Skip to content

Loading…

Sometimes `domain` directive in source filter lists is below real domain as per PSL #188

Closed
gorhill opened this Issue · 1 comment

1 participant

@gorhill

[PSL = Public Suffix List.]

Instrumenting to detect such case, I get the following at the console:

FilterParser.parseOptHostnames(): No domain for blogspot.com
FilterParser.parseOptHostnames(): No domain for cloudfront.net
FilterContainer.freezeHostnameSpecifics(): No domain for blogspot.co.uk
FilterContainer.freezeHostnameSpecifics(): No domain for blogspot.com
FilterContainer.freezeHostnameSpecifics(): No domain for gov.pl
FilterContainer.freezeHostnameSpecifics(): No domain for poznan.pl
FilterContainer.freezeHostnameSpecifics(): No domain for gda.pl
FilterContainer.freezeHostnameSpecifics(): No domain for web.id
FilterContainer.freezeHostnameSpecifics(): No domain for cloudfront.net
FilterContainer.freezeHostnameSpecifics(): No domain for dreamhosters.com
FilterContainer.freezeHostnameSpecifics(): No domain for blogspot.co.nz

So the domain directive for net and cosmetic filters is not strict, it's more like "hostname suffix".

The problem here may account for those cases where users report that not all ads are blocked.

I need to think carefully about how to fix this.

@gorhill

I found an elegant solution to address the problem here for net request filters. However, this adds two more buckets to be tested for each token of a URL, hence potentially an increase in CPU overhead when testing a net request. I decided to benchmark using reference benchmark to find out how performance is affected with the change. Although I didn't expect anything else than a small overhead increase in testing for each net request, results of my benchmark show he opposite:

µBlock > onBeforeRequest: 0.162 ms (18481 samples)
µBlock > onBeforeRequest: 0.162 ms (18768 samples)
µBlock > onBeforeRequest: 0.162 ms (19081 samples)
µBlock > onBeforeRequest: 0.162 ms (19346 samples)
µBlock > onBeforeRequest: 0.161 ms (19690 samples)
µBlock > onBeforeRequest: 0.161 ms (20013 samples)
µBlock > onBeforeRequest: 0.160 ms (20184 samples)
µBlock > onBeforeRequest: 0.161 ms (20371 samples)
µBlock > onBeforeRequest: 0.161 ms (20532 samples)
µBlock > onBeforeRequest: 0.161 ms (20656 samples)

In my former benchmark which I used as official doc, I measured slightly above 0.170 ms per net request.

It was a long time since I measured this particular part of the code, so not sure which changes in between since then is responsible for the now better performance despite the addition of code paths to fix the current bug. Whatever, no negative impacts for the found solution, I'll keep it.

@gorhill gorhill added a commit that referenced this issue
@gorhill gorhill this fixes half of #188 e12eeda
@gorhill gorhill added a commit that closed this issue
@gorhill gorhill this fixes #188 completely 7b82f7a
@gorhill gorhill closed this in 7b82f7a
@andre-hub andre-hub pushed a commit to andre-hub/uBlock that referenced this issue
@gorhill gorhill this fixes #188 7eed999
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.