[TAG] Unify with sandbox attribute?

[slightlyoff]

From TAG review

There appears to be some overlap between the sandbox and allow attributes. Have the designers considered migrating sandbox directives to Feature Policy? This might enable equivalence between these, and eventual deprecation of sandbox in favour of allow:

<iframe sandbox="allow-forms allow-modals" allow="geolocation" ...>
<iframe sandbox allow="forms modals geolocation" ...>

With the transitionary, compatible use of:

<iframe sandbox="allow-forms allow-modals" allow="forms modals geolocation" ...>

[clelland]

Yes! There has been some agreement that most sandbox features could/should eventually move to feature policy. We haven't specifically proposed this yet, but that's mostly just trying not to distract from the conversation around the basic mechanism of Feature Policy first.

I think that the fundamental feature of sandbox -- to isolate frames as if they were cross-origin from all other frames -- will remain, but that almost all of the flags could be migrated. (I like the suggestion for the transition state, btw)

I'll put a note in the "other and related mechanisms" section of the spec, but the actual migration proposal should probably be written up separately. (I though there was already an open issue for this, but I can't see it now).

[clelland]

I've written up a proposal for this here: https://docs.google.com/document/d/1KsCFmugEAZf1LT_C3ZCj8FfkkljZV3D3EoMenX7yQto/edit#

Also, I've just submitted a PR to update the spec with a longer discussion of the current relationship between sandbox and FP: #82

[annevk]

Does Feature Policy have the same model as sandboxing when it comes to navigation and opening new windows and such? Is that specified?

[clelland]

Tee navigation model should be the same, by design (any discrepancies should be resolved in favour of matching sandbox behaviour, I think)

The pop-up model is currently different, but we should find a way to unify them.

Currently:

1. New windows opened by sandboxed frames inherit the opener's sandbox, unless the opener was granted "allow-popups-to-escape-sandbox" by its embedder.
2. New windows are considered top-level browsing contexts by Feature Policy, and therefore get a default policy. (Essentially granted all features).

I think that the second point could be improved, so I've suggested that popups which do not disown their opener should inherit their opener's feature policy. This is obviously different than the sandbox approach, so now I'm wondering if we need to do more.

Generally, popups -- if allowed at all -- should be as restricted as their openers. However, there should be some way for sandboxed / restricted content to open new windows to unrestricted content. (Think of clicking on an ad in an iframe opening a new window to the advertiser's home page)
This should be considered safe as long as the unrestricted content isn't be able to communicate back to the restricted frame.

The issues I see are these:

1. If you allow unsandboxed popups to retain a channel to their opener, then you may have a sandbox escape
2. If you allow same-origin pop-ups to use BroadcastChannel, then an popup can communicate with its opener even without window.opener being present.

So I think that we need to do a few things:

1. Make the change proposed, to require popups to disown their opener in order to get a default feature policy.
2. Also require popups opened by sandboxes to disown their opener in order to escape the sandbox.
3. Make the ability to receive messages over BroadcastChannel a policy-controlled feature

At that point, I think we could merge sandbox into feature policy. We would make all of the sandbox features, including 'allow-popups-to-escape-sandbox', into policy-controlled features (with default allowlist of *, to be available in all frames by default). The rule for obtaining a default feature policy (which would also escape the sandbox) would be:

• opener is granted the 'allow popups to escape sandbox' feature by its embedder, and
• popup disowns its opener.

The sandbox attribute itself would remain (for backwards compatibility), and would be the mechanism to cause the frame to have an opaque origin.

Does this make sense? It's possibly a breaking change to make that noopener change to sandbox, so we'd have to evaluate that. Without that, we could do something like treating sandbox-features in feature policy different than other features, or requiring rel=noopener from outside of a sandbox, but just allow-popups-to-escape-sandbox from inside of a sandbox.