Ublock: unblockable ads

[KonoromiHimaries]

dobreprogramy.pl

unblockable ads

https://github.com/NanoAdblocker/NanoFilters/issues/3

Steps to reproduce the issue

• join to this site
• use this filter

dobreprogramy.pl##body > *:matches-css(background-image: /data:image\/(gif|jpg|jpeg|png);base64,/):matches-css(position: fixed)

my filters
https://gist.github.com/KonoromiHimaries/809ef17633ba86197db6df03d6790f16

uBlock Origin 1.14.22
Nano Defender 13.8
Chrome 63.0.3239.108
win10

[gorhill]

I don't see that ad when using both POL filter lists + default settings + only uBO.

[okiehsch]

See https://github.com/NanoAdblocker/NanoFilters/issues/3#issuecomment-352157505

With Windows the ad "flickers" on my end, with Linux I don't see the ad.

[gorhill]

Well, with 1.14.22 a costly procedural cosmetic filter can still be disabled if it's really, _really_ expensive. In the end, filter list maintainers are responsible to craft their filters carefully. The filter above is lacking in such carefulness, so this could be an issue on slower CPU.

Instead of:

dobreprogramy.pl##body > *:matches-css(background-image: /data:image\/(gif|jpg|jpeg|png);base64,/):matches-css(position: fixed)

Try

dobreprogramy.pl##body > *:matches-css(position: fixed):matches-css(background-image: /^url\(data:image\/(gif|jpg|jpeg|png);base64,/)

Notice:

• be more selective with the prefix selector
• put the least expensive matches-css first
• the data: URI is over 11,000 characters, so you want to avoid a regex that will scan the whole URL

[KonoromiHimaries]

@gorhill this filter not working for me

dobreprogramy.pl##body > *[class]:matches-css(position: fixed):matches-css(background-image: /^url\(data:image\/(gif|jpg|jpeg|png);base64,/)

[gorhill]

I edited the filter to remove the class, try again the edited version. But anyways, just modify your filter in your list so that the regex is more efficient (avoid scanning whole URL), and use the cheapest matches-css first.

[gorhill]

Also, see if at the console your filter is being disabled, uBO reports when this occurs.

[KonoromiHimaries]

@gorhill still not working

dobreprogramy.pl##body > *:matches-css(position: fixed):matches-css(background-image: /^url\(data:image\/(gif|jpg|jpeg|png);base64,/)

[gorhill]

Did you investigate whether the element to filter matches anything in the DOM? Please investigate _more_ on your side.

[KonoromiHimaries]

@gorhill i don't know
https://gist.github.com/KonoromiHimaries/3ea43a26be11a5824951ebe093eb9f01

[gorhill]

[KonoromiHimaries]

of corse, i tryed without this filters list and i have the same effect.

[gorhill]

Ok, I think the page is changing the class under some conditions, and uBO's mutation observer does not observe class changes.

[gorhill]

The page is trapping calls to getComputedStyle -- most likely to foil uBO:

Object.defineProperty(window, 'getComputedStyle', {
    value: function (e, p) {
        return e && e.hasAttribute('YszMpo') ? null : opMzsYopMzsY(e, p);
    },
});

This could be the issue.

[jspenguin2017]

The page is trapping calls to getComputedStyle

Isn't element hiding handled by content script? There is no way for the page script to tamper with content script functions.

[gorhill]

Yes, that's right. So the class modification could be the issue.

[gorhill]

How about:

dobreprogramy.pl##body > *:matches-css(position: fixed):matches-css(background-image: /^.{0,8}data:image\/(gif|jpg|jpeg|png);base64,/)

[jspenguin2017]

Apparently there is a double-quote there.

[jspenguin2017]

This works for me, but it takes like 5 seconds before it gets hidden:

dobreprogramy.pl##body > *:matches-css(position: fixed):matches-css(background-image: /^url\("data:image\/(gif|jpg|jpeg|png);base64,/)

Update: With polish filters on, the ad only blink once.

[gorhill]

There is this:

dobreprogramy.pl##a[id][href="#"]:xpath(..)

Edit: or pure xpath -- better:

dobreprogramy.pl##:xpath(//a[@href="#"][@id]/..)

[gorhill]

Probably a case that would benefit from a :remove operator: removing the style node behind the ad removes the need to chase for the ad in the dom. #2252.

[jspenguin2017]

I was definitely looking into a remove operator, I was planning on adding it but I'm not really familiar with how the cosmetic engine works so I added a surrogate (that works half the time) instead (nano-remove-element-onready.js).
The problem is if uBO can remove elements instead of hiding them, they can just watch for remove as well, so we'll be back to chasing it around the DOM.
I don't know how hard it is to implement it, but if you want it to deal with hard-to-block ads, chances are it's not going to last very long.

[gorhill]

they can easily watch for remove as well, so we'll be back to chasing it around the DOM

There is _always_ something they can do in response to what blockers do. If the mindset in the past had been that there is no point doing something because they can always do something to work around, there would be no blockers today.

This also can be said of every single filter we add, and yet we are here, adding filters.

[jspenguin2017]

This also can be said of every single filter we add, and yet we are here, adding filters.

It really depend on what we are dealing with, if it's a third-party adblocker detection library, I usually craft a generic rule so the time it takes them to overcome my rule is unreasonable compared to the time I need to craft the rule. For example, in the battle against NoAdBlock, my first rule took them 2 days to overcome, my second rule took them 2 weeks, and my third rule took them already a few months and they still haven't be able to get around it.

I think in this case here we are dealing with a "library" or something third-party, because they need to make sure their code works for all of their customers, it is rather hard for them to make changes. So I think it's worth investigating deeper to strike where it hurts, like API interface or other hard-to-change components.

:remove is useful, I'm not saying it's not, it's just not the right tool for this specific job here.

[gorhill]

Quick test with HTML filtering, these seems to work:

dobreprogramy.pl##^script:has-text(DisplayAcceptableAdIfAdblocked|getComputedStyle)
dobreprogramy.pl##^style:has-text(/^\[/)

Requires Firefox 57+ and uBO dev build.

Using HTML filtering to fix the issue here would really be the simplest way for uBO users -- there is no fight occurring in the DOM, the offending styles and scripts are removed before the browser parses the page.

Are Polish users willing to move to Firefox 57 given the behavior of top .pl sites?

[KonoromiHimaries]

@gorhill

Are Polish users willing to move to Firefox 57 given the behavior of top .pl sites?

I do not think it's going to happen
50% users use at chrome and i know that not change because 1 ad has show
mozilla not be better, mozilla have a own ads

https://www.reddit.com/r/firefox/comments/7jh9rv/what_is_looking_glass/?st=jbc2pv1c&sh=83a5507d

[gorhill]

Yes, they fumbled. However that extension was never ever enabled by default, it had to be enabled by the user. I checked the code on GitHub, I can confirm.

If people are not using Firefox and instead pick Chrome because of that one event, this just makes no sense, that would be an irrational decision: there is no way Chrome gives you the same level of config capability offered by Firefox. In any case, all has been said about that LookingGlass event, I don't want the issue here to become more of it.

I am merely pointing out that at some point, uBO can't do magic, it has to deal with the real world with realistic solutions. And so far, Firefox 57 with uBO 1.1.15 will be far better equipped than Chromium to deal with what out-of-control sites are throwing at browsers. In the end users will move to what works.

So in any case, I will add the filters above to uBO's filters when 1.1.15 is published, and more generally I will add whatever HTML filters benefit Firefox users, while Chrome users will have to accept imperfect solutions with trade-offs (CPU-intensive procedural filters, glitchy rendering because DOM fighting, Chrome's lack of support for user stylesheets, Chrome's unreliable scriptlet injection due to race condition, etc.).

Same reasons I advise people to move to Firefox when they suffer Instart Logic's crap.

[jspenguin2017]

there is no way Chrome gives you the same level of config capability offered by Firefox

Chrome comes with a decent amount of flags and more command line options than you need: https://peter.sh/experiments/chromium-command-line-switches/

The Chrome DevTools is definitely better than Firefox's one. You get a warning every single time you open background page console and if you clicked the wrong button, you have to reinstall Firefox.
And you can only have one background console open at one time, how are you suppose to debug cross extension messaging?

uBO can't do magic

It's not magic, it's polyfill. Nano Defender can filter script tags since last year, so can uBO.

Chrome's lack of support for user stylesheets

It's almost released, it's in dev or beta.

[KonoromiHimaries]

new ads

[Martina-Neumayer]

Yeap.. and new crap.. https://github.com/NanoAdblocker/NanoFilters/issues/3#issuecomment-357144766