AdguardBrowserExtension
AdguardBrowserExtension copied to clipboard
Rule priorities
AdGuard Extension version
4.2.189
Browser version
Chrome 109
OS version
Windows 7
What filters do you have enabled?
Filter unblocking search ads and self-promotion
What Stealth Mode options do you have enabled?
No response
Issue Details
I've read the Rule priorities
section a lot of times. Finally, as I understand:
- The rules are arranged in the order of priority from low to high.
- The priority order of filtration rules is used in the highest priority order to the lowest.
However, I encountered some cases as follows:
The rules of higher priority will be used:
! weight of the rule without modifiers
! Priority: 1.
||example.com/ggccp.js
! base weight + weight of the modifier
! Priority: 1 + 1 = 2.
ggccp.js$match-case
Of the two filter rules, the rules of ggccp.js$match-case
are always used, even though I have changed the order of those two rules for each other.
When two rules have the same priority:
! base weight + $removeparam is not involved in the priority calculation
! Same priority as `$domain=example.com,removeparam=popunderp`
! Priority: 1 + 0 = 1.
||example.com^$removeparam=popunderp
! weight of the rule without modifiers
! Priority: 1.
popunderp
Of the two filter rules, the rules of popunderp
are always used, even if I change the order of those two rules for each other.
The rules with lower priority will be used:
! base weight + $removeparam is not involved in the priority calculation + important rules
! Same priority as `$domain=example.com,removeparam=popunderp,important`
! Priority: 1 + 0 + 1000000 = 1000001.
||example.com^$important,removeparam=popunderp
! weight of the rule without modifiers
! Priority: 1.
popunderp
Of the two filter rules, the rules of popunderp
are always used, even though I have changed the order of those two rules for each other.
Expected Behavior
It can be seen that the rules are used not according to any priority. Although I changed the order of rules and then tested again. I hope there will be a consensus to use rules based on their priority, like:
- Rules with higher priority will take precedence.
- Two filtering rules have the same priority, the upper filter rule will be used.
Screenshots
Screenshot 1:
Additional Information
No response
@tumatanquang, the calculation of priority actually works correctly. However, when we consider these rules:
||example.com^$removeparam=popunderp
popunderp
The rule with $removeparam
is not a blocking rule; it simply removes parameters. For this reason, we first search for blocking rules and then check for $removeparam
rules.
You can see why this approach was chosen here: link to GitHub issue.
TL;DR, if we were to first remove parameters from the request, the engine would not be able to find a blocking rule because the URL of the request would already be changed. This is why $removeparam
doesn't increase the rule's priority, just like $cookie
or $removeheader
. These modifiers add some post- and pre-processing for requests.
Regarding the statement:
If two filtering rules have the same priority, the upper filter rule will be used.
We have described how to handle these collisions here: link to AdGuard knowledge base:
When two rules with the same priority match the same request, it depends on the filtering engine implementation which one will be selected.
So we cannot provide a general approach for all our supported platforms because in some cases, the newest rule may be at the end of the list, so the engine should select the lower filter rule. Therefore, "it depends."
@105th Obviously, I open the issue here, the filtering engine I am using is AdGuard for Chromium
.
If so, you seem to have separated the block rule and modifier into two groups and neglected to compare the priority between the block rule and the modifier. No matter how high priority the modifier has, it is only given priority within the modifier group, which cannot be prioritized over the block rule group (as in the example The rules with lower priority will be used
above).
@tumatanquang Yes, this is why modifiers like $removeparam
itself don't contribute to the rule's weight. This is a kind of limitation when trying to encompass all modifiers within a single schema.
@105th But the act of calculating priority now treats all rules containing $removeparam
to the current priority × 0 = 0 priority, regardless of whether or not the rule contains other modifiers. As above, although I added $important
to increase priority and forced to prioritize using a rule containing $removeparam
, the actual behavior is that it has been ignored.
I think it is necessary to change the way priority is calculated with rules containing $removeparam
:
- For a rule that contains only
$removeparam
and does not contain any other modifiers, use a block rule that has greater priority than or equal to a rule that contains only$removeparam
. - But in cases where a rule contains
$removeparam
but contains additional modifiers that make the priority of the whole rule greater than the block rule, the rule containing$removeparam
will be forced.
Because the use of rules is determined by priority rather than by the order in which they appear, it makes sense to adjust the priority calculation behavior for rules containing $removeparam
as above. Because if not, you need to remove the block rule or whitelist that site from the blocking rule.