I find this a bit weird. Suppose I try to load StackOverflow over https:

I get a nice green padlock of feel-good browser feeling that my web browsing is secure. However, if I start to navigate the site, very often this happens:

Luckily, clicking on that white page of vanished security dreams lets me ask my browser why, even if it's loading Stack Exchange content over the https protocol, it still feels like killing the party spirit with some you're-never-safe existential-dread reminder.

Generally speaking, these get blamed to mixed content warnings, because many pages on the network load external content over plain http either by default or because the external provider might not support https (which would be a weird situation, and almost (?) always discouraged, but conceivable such as a user loading images directly from some external site as ![image](http://not-stack-imgur.com)).

However, most often the culprit is not external content but simply the standard stack.imgur image hosting, both for images in posts and in community ads. If you load, say, this rarely-visited piece of real estate, there's five mixed-content warnings all coming from i.stack.imgur. Funnily enough, though, it doesn't have to be that way. In fact, the most iconic image on that page (i.e. this one) is actually loaded over https, which can be done either by explicitly modifying the protocol in the markdown, or by simply dropping the protocol (i.e. ![](//i.stack.imgur.…)).

That means that the official stack.imgur service is perfectly happy to serve the images over secure http. In that light, I think the following feature request is pretty reasonable:

If I load a Stack Exchange over https and a page contains an image from https://i.stack.imgur.com, change that link to the https version.

Now, I know that https support on the Stack Exchange network is not completely official, not because the devs don't care about it but because it is hard (including e.g. that issue with certificates for per-site meta sites), but this seems like a small and cheap step that will help close the loop on unencrypted connections and eventually make for a better internet for everyone.

These images are a privacy risk. If I'm loading, say, The Workplace over https, people can infer that I'm looking at workplacey stuff, but they can't tell what question I'm looking at, asking or answering, or even whether I'm just reloading the front page every few minutes. However, if I load this question, say, an eavesdropper can see the pretty distinctive image identifier TenFQ and infer pretty uniquely what question I was looking at (and potentially, say, infer that it was me that sent the anonymous complaint over office lighting light month). All because of an avoidable http call.

Now, I understand that this is only a small, partial solution to a bigger problem, but it seems to me that it does actually help keep browsing a private affair between the user and Stack Exchange, and that's a Good Thing around these parts. I also understand that https is a technically complex subject, and I'm happy to be corrected if my assumptions don't hold and the change would not actually help at all. I also realize that this will not have a trivial performance footprint server-side, but hopefully this is not fatal either. Or are there other fixes with better security-to-performance ratios in the works to come online soon?

I find this a bit weird. Suppose I try to load StackOverflow over https:

I get a nice green padlock of feel-good browser feeling that my web browsing is secure. However, if I start to navigate the site, very often this happens:

Luckily, clicking on that white page of vanished security dreams lets me ask my browser why, even if it's loading Stack Exchange content over the https protocol, it still feels like killing the party spirit with some you're-never-safe existential-dread reminder.

Generally speaking, these get blamed to mixed content warnings, because many pages on the network load external content over plain http either by default or because the external provider might not support https (which would be a weird situation, and almost (?) always discouraged, but conceivable such as a user loading images directly from some external site as ![image](http://not-stack-imgur.com)).

However, most often the culprit is not external content but simply the standard stack.imgur image hosting, both for images in posts and in community ads. If you load, say, this rarely-visited piece of real estate, there's five mixed-content warnings all coming from i.stack.imgur. Funnily enough, though, it doesn't have to be that way. In fact, the most iconic image on that page (i.e. this one) is actually loaded over https, which can be done either by explicitly modifying the protocol in the markdown, or by simply dropping the protocol (i.e. ![](//i.stack.imgur.…)).

That means that the official stack.imgur service is perfectly happy to serve the images over secure http. In that light, I think the following feature request is pretty reasonable:

If I load a Stack Exchange over https and a page contains an image from https://i.stack.imgur.com, change that link to the https version.

Now, I know that https support on the Stack Exchange network is not completely official, not because the devs don't care about it but because it is hard (including e.g. that issue with certificates for per-site meta sites), but this seems like a small and cheap step that will help close the loop on unencrypted connections and eventually make for a better internet for everyone.

These images are a privacy risk. If I'm loading, say, The Workplace over https, people can infer that I'm looking at workplacey stuff, but they can't tell what question I'm looking at, asking or answering, or even whether I'm just reloading the front page every few minutes. However, if I load this question, say, an eavesdropper can see the pretty distinctive image identifier TenFQ and infer pretty uniquely what question I was looking at (and potentially, say, infer that it was me that sent the anonymous complaint over office lighting light month). All because of an avoidable http call.

Now, I understand that this is only a small, partial solution to a bigger problem, but it seems to me that it does actually help keep browsing a private affair between the user and Stack Exchange, and that's a Good Thing around these parts. I also understand that https is a technically complex subject, and I'm happy to be corrected if my assumptions don't hold and the change would not actually help at all. I also realize that this will not have a trivial performance footprint server-side, but hopefully this is not fatal either. Or are there other fixes with better security-to-performance ratios in the works to come online soon?