Scopes don't seem to layering properly

[stormy-henderson]

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!

[gorhill]

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:

First complication is UI: no 2d representation fits having scope inheritance. If there was scope inheritance, there is no way around having to visually see scopes from which something can be inherited or else that requires a user to keep an accurate mental image of those hidden scopes so that a user would be able to predict what happens when a cell is clicked.

Another complication is a user would also have a hard time figure the inherited state of a cell, as a single cell in the middle of the matrix could inherit from more than two parent cells: the domain on the left, the type on top as is currently, and whatever else in the broader scopes -- which is not visible. It's just impossible to figure and predict for a user.

Consider that currently a cell in the middle inherits from two parent cells, the hostname and type. There is already a complication which is: from which parent cell a graylisted cell in the middle inherit, if these two parent cells have opposite state, one whitelisted and one blacklisted? This is currently taken care using the "strict blocking" option: if it is on, type wins, if it is off, hostname wins.

Now this sort of complication would become compounded if there was yet more inheritance paths, to the point where no user would be able to make logical sense of the state of the matrix.

And actually, thinking about it, seeing the scopes as totally separate sandboxes is easier to explain and understand for most users.

In short scope inheritance led to what I call over complications, which was opposite of what I am trying to achieve.

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.

[stormy-henderson]

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.

[gorhill]

Consider the following: Say script for www.youtube.com is graylisted in plus.google.com scope. Now the current code will, for one single net request of a script file:

• Is script for www.youtube.com whitelisted?
  • If yes, allow script
  • If no, is script for www.youtube.com blacklisted?
    • If yes, block script
    • If no, scriptfor www.youtube.com is graylisted, inherit from higher precedence cell
    • Is script for youtube.com whitelisted?
      • If yes, allow script
      • If no, is script for youtube.com blacklisted?
        • If yes, block script
        • If no, scriptfor youtube.com is graylisted, inherit from higher precedence cell
        • Is any type for any www.youtube.com whitelisted?
          • If yes, allow script
          • If no, is any type for www.youtube.com blacklisted?
            • If yes, block script
            • If no, any type for www.youtube.com is graylisted, inherit from higher precedence cell
            • Is any type for any youtube.com whitelisted?
              • If yes, allow script
              • If no, is any type for youtube.com blacklisted?
                • If yes, block script
                • If no, any type for youtube.com is graylisted, inherit from higher precedence cell
                • Is script for any hostname whitelisted?
                  • If yes, allow script
                  • If no, is script for any hostname blacklisted?
                  • If no, script for any hostname is graylisted
                  • Is the all cell whitelisted?

(too many indents, github can't render properly the last three entries).

The inheritance path of script for www.youtube.com translates rather well into a well ordered 2.5d- matrix (.5 because of the inheritance to ancestor hostnames shown as grouping in the matrix).

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 script @ www.youtube.com cell. If script for www.youtube.com is graylisted, where to look first? script for youtube.com in the current scope or script for www.youtube.com in the broader scope? And regardless, since there is strict-blocking for the 2.5d-matrix, user could expect to have it as well for the 3.5d matrix (which is what inheritance through scopes is). Who would be able to manage mentally such complication?

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 all cell (useful with a narrow scope to skip having to figure the proper set of rules to make a site work). If rules from broader scopes bleed into the narrow scope matrix, this feature is at risk, as the current behavior is no longer guaranteed.

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.

[gorhill]

Major refactoring.

[gorhill]

This is how µMatrix works, i.e. scopes are not sandboxed.