Dependent/Conditional filters

[reitzig]

Currently, filter rules can use host domain, target domain, and resource type as criterion. As a user of "uMatrix mode" (i.e. globally block all 3rd-party material, white-list explicitly), this has turned out to cause repetitive patterns of allow-and-reload for some service providers that scatter their ever-same resources across several domains that appear one by one in uBO.

Some examples:

• Discourse:
  
  

• Youtube Embeds:
  
  
  
  (And often I'll need another round for gstatic.com or video won't play.)

• Google Recaptcha:
  
  
  

... and the list goes on: Gist code embeds, Shopify (ugh...), Disqus, ...

The common denominator is: when I white-list the "main" target domain, I want all the other required ones to be allowed as well. That is, for example, I want to be able to configure rules like this:

When discourse-cdn.com is allowed (for this host domain), also allow kxcdn.com.

Or:

When youtube.com is allowed, also allow google.com
When google.com is allowed, also allow gstatic.com.

If I had that, I could (for instance)

• globally allow discourse-cdn.com (because I trust Discourse) but only allow kxcdn.com when it's used by (or together with) Discourse (because I don't trust kxcdn as much); or
• allow discourse-cdn.com on demand when I need it, and instantly get kxcdn.com as well, thus avoiding repetitive reloads.

I don't have a concrete proposal for text-file syntax for this, but I'm sure that's not the limiting factor so I'll leave it at that. :)

[iam-py-test]

That seems very difficult to program. While I see how that could be helpful, it feels like it would be a lot of work for @gorhill
I have programed a few browser extensions (though nowhere as complex as uBlock Origin), and from my experience that would be difficult
Of course, @gorhill and the team might know a way I don't, and if they do & are willing to put the time in, I definitionally see that this could be beneficial.

[ghost]

It was requested before at least once: uBlock-LLC/uBlock#1482

[gorhill]

This is essentially what uMatrix's recipes were. They never really took off, so it appears only a minority of people cared about these, and that was for an extension with a relatively low user count compared to uBO. I don't see burdening myself with throwing a lot of code at a feature which would be used by a minority of users.

[reitzig]

I can't comment on how much work it'd be -- depends on the current codebase -- but I'll note an imho central difference between recipes and what I have in mind:

Recipes are never automatically imported, they always require that you explicitly import them. You may inspect all the rules by expanding the recipe.

When you import this recipe (let's say into the example.com scope), temporary rules will be created in the current scope,

That means I can't actually solve the use cases I mention in the OP: either, I have to apply the recipe manually for each scope, or I have to apply a recipe with global rules (which adds little value indeed).

Recipes were a macro for creating rules; conditional/dependent rules/filters would be different.

[reitzig]

Here's an idea for syntax:

// On any page, if youtobe.com is allowed, allow ytimg.com
*[youtube.com] ytimg.com * noop

Regarding implementation, I'm thinking in terms of parsing filter rules as a graph (not a DAG, in general?) -- every rule allowing youtube.com gets a pointer to the rule given above -- which can then be pre-processed (incl. localized updates in change of added temporary rules) into a flat list of filter rules by graph traversal. For example,

*[youtube.com] ytimg.com * noop
patreon.com youtube.com * noop
kickstarter.com youtube.com * noop

becomes

patreon.com youtube.com * noop
patreon.com ytimg.com * noop
kickstarter.com youtube.com * noop
kickstarter.com ytimg.com * noop

Then, the current code can be used for the actual filtering.

Huh. I wrote:

Recipes were a macro for creating rules; conditional/dependent rules/filters would be different.

One could say the proposed feature does the same -- the difference is, it's reapplied automatically.