When using (auto create) domain level scope, how do I create a rule that auto aplies to each scope when it is created?

[cezarmoise]

In my specific case, I use an extension (Pocket) for chrome that creates a frame. White-listing the site (getpocket.com) doesn't work, because frames are blacklisted by default.

I tried to add the frame to the global whitelist, and, if I change the scope to global from domain, it works, but then I lose the domain specific rules.
I expected that domain scopes will automatically use whatever rules they find in the global scope, but that is not the case.

One solution would be to remove frame from the blacklist, but that is not something I'm keen on.
Is there a way to specify an exception to the blacklist, i.e. blacklist every frame except the ones coming from this domain?

DOMAIN SCOPE

GLOBAL SCOPE

If you make the default frame rule to be greylisted (pale red), rather than blacklisted as it is now (dark red), your getpocket.com rule will extend to the frames column.

Meanwhile, if you don't allow any domains with a frame inside them, they will still be blocked via greylisting and the blacklisting rules you have enabled..

[jankkm]

I have a similar problem:
In global scope I whitelisted everything that embedded youtube videos need to play properly. But if a domain-level auto scope is created it does not include this whitelisting. I think only blacklisting is included in auto scopes but whitelisting is not. Am I wrong?

[gorhill]

I think only blacklisting is included in auto scopes but whitelisting is not

The code which auto-create a scope attempts to transfer rules from global scopes which are relevant to the local scope.

"Relevant" means whatever rules in global scope which hostname match the hostname of a request made in the local scope. And that's the problem, when the scope is created, there are no requests yet recorded for the local scope, hence no relevant rule is found, except that is for the generic one (the top row of the matrix which matches all hostnames). It's a chicken and egg problem.

One solution is to copy all rules from global scope to the narrower scope, even the ones which may be completely irrelevant. Depending on how HTTPSB is used, I can picture this leading to rule bloat in the user data.

The other solution is to evaluate global scope at the same time as local scope, but the problem with this approach means an (significant I fear) added overhead to the matrix filtering engine, an area which needs to be executed in time-critical context (the browser is blocked).

So this is a difficult problem.

One solution is to copy all rules from global scope to the narrower
scope, even the ones which may be completely irrelevant. Depending on
how HTTPSB is used, I can picture this leading to rule bloat in the user
data.

I think this is the solution which should be preferred. I suggest to
offer it as an option combined with an explicit warning to avoid too
many global rules.

[gorhill]

I think this is the solution which should be preferred.

That sure would solve an issue which is brought back regularly, and I sure agree that it sucks currently. That would be a big improvement in usability. I have closed that kind of requests before as "by design", but I can no longer ignore it.