Breaks external HTTP images on HTTPS pages

[Marat-Tanalin]

Description

Looks like Ghostery started to automatically replace http with https (note the s) in IMG element’s src attribute. This breaks external images located on HTTP sites that don’t have HTTPS version.

Tested with a new clean profile with Ghostery installed as the only extension. Disabling Ghostery as an extension via Firefox extension manager does help.

Expected Behavior

Ghostery should not touch regular (not related to trackers or advertisement) images, at least by default. Images should work by default. Such web-incompatible features should be opt-in.

Just replacing http with https does not magically make all sites working via HTTPS.

Actual Behavior

External (located on a host different from the host the page is located on) HTTP images on HTTPS sites do not load if the external site does not have an HTTPS version.

Steps to Reproduce

1. Install Ghostery for Firefox.
2. Go to the example page (see after the “What’s the state […]” paragraph).
3. Observe that the word Image is displayed instead of the actual image.
4. Note that sometimes image is displayed when the page is loaded for the first time. Then refresh the page to see the issue.

Versions

• Browser: Firefox Developer Edition 64.0b14.
• OS: Windows 10 Pro (64 bit)
• Ghostery: 8.2.5 for Firefox

[Aziz-Ghostery]

We do not allow access to non secure pages/content from within a secure site: https://forums.geforce.com
If this were non secure site then access to http content (images) wouldn't be an issue.
I think this is an issue that the site owner should rectify, i.e. either making site and its content secure or non-secure.

[Marat-Tanalin]

This is a pretty naive approach. If any site could be made secure just by replacing http with https, then extensions like HTTPS Everywhere wouldn’t be forced to have a huge built-in database of hosts actually working via HTTPS.

Blindly replacing http with https in external URLs is web-incompatible, so this should at least be opt-in anyway.

[Aziz-Ghostery]

We may be wrong in assuming that anybody who goes through the trouble of setting a secure site will make sure that its content is equally secure. As I've explained this is how Ghostery currently works.
If you are keen on accessing these two images, you may disable smart blocking.

[christophertino]

@Marat-Tanalin We only check for mixed content when users have Smart Blocking enabled. To your point, it is an opt-in feature. You can disable it by clicking on the blue light-bulb icon in Ghostery.

You can see here where we attempt to upgrade the request to https.

ghostery-extension/src/classes/EventHandlers.js

Line 631 in a10b414

if (upgradeInsecure) {

As you mentioned, this won't work in all cases but we've decided that the risk of loading insecure content on a secure page outweighs any potential hassle caused by accidentally blocking legitimate site content. Nonetheless, it's an optional feature which users may choose to disable at their discretion.

[Marat-Tanalin]

Opt-in means disabled by default. Smart Blocking is apparently enabled by default given that images did not load when I tested with a clean Firefox profile with Ghostery just installed and used with default settings.

If you’ll decide to keep it enabled by default (which I believe would be a mistake), then it would probably make sense for you at least to consider making it more explicit and clear to user:

instead of silently replacing http with https in image URLs thus making them nonworking with no obvious reasons, replace the image itself with a Ghostery-specific block (like you did with SoundCloud embedded player) containing an explanatory notification about that the image has been blocked by Ghostery and that this behavior can be disabled by disabling the Smart Blocking feature in Ghostery. Thanks.

[christophertino]

Those are all good points. The Smart Blocking feature is a bit of a black box right now. There should be an indicator in the UI explaining what type of requests it's blocking. I'll make a ticket for it.

[MatrixFr]

Can we add an option to allow mixin plz?

Cant continue to use Ghostery because this bug....

[bast1aan]

This issue affects me too, it took me some time to find out the problem is caused by Ghostery. As mentioned by the issuer, this is standards-violating behavior. In cases of user generated content like forums, you cannot assume the site owner always has control that all content is also always served over https. As far as I know, browsers block by default leaking data like referer or https-cookies to http externa connections. I also agree it would be nice if the user is notified if http is replaced by https.

[linegel]

My two cents: that’s behavior is correct and should stay in place, but to make clear for user that what happens is expected behavior there should be a tip somewhere with link to explanation how much information can be exposed in case this feature will be disabled coz for many people this tech scoop not obvious

[denyeo]

Just ran into this bug - replacing http with https naively is a bad practice that breaks content silently. Web servers simply don't always offer HTTPS - and in our case, our S3 bucket's HTTPS isn't working, so we had to use HTTP. Firefox already handles this with an "insecure" icon. I ended up troubleshooting for an hour before finding the problem, and I even checked Ghostery's settings to make sure it wasn't doing anything funny. Recommend that you guys disable this practice, or at least make it obvious.

[sebmjoll]

I just experienced a problem that is very similar. I am using serverless offline to develop locally my web application as well as some local AWS lambdas and everything is fine until I click manually on a button that triggers an http GET requests towards an https:// url. At this point, the browser adds "Upgrade-Insecure-Requests: 1" to the request header, and any http url used after that is updated by ghostery to replace http:// with https:// which breaks complety the application. Here is a screenshot taken from Chrome where I can see the faulty redirection:

It is worth noting that https urls that are fetched by the application itself do not trigger the problem. It seems that it is only when the action is triggered by a user that the problem starts happening.