"|https://$third-party,image" uBlock incorrect reading

[ghost]

reportingnow commented Apr 8, 2016

uBlock enforce "|https://$third-party,image" blocking rule even the blocklist
have nothing such line.
One or more specific URLs where the issue occurs

https://www.amazon.co.jp/
(not http://)
Screenshot in which the issue can be seen

https://i.imgur.com/3GoQl3J.jpg
Steps for anyone to reproduce the issue

Subscribe NoMercy blocklists and nothing else.
Open chrome://ublock0/content/logger-ui.html
Visit the URL above.
Blocked with reason(screenshot).

Your settings

Browser/version: Palemoon 26.2(latest)
uBlock Origin version: 1.6.9b0 (from this github)

Your filter lists

Only these; other lists are not checked.
http://repo.a2af37vnxe44tcgo.onion/data/abl/nm_fanboy-ultimate.txt
http://repo.a2af37vnxe44tcgo.onion/data/abl/nm_easylist_asia.txt
Your custom filters (if any)

none.

This is NOT blocklist's fault; Adblock works fine.
reportingnow commented Apr 8, 2016

Current data, for @gorhill. See, there's no "|https://$third-party,image".
What do you think? Why uBlock Origin think "|https://$third-party,image" is exist?
reportingnow commented Apr 8, 2016

https://gist.github.com/reportingnow/4f7ff270bd4053a10fba19a1461b4c4d

[gorhill]

http://repo.a2af37vnxe44tcgo.onion/data/abl/nm_fanboy-ultimate.txt contains this filter:

|https://$image,script,third-party

[lewisje]

First of all, if you use the "NoMercy" lists, which strip out the exception rules that keep certain sites from breaking, you'll have a bad time: https://adblockplus.org/forum/viewtopic.php?p=120975#p120975

With that said, I haven't found a no-Tor mirror of those filter lists, so I went ahead and fired up the Tor Browser just to look at them, and in the "NoMercy" version of Fanboy Ultimate, I found this gem:

|https://$image,script,third-party

I found that same filter, in the same place, in the "NoMercy" version of EasyList Asia.

The real question, then, is how that filter got in there, and why uBlock Origin reports the filter as something else (maybe the latter has to do with how it decomposes the filter options and internally represents the filter).

Around that same spot in EasyList itself (the part about adult-specific blocking), I see a very similar filter, but with negative domain specifiers:

|https://$image,script,third-party,domain=~feedback.pornhub.com|pornhub.com|redtube.com|redtube.com.br|tube8.com|tube8.es|tube8.fr|youporn.com|youporngay.com

Both of these variants were right above the following filter, so I highly believe that the first one is the second with its negative domain specifier removed:

|https://$image,xmlhttprequest,domain=pornhub.com|redtube.com|redtube.com.br|tube8.com|tube8.es|tube8.fr|youporn.com|youporngay.com

Below are the two NoMercy lists as of a few minutes ago, and below that is EasyList as of that time:
nm_easylist_asia.txt
nm_fanboy-ultimate.txt
easylist.txt

This sums up what I think about this issue.

[gorhill]

maybe the latter has to do with how it decomposes the filter options and internally represents the filter

Yes.

[ghost]

He already answered that question above.

maybe the latter has to do with how it decomposes the filter options and internally represents the filter

Yes.

[gorhill]

uBO decomposes filters in smaller units, for efficiency purpose, and to detect/discard duplicates.|https://$image,script,third-party becomes:

|https://$third-party,image
|https://$third-party,script

In the logger, the textual representation of the filter involved in a network request is rebuilt using it's decomposed version.

See https://github.com/gorhill/uBlock/wiki/Launch-and-filter-lists-load-performance.