Document Policy and Sandboxing

[mikewest]

In https://w3c.github.io/webappsec-feature-policy/document-policy.html#relation-to-feature-policy, you suggest that a core distinction between FP and DP is the cascading inheritance model. In https://w3c.github.io/webappsec-feature-policy/document-policy.html#relation-to-sandboxing, you suggest that DP can pull in the features that sandboxing controls.

One feature of <iframe sandbox> is that the sandboxing flags on a given browsing context are enforced on nested browsing contexts, and auxiliary browsing contexts created from the sandboxed context. That model seems both necessary to make the sandbox meaningful, but also counter to the mechanism described in DP with regard to inheritance.

Is there a conflict here?

[clelland]

<iframe policy>, much like <iframe csp>, works by setting a 'required policy' on the iframe, which does cascade down to its nested frames. The intention is that this should work very similarly to <iframe sandbox>.

One difference is that documents currently need to opt-in to any required policies, by setting their own policy to something compatible with it. Existing sandbox features don't need that; they are set unilaterally by the embedder, so we would need to have exceptions to the opt-in requirement, where some policies are automatically applied if required in a frame, even if the document doesn't specifically request it.

I expect that auxiliary browsing contexts are going to be handled in exactly the same way as sandbox as well (though that's not written up yet): if the sandbox propagates to auxiliary browsing contexts flag is true, then document policies (and sandbox) will be reset in popups, otherwise it will inherit from the opener.