Use cases are not detailed enough

[annevk]

It's unclear why direct script access is a problem, but being able to meddle with storage or BroadcastChannel and influence each other that way is not.

We've found time-and-time again that side channels are problematic. It's not clear why they'd be suddenly okay now.

[dtapuska]

Perhaps this is about the way you may be thinking about this. I am not claiming any additional security benefits from this, other than solving the sandbox="allow-scripts allow-same-origin" removal of sandbox flags issue. The benefits come from some of the guarantees, scheduling improvements the user agent can provide.

Yes local storage and broadcast channel can always be used to access sensitive data. And I think sandboxing addresses these because of the opaque origin. We've seen before that web authors still want access to local storage via "allow-same-origin" sandbox flags though. This just provides them with another tool to control the type of access they want to allow.

I think powerful features such as local storage, cookies and broadcast channel should be controlled via document/feature policy separately.

[annevk]

I guess in that case it really ought to go through "document policy" as that's meant to give that kind of sandboxing functionality (while not giving attackers new tools).

cc @clelland

[dtapuska]

We bounced around this attribute for a while whether it would be a feature policy, then a document policy. (there is a section covering that in the explainer). The problem with document policy is around the fact the attributes inherit across each document. ie. so it would work as set, each iframe would end up in its own agent cluster instead of just a single subtree set at a point. ie. inheritance makes it ugly. As well as forcing opting in doesn't work too well.

I spoke with Ian at great lengths about this when I pivoted away from the feature policy version of this explainer.

[annevk]

To some extent it's understandable, but by not being part of that framework it makes different decisions about what kind of control flow alteration are acceptable across origins, which is not great.

[clelland]

Yeah, it doesn't really fit feature policy, as it's difficult to define what it does in terms of a feature that you can disable in one frame, and is then disabled in all descendant frames of that one -- you can't just have it be "is allowed to script its parent document", or else every subframe is also blocked from scripting it's own parent as well.

Document policy is a better fit, though still not perfect, since you can disable it in just one document, from that document. It still has the sandbox-like model that if you force the policy on a child frame, then that at policy it has to be enforced on all descendants of the child as well, so that doesn't really work.

Really, this feature is about creating a different sort of frame boundary, between precisely two frames, and saying that all access across that boundary needs to be treated as cross-origin. On either side of the boundary you should be able to have same-origin semantics, and I haven't found a clear way to describe that with either feature or document policy.