Changes between Version 10 and Version 27 of Ticket #242

12/19/2016 01:03:56 PM (2 years ago)

Since this circumvention method is becoming popular again, I reopened this issue and updated the description. Also I made the issue confidential, surprisingly this wasn't done back then, despite this providing an exploitable circumvention technique.

Currently, our plan is to see what's going to happen with Chrome bug 632009, in which we requested chrome.tabs.insertCSS() to use user stylesheets, so that we can migrate to that API, instead of injecting an author stylesheet, which will be even less effective once shadow DOM v0 gets removed from Chrome. Then again, due to the upcoming deprecation of shadow DOM v0, the Chromium team seem to consider prioritizing that issue now (also see #4713).

Alternatively, we could (theoretically) emulate element hiding filters, partially reimplementing CSS ourselves, so that we can operate on the nodes to be hidden rather than using a stylesheet. That is essentially what uBlock is doing. But this approach is a bit controversial, as the implementation tends to be quite complex and might potentially have a negative performance effect in particular on large pages and pages that change a lot dynamically. On the other hand it could also help reducing the memory usage, like it does in uBlock. But then again, we'd still mess with the DOM, in a merely slightly harder to circumvent way. Not to mention, that as more as we mess with the actual page content (e.g. through the DOM) as higher the legal risk we are facing. So this might only be a last resort, if at all.


  • Ticket #242

    • Property Status changed from new to reopened
    • Property Platform changed from to Chrome
    • Property Cc saroyanm sebastian fanboy arthur scuturic added
    • Property Tester changed from to Unknown
    • Property Sensitive set
    • Property Summary changed from chrome: hiding filters do not work to Element hiding filters can be overridden by the element's style attribute
    • Property Ready unset
  • Ticket #242 – Description

    v10 v27  
    1 === Environment === 
    2 chrome 
    3 Adblock Plus 
    4 easylist 
     1=== How to reproduce === 
    6 === How to reproduce === 
    7 go to 
     3* Search for something on Bing (also see #4425) 
     4* Visit any article on The Telegraph (also see #4171) 
     5* ~~Search for something on (no longer reproducible, website seems to be broken) 
     6* Visit any web page that uses `style="dislay: block !important"` (or alike) to avoid element hiding 
    98=== Observed behaviour === 
    10 the filter (easylist) 
    13 is not working 
     10If a web page sets the `display` CSS property of an element using an `!important` rule applied via the element's `style` attribute, it takes precedence over element hiding filters applied by Adblock Plus, potentially preventing ads from being hidden. 
     12That is because element hiding in Adblock Plus for Chrome (as well as on Safari and Microsoft Edge, but unlike on Firefox) is implemented using an author stylesheet, i.e. a regular `<style>` element which is injected into the (shadow) DOM. 
    1514=== Expected behaviour === 
    17 the SimpleAcceptableTextAds class is not hidden 
    18 in Firefox the class is hidden 
    20 see 
    21 '''Ad visible due to "display: block !important;"''' 
    23 see also 
     16Element hiding filters should take precedence over any styles applied by the web page, including those applied using the `style` attribute.  Adblock Plus for Firefox currently achieves that by utilizing user stlesheets. This mechanism, however, is currently not supported by Chrome, see [ Chrome bug 632009].