Opt-in negotiation for new sandboxy features

[clelland]

@annevk @mikewest

Continuing discussion from https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-467015708:

Sandboxing: unless it's one of the types of sandboxing we already allow, I think we should have an explicit opt-in negotation with those being sandboxed. We should not allow embedders to decide the control flow beyond the extent to which they already have that ability. And we should probably also enable embeddees to protect themselves against existing forms of sandboxing (by turning into a network error if something is imposed upon them they do not like).

This sounds a lot like the required reflection of CSP Embedded Enforcement; can we leverage that in any way?

That is, if the parent frame includes the child with an iframe element like

<iframe src="..." allow="document-write 'none'"></iframe>

Then the request for the child will be sent with the request header

Required-Feature-Policy: document-write 'none'

and the child must be returned with a Feature-Policy response header which also blocks the feature, or else a network error will be generated instead.

Spec-wise, I suspect we'd need steps like

For outgoing requests:

1. Generate the inherited policy for the prospective new document, given its origin.
2. For each feature that requires opt-in, if inherited policy[feature] is false, then add "feature 'none'" to the Required-Feature-Policy request header

(Repeat for a new origin if the response is a redirect?)

For incoming responses:

1. Process the response policy
2. For each feature that requires opt-in, if inherited policy[feature] is false, and the declared allowlist for feature is not 'none', then the response is blocked. (Check how CSP blocks responses and do something similar)

Does that make sense? I can write it up as an actual spec PR if the idea is at least sound.

Some other questions:

• Does Required-Feature-Policy need to be Sec-Required-Feature-Policy?

• Should there be an Allow-Feature-Policy-From as well?

[annevk]

It makes sense, but I'd still vastly prefer making this a separate category instead of trying to shoehorn it all into a single policy mechanism with various booleans controlling what happens for a given string.

You need Sec-. I'm not sure what Allow- would be for. That would take an origin or some such?

[clelland]

Yeah, Allow-Feature-Policy-From would be like Allow-CSP-From, and would take an origin which is trusted to set the policy unilaterally.

I agree about defining discrete categories, rather than a host of booleans. (#282) The steps above couId be written either way, I hope.

[clelland]

Closing this idea in favour of #300