Architecture discussion: Sandbox policies

[clelland]

As mentioned in https://github.com/w3c/webappsec-feature-policy/issues/282#issuecomment-486267212, there's interest in splitting different types of policies out into different pieces of FP. I'm going to try to define the 'sandbox policies' piece here, and leave the other two to their own issues. This issue can become the central bikeshed for that behaviour.

The key difference between sandbox policies and the other two pieces is that, while these can be applied by a document to child frames, they require an explicit opt-in acknowledgement by the document in that frame, or else the child document will not load. (This negotiation would not be required by documents with about:blank, data: or blob: urls)

Rough sketch:

Unlike document policies, but very much like iframe sandboxing, these policies are required to be enforced in child frames.

Sandbox features are all enabled by default in all browsing contexts, until disallowed by policy.

Resources can sandbox themselves with a response header (bikeshed: Sandbox-Policy) containing a list of features which will be disallowed. They can also further restrict any iframes with an HTML attribute (<iframe disallow>?)

As an opt-in negotiation, the browser would send a request header (bikeshed: Require-Sandbox-Policy) with a list of features which will be disabled. The response must be returned with a response header which includes at least those features. Without that, the document will not be loaded. (It should fail with the same mechanism used by Embedded CSP)

These policy declarations would not require allowlists or parameters; the policy would be applied to the document received with the response header.

Question: Does this design allow for existing sandbox features to be used without the opt-in negotiation?

[clelland]

One issue with <iframe disallow> is that is is not a counterpart to <iframe allow> in this model -- they would control different features, and so support different tokens.

[clelland]

Also, any new header here should probably be designed to fit within the Structured Headers model. I expect that a simple list of tokens would be sufficient:

Require-Sandbox-Policy: scripts, forms, pointer-lock
Sandbox-Policy: scripts, forms, pointer-lock

[ehsan-karamad]

At a high level, I wonder if this new policy type should either merge with, be included in, or replace parts of the CSP spec (I am in part repeating part of what clelland@ mentions in the first comment).

• Sandbox is already supported in CSP. I understand the CSP sandbox, similar to <iframe>'s is of "disable all unless specified" nature, whereas with Sandbox-Policy we do the opposite (only disabled the ones mentioned). However, we could perhaps reconcile the two by making the new Sandbox-Policy directives have a default flag state off and a directive of the form disallow-* to turn it on. For instance,

  Content-Security-Policy: sandbox allow-scripts disallow-feature-x;
  

  In this case, the active sandbox flags set should start off as having all bits corresponding to the conventional sandbox features on and all the newly to-be-proposed sandbox features as off. Then after parsing the header, the bit for scripts is turned off and the bit for feature-x- is toggled on.

• CSP has the Embedded-CSP which IIUC does a similar thing to the pair of Sandbox-Policy and Required-Sandbox-Policy. In essence:

  the embedder proposes a Content Security Policy as an attribute on the <iframe> element. This policy is transmitted along with the HTTP request for the framed content in an Embedding-CSP header. If the embedded content can accept that policy, it may do so by returning the proposed policy in a Content-Security-Policy header along with the response.

  My understanding is that it should currently support sandbox directive as well. Should we just reuse the same attribute and possibly add more details the current spec for it?

• What should an empty Sandbox-Policy: mean ? Does it restrict navigations?

[annevk]

I would not mind merging with CSP or CSP deferring to this new header for a superset of its functionality. CSPEE does make merging somewhat attractive I suppose.

Part of the motivation behind the sandboxing features (before part of Feature Policy) that @clelland mentioned was not opting into all the things sandbox gives you by default, but being able to only opt into a couple and perhaps a new thing. This would argue for some new syntax.

[clelland]

I've taken the ideas from this, and #299, and combined them into a proposal here: #328