
Loading…
[Request] Cascading permissions for dynamic filtering #1482
@hackel Thanks for your suggestion! I've never used Request Policy, but this concept of cascading permissions is really interesting and I would enjoy having it as well. I think if it is implemented, it would need to meet 3 requirements:
1) Be easy to understand and to use, in keeping with uBlock's biggest advantage over addons such as NoScript or Policeman
2) Be optional, so that the user can choose to allow or disallow cascading.
3) Not be a big drain on performance
In the UI, I would make this a new Dynamic Filter: imagine, along with inline-scripts, 3rd party scripts..., a cascade permissions setting which could be set globally or for the current host only.
In My Rules, something like example.com * cascade noop would allow all permissions set on example.com to cascade, so if the rules have example.com disqus.com * noop and disqus.com diqcuscdn.com * noop, the filtering will allow disqus.com to request disquscdn.com from the context of host example.com.
Such a rule would even allow for finer tuning if you wanted. For instance example.com diqcus.com cascade noop would allow only disqus.com permissions set on example.com to cascade: allow disqus.com to request disquscdn.com from the context of host example.com so long as disqus.com disquscdn.com * noop was preset, but would NOT allow google.com to request googleusercontent.com from host example.com even if google.com googleusercontent.com * noop was preset
There are some drawbacks though: the answers to the following (I don't know them) should be considered:
1) would it make the code much harder to maintain?
2) Could these settings be surfaced on the UI in a way that is easy to understand? In my UI implementation proposal above for instance, example.com * cascade noop can be set by clicking the dynamic filter for cascade permissions, but fine-grained settings such as example.com disqus.com cascade noop would only be possible from the My Rules tab of the add-on settings.
3) Would uBlock and uBlock Origin have to agree to adopt this feature since it requires adding to the My Rules syntax?
4) Is the performance hit, coding time and code maintenance time worth the benefit? The current setup is no less secure than what is proposed, and the inconvenience of manually allowing each new domain is only incurred once per host (assuming you save settings once things work)
Risky workaround: create global rules for cascades and on specific pages allow main script only. Example, search for 'youtube' here https://github.com/chrisaljoudi/uBlock/wiki/Dynamic-filtering:-default-deny:-useful-rulesets
With RequestPolicy, it was possible to define cascading permissions, such that a site could have sub-dependencies allowed with a single rule.
Example:
I allow disqus.com to load disquscdn.com (
disqus.com disquscdn.com * noop)If I allow site X to load disqus.com, then it should automatically permit disquscdn as well.
Currently, my workflow is very cumbersome:
1. Load site X.
2. See that it requires disqus.com, allow and reload.
3. See that it new requires disquscdn.com, allow and reload.
4. ...repeat until all dependencies are loaded.
With this enhancement, you would only have to do this once, eliminating steps 3+ on subsequent sites once you have determined the dependencies a first time. There are many other sites that have similar sub-dependencies, such as youtube.com and ytimg.com.
RequestPolicy's UI allowed "drilling down" to sub-sites. This could be achieved in a similar fashion. Clicking on a domain name in the left column would open up that domain and allow you to specify rules for that domain instead of the one you are currently on. There could be some kind of indicator in the uBlock UI that a top-level domain has includes from another domain.
Another option would simply be to display those sub-requests right below the parent that initiated them, indented. That way we keep all requests on a single screen. This wouldn't be very intuitive with the domain names right-aligned, but perhaps these domains could have a "+" toggle to the right of them, which allowed displaying the dependent domains below it with bracket around this collection. Just something to make it intuitive.