Support redirect-only rule in DNR

[Yuki2718]

Namely $redirect-rule working as redirect-if-blocked. uBlock Origin uses almost 600 of $redirect-rule while AdGuard 40+ if limited to Base filter. The main use of this are:

1. $script,redirect-rule=noopjs,domain=blog24.me (in Base filter): some websites frequently change domain or path to detect anti-block or ad-reinjection and in such cases this sort of rule is often used. If done by $redirect the rule breaks the sites as blocking all scripts.
2. /ads-prebid.js$script,redirect-rule=prebid-ads.js (in uBlock fitler): Some bait paths for anti-block/reinjection are used by many sites and in such cases this sort of rules are useful. It's possible to replace by $redirect; however, EasyList regularly removes rules used to detect blocker, then the rule become obsolete, or even worse can rather cause detection as the rule doesn't work on all sites. It's practically impossible for us to monitor all such changes.

[gorhill]

You can see all the redirect-rule filters which are rejected when compiling filter lists into DNR rules at uBO Lite build time: https://github.com/uBlockOrigin/uBOL-home/blob/main/chromium/log.txt (search for redirect-rule).

Essentially, this is a redirect action which does not compete with block action as those redirect directives are only looked up once it has been determined that a network request is meant to be blocked.

[Rob--W]

Could you clarify the exact feature request here? Below I specify the current behavior of DNR. As you can see there, the "redirect" action already has lower precedence than "block". The precedence of actions can be overridden with the "priority" property of a rule, if you want to deviate from the default action precedence. For example, if you want to have redirects instead of blocks on specific websites.

What functionality are you looking for that is not possible with the current DNR API?

Summary of DNR action precedents

For context, the action precedence rules within an extension and across extensions is documented at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/declarativeNetRequest#matching_precedents

Summarized, same-priority rules have their actions executed in the following precedence (first one present wins):

1. allow, allowAllRequests
2. block
3. upgradeScheme
4. redirect
5. modifyHeaders

When multiple extensions specify a matching action, the chosen action is determined by the following precedence (first one wins):

1. block
2. redirect, upgradeScheme
3. allow, allowAllRequests

[gorhill]

Filter lists contains many generic filters:

/ad_common.
/ad_code.
/abc.gif?

There are many thousands of such generic patterns which are meant to result in a block action.

Some websites are known to create 1st-party resource which match any of these generic patterns, we refer to these as bait, and their purpose is to detect content blockers -- and they will pick any of the generic patterns and can change at any time from one generic pattern to another one.

For these websites, we create generic redirect directives to ensure that what would be otherwise blocked is redirected to a local resource to mimic that the network request succeeds. These redirect directives are looked up only in case a network request is blocked, otherwise they are ignored.

The compatibility issue with DNR's redirect is that, speaking for uBlock Origin/AdGuard, redirect actions do not compete with allow/block actions, there is no need for precedence, they are an extra step to perform after evaluating whether a network request is allowed or blocked.

The only way to mimic the redirect-if-blocked approach with DNR would be to create as many redirect rules as there exist generic block filter with distinct pattern.

A redirect-if-blocked would require a new approach for the DNR:

Precedence:

1. allow, allowAllRequests
2. block

If result is block then:

- redirect-to-local-resource

Else (result is allow, allowAllRequests):

- redirect-transform
- upgradeScheme
- modifyHeaders

The issue here is reminiscent of #468, in which the issue is that with the DNR API, all rules compete with each others, whereas in uBO/ADG, there are directives to look up and apply once the allow/block status has been evaluated -- we call them modifiers -- they do not compete with allow/block, they are directives which instruct what to do next -- hence why it was natural for uBO/ADG to process all directives to remove query parameters at once.

[ameshkov]

The issue was discussed during the WECG in-person meeting.

First of all, this type of rule conditions is still very popular in filter lists and the usage continues to grow. It grew from 600 to almost 800 rules in uBlock filters already. It is very important that DNR provided a way to implement this functionality in MV3.

The suggested way forward is to provide a new type of condition (as the requested functionality is effectively a condition and not an action):
matchedRuleActions: RuleActionType[]

This condition means, that the rule should be applied only when the request was matched by a different rule with action from the matchedRuleActions list that does not have a matchedRuleActions condition itself (to prevent any loops) and that has lower priority (see DNR rules prioritization).

In this case the $redirect-rule rules can be converted to DNR rules as in the following example:

$script,redirect-rule=noopjs,domain=blog24.me

Will be converted to:

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "redirect",
    "redirect": { "extensionPath": "/redirectResources/noopjs.js" }
  },
  "condition": {
    "initiatorDomains": ["blog24.me"],
    "resourceTypes": ["script"],
    "matchedRuleActions": ["block"]
  }
}