Loading…
"Your Filters" should take precedence over 3rd-party filters #139
3 participants
What do other more popular blockers do?
I just checked with ABP and AdBlock, and there is no such thing as special treatment for user-supplied filters.
I used wired.com/wp-content/config/cn-fe-stats/ as a filter, and ABP/AdBlock didn't block http://www.wired.com/wp-content/config/cn-fe-stats/s_code.js?ver=1407430248 because of the exception filter @@wired.com*/cn-fe-stats/ in EasyPrivacy.
So that would be a new feature not found in other blockers, and since at this point I want to spend whatever programming time I have to actually bring to life uMatrix, I will close this one as by design.
So that would be a new feature not found in other blockers, and since at this point I want to spend whatever programming time I have to actually bring to life uMatrix, I will close this one as by design.
That's perfectly understandable. However, I think that cbuijs's request makes sense. If I add an own filter it's because it's missing in the 3rd party lists, or it's because I explicitly want to override an existing rule (be it a false positive or not). In the second case, in order to achieve that the own rule must take precedence. I understand that you want to ensure ABP compatibility, but if it comes to how own rules are handled, a deviation is justified, IMHO, to ensure that µBlock behaves according to the user's needs.
May I suggest that you look into this once you have the time do so after µMatrix development has progressed sufficiently?
With fix to #191, I can trivially support a new filter option, important, meaningful only for block filters, and which means "unconditionally bypass allow filters". However, after I put in the two extras line of code required to support this new filter option, I found out things are not that simple. The problem is that more than one block filter may match a specific URL, and there is no guarantee that the first one found will be the one with the important option. So back to square one, I originally thought the important option was the solution, and I liked it because of its elegance.
Actually, the solution can be used. I had assumed that adding another URL-scan evaluation block would be too much, but I just benchmarked to find out the performance cost of an extra evaluation block, and this is what I get:
µBlock > onBeforeRequest: 0.151 ms (19696 samples)
µBlock > onBeforeRequest: 0.150 ms (20024 samples)
µBlock > onBeforeRequest: 0.150 ms (20330 samples)
µBlock > onBeforeRequest: 0.150 ms (20612 samples)
µBlock > onBeforeRequest: 0.150 ms (20946 samples)
µBlock > onBeforeRequest: 0.150 ms (21128 samples)
µBlock > onBeforeRequest: 0.150 ms (21225 samples)
µBlock > onBeforeRequest: 0.150 ms (21419 samples)
µBlock > onBeforeRequest: 0.150 ms (21578 samples)
µBlock > onBeforeRequest: 0.150 ms (21771 samples)
So it's all fine. For comparison, here are the same benchmarks at some point in the past (most recent to least recent):
Great! So, if I understand you correctly, you introduced a second evaluation scan to make sure that the filter with the important option will be the first one?
Yes. First scan checks for important block filter. If there is one, evaluation completed = blocked.
Second scan, as before, checks whether there is a plain block filter, if there is none, evaluation completed = not blocked.
Third scan, as before, checks whether there is an allow filter, evaluation completed regardless of result. if there is one allow filter, not blocked, if there is no allow filter, blocked.
This also means that with the new important filter option, uBlock will now be able to block with 100% certainty -- at user's own risk. It will still be easier to block with 100% certainty with HTTPSB, since a fix is a single point-and-click away.
Just one question regarding the new important option: Is it combinable with other options like, e.g.,
||google-analytics.com^$important, domain=example.com
or have you designed it to be used as a "global" rule?
Combinable.
Great! That's what I actually expected. Thanks - excellent work as usual!
I've added a paragraph in "Privacy Stuff". Please check its correctness.
That doesn't work:
||google-analytics.com^$important,domain=~example1.com|~example2.com
important means to reverse the evaluation order, or in other words to bypass any existing exception filters.
This above means "bypass exception filters except when".
I'm not sure that I understand. Isn't that equivalent with what I wrote?
This is how I see it:
||google-analytics.com^$important
overrides those exception filters on all websites.
||google-analytics.com^$important,domain=example.com
overrides those exception filters on example.com only.
||google-analytics.com^$important,domain=~example.com
overrides those exception filters on all websites but not on example.com.
Is that wrong? Perhaps my wording was unclear ...
EDIT: BTW, v. 05.5.0 is still available as pre-release and only as source code ...
overrides those exception filters on all websites but not on example.com
Important filters can not be "excepted".
but would be a nice enhancement
No, or else where do we stop? Next someone will ask can we have a really-important option, and then a really-really-important-i-mean-it option?
By default net requests are all allowed. Block filters are exceptions to this default behavior. Then there is the allow filters to create exceptions to block filter exceptions to default behavior. Then there is now the important option to create block filter exceptions to allow filter exceptions to block filter exceptions to default allow behavior.
Yes, the other example is correct.
Seems that whitelist entries in the "3rd-party filters" (like the @@ ones in the adblock subscriptions), take precedence over the "blacklisted" ones that I use in "Your Filters" sections.
As example, I have the following in my "Your Filters":
||aolcdn.com/ads^
But in the statistics it shows that it is whitelisted in the easylist blocklist, which has the entry:
@@aolcdn.com/ads/adswrapper.js
Could we have the "Your Filters" have precedence or an option where you configure so?