Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Comments on Some user avatars are referenced over HTTP when the page is loaded over HTTPS, triggering mixed content handling

Post

Some user avatars are referenced over HTTP when the page is loaded over HTTPS, triggering mixed content handling

+1
−0

I noticed that visiting Using accents while staying legible on Writing triggered a mixed content warning in my browser. Another example is How to train readers in Argot or Slang (full disclosure: I have posted an answer to the latter question).

It seems that some user avatars are referred to through http://writing.codidact.com/uploads/... which then redirects to https://s3.amazonaws.com/storage.qpixel.artofcode.co.uk/....

This is a problem because the initial request is for a resource hosted over HTTP, which triggers mixed content handling in the browser.

Even though images aren't considered active content, that's still enough to cause a strictly configured browser to not load them, and it is a potential information leak; especially on pages with multiple user avatars displayed, it would be plausible to piece together which pages are being viewed based on the specific set of user avatars requested.

Such requests should either be explicitly HTTPS, or protocol-relative. (A protocol-relative link is, for example, //writing.codidact.com/uploads/...; notice that the protocol specification is missing. If the page is loaded over HTTP, this uses HTTP; correspondingly, if the page is loaded over HTTPS, it uses HTTPS.)

Without having analyzed the issue in detail, it appears to me that this is the case for users who have uploaded their own avatars; those served by unicornify.pictures are correctly requested over HTTPS.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (6 comments)
General comments
ArtOfCode‭ wrote over 4 years ago

[status-norepro] so far. Which avatars in particular aren't loading via HTTPS for you?

Canina‭ wrote over 4 years ago · edited over 4 years ago

@ArtOfCode Both posters' avatars in the first linked question. I even went so far as to double-check the DOM before posting this. However, I can't seem to get the same behavior now. Makes me wonder if my browser had somehow got into a weird state, and what I was seeing was a reflection of that; I'm pretty sure one of the few things I didn't try before posting this was to restart the browser.

ArtOfCode‭ wrote over 4 years ago

@aCVn Possibly, or you may be right that something was up. There were a bunch of RSS feed items posted into Discord as HTTP links recently, but now they're all back to being HTTPS. I'll keep an eye out, but with any luck this has just resolved itself.

Canina‭ wrote over 4 years ago · edited over 4 years ago

@ArtOfCode I'm definitely willing to go so far as to say that something caused my browser to treat the non-unicorn avatars as mixed content, which prevented them from loading because my browser is set to block all mixed content (not just mixed active content). (My avatar, which is sourced through unicornify, loaded fine.) When I looked, I clearly saw the http:// in the DOM for the non-loading avatars.

Canina‭ wrote over 4 years ago

What I don't have any plausible explanation for is what caused that, especially since (according to the page footer) there was no release in between my reporting this as a problem and my being able to confirm that the software was no longer behaving that way.

ArtOfCode‭ wrote over 4 years ago

Might've had something to do with the new site launch, since that was around the same time... I'll keep an eye out for it next time we launch a site.