gorhill / httpswitchboard Public archive
Scopes don't seem to layering properly #227
Comments
|
Scopes are akin to totally separate sandboxes, there is no inheritance between scopes. This has been brought before, and roughly problem is that inheritance through scopes leads to intractable issues and complications. I think I will write a wiki to try to explain why. I did try to explain a few places. Here is what I wrote on Youtube, but I am not sure it is that clear, I don't think I can do better:
Now regarding your particular case, if you want Youtube to play everywhere, this is now possible with version 0.8.6.0: In the Ubiquitous rules tabs, there is now a "Ubiquitous whitelist" section, where a user can enter a list of hostnames which are to be wwhitelisted in all scopes. |
|
Hmm. It seems logical & understandable to me that the rules on the top layer overrule the ones underneath (in fact, it seemed the only possible way it could work), but I'm a programmer and not the average user, although this extension isn't for the average user. It seems to me that without inheritance, the domain and subdomain scopes are of limited use. Every time I create one I block my global whitelists, such as YouTube embeds, custom fonts, Wordpress embeds, etc., and I end up having to whitelist the same global items over and over. |
|
Consider the following: Say
(too many indents, github can't render properly the last three entries). The inheritance path of Now keep in mind this is the simplified logic, as I didn't represent above the strict-blocking logic, which is that a cell will not be allowed if any of type-for-any-hostname or hostname-for-any-type is blacklisted, including looking up at ancestor hostnames. Now imagine a third path of inheritance from the broader scope for that one Imagine a user changing the status of a cell in a broader scope, will any user really have the ability to mentally remember and thus predict all the side-effects the change will have to all the narrower scopes? Other consequence: a nice current side-effect of the inheritance model is that it is straigthforward to allow the whole matrix by simple whitelisting the So by design, rules for a scope are sandboxed to that scope, and then there are ubiquitous rules for those hostname-based rules you want to apply universally. |
|
Major refactoring. |
|
This is how µMatrix works, i.e. scopes are not sandboxed. |


My understanding of how scopes work is similar to layers of transparencies; when something isn't addressed by the most specific scope, HTTPSB should look through the blank spots to what's underneath.
An example on https://plus.google.com: On the * scope I have previously whitelisted YouTube so that embedded videos play everywhere:

Now I switch to the *.google.com scope to whitelist cookies, but look what happened: I've lost the whitelisting of YouTube:

Now I switch to the plus.google.com scope to blacklist talkgadget because it slows Google+ too much, but now I've lost the cookies AND YouTube. It also shows 7 changes were made to this scope, rather than 1.

What am I not understanding? I expect YouTube to be whitelisted on all scopes of google.com because it's whitelisted on *, and the more specific scopes for Google don't overwrite that. I expect plus.google.com to also be transparent to the lower levels and allow cookies and YouTube because they weren't overwritten either.
Thanks for the great extension!
The text was updated successfully, but these errors were encountered: