AdguardBrowserExtension icon indicating copy to clipboard operation
AdguardBrowserExtension copied to clipboard

Rule priorities

Open tumatanquang opened this issue 1 year ago • 4 comments

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:

Filter log

Additional Information

No response

tumatanquang avatar Oct 31 '23 16:10 tumatanquang

@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 avatar Nov 01 '23 21:11 105th

@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 avatar Nov 03 '23 15:11 tumatanquang

@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 avatar Nov 07 '23 14:11 105th

@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.

tumatanquang avatar Nov 08 '23 15:11 tumatanquang