-
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: ... 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:
Or:
If I had that, I could (for instance)
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. :) |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments
-
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 |
Beta Was this translation helpful? Give feedback.
-
It was requested before at least once: uBlock-LLC/uBlock#1482 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
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. |
Beta Was this translation helpful? Give feedback.
-
Here's an idea for syntax:
Regarding implementation, I'm thinking in terms of parsing filter rules as a graph (not a DAG, in general?) -- every rule allowing
becomes
Then, the current code can be used for the actual filtering. Huh. I wrote:
One could say the proposed feature does the same -- the difference is, it's reapplied automatically. |
Beta Was this translation helpful? Give feedback.
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.