ghostery-extension: Ghostery for Chrome unexpectedly blocks content with class="clickable"

Description

When I open a local file via file: protocol, and that file includes an iframe via https: protocol, Ghostery unexpectedly inserts a rule into the iframe that suppresses some content - specifically, any element with class “clickable”.

Expected Behavior

Nothing. Ghostery says it only scans http and https pages; I wouldn’t expect it to do anything in this case, let alone this.

Actual Behavior

Ghostery appears to insert <style type="text/css" id="cliqz-adblokcer-css-rules"> :root .clickable {display:none !important;}</style> to the <head> element of the iframe, causing some of its content to be suppressed.

Steps to Reproduce

Open this Gist: https://htmlpreview.github.io/?https://gist.github.com/aaronadamsTO/f9206dc5e2e3f2217bbde8fcb92609b0/raw/bug.html
Save bug.html locally
Open bug.html in your browser via the file: protocol, while running Ghostery for Chrome 8.2.0

Note that paragraph 2 inside the iframe is no longer visible. This appears to be due to Ghostery unexpectedly inserting a rule into the iframe page’s <head> element.

This appears to happen only when the parent page is accessed via file:, and the child page via https: (or http:). No other combination, including visiting the child page directly, appears to cause Ghostery to insert this rule.

(I know it seems super unlikely that anyone would run into this in the wild - but I did, via work on a platform that involves third-party JavaScript and iframes. It was super confusing until I figured out Ghostery was messing with me, likely inadvertently.)

Versions

Browser: Chrome 68
OS: Windows 10
Extension: Ghostery for Chrome 8.2.0

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 18 (9 by maintainers)

Most upvoted comments

@aaronadamsTO I was able to reproduce and find a fix for this issue, which was two-fold:

We should not inject cosmetics at all on un-supported protocols (e.g. file://), as you suggested initially. There was one code-path which did not check this condition and would potentially inject cosmetics for URLs with any protocol.
In some cases, when hostname is empty, some rules would be incorrectly matched. Again, as pointed out by you, this could happen with file:/// protocol.

The fixes will be pushed to ghostery-extension soon. I will keep you updated on the status.

Thanks again for investigating, this was really helpful.

remusao on Nov 9, 2018

@christophertino Success! I’m happy to confirm Ghostery is no longer injecting strange rules into my iframes in domainless contexts. My test pages work again!

This will save me multiple “WTF? Guh…” trips to Incognito mode every week, so thank you!

aaronadamsCA on Nov 27, 2018

Thanks @remusao.

If it helps, I’m guessing the rule that’s now suppressing iframes entirely is probably this one, checked in 12 days ago:

https://github.com/cliqz-oss/adblocker/blob/0cddd63ec5cf46d71f2d39b8e8887172b2ab6feb/assets/raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/filters.txt#L10997

rmdown.com##[style]:not(SPAN)

aaronadamsCA on Nov 9, 2018

Unfortunately I’m still able to reproduce in version 8.2.3, under these (admittedly very specific!) circumstances.

aaronadamsCA on Aug 10, 2018