search

w3c / webappsec-permissions-policy

A mechanism to selectively enable and disable browser features and APIs
https://w3c.github.io/webappsec-permissions-policy/
Other
399 stars 155 forks source link

Feature policy + sandbox review notes #194

Open domenic opened 6 years ago

domenic commented 6 years ago

Reviewing https://github.com/WICG/feature-policy/blob/master/sandbox.md, in particulra this revision.

My biggest concern is about the things disabled in sandbox but with no counterpart in the list of policies. These are:

These omissions make the statement

will apply a container policy to the frame as if the <iframe> tag had been written like

not quite accurate, I believe.

There is also the distinction between allow-top-navigation and allow-top-navigation-by-user-activation, which I don't see captured in the explainer's "top navigation" feature.

clelland commented 6 years ago

Thanks @domenic (and sorry this took so long to get back to)

I believe that all of those things should continue to be blocked by sandbox; they're currently blocked with no way to re-enable (except for the note about autofocus/autoplay, but see below). That does make this a bit more difficult to handle elegantly, but probably not impossible.

The easiest thing to do would be to do nothing. Leave those behaviours of the sandbox attribute as-is, and say that those features are not re-enablable. I think this is roughly equivalent to the opaque-origin behaviour of sandbox, which is also a 'feature' that can't be overridden with another policy declaration.

<iframe sandbox>

becomes shorthand for "Give the frame an opaque origin, disable these three-or-four features unconditionally, and construct a container policy that disables the rest of them".

We then have two questions:

  1. Which if these would be useful as a feature outside of sandbox?
  2. Should a feature policy be able to re-enable any of them in a sandboxed frame?

For (1), I can definitely see the usefulness of restricting document.domain. Preventing other-context-navigation could also be useful. We've considered making 'local storage' generally a feature, but I don't think that's what your point above refers to.

Form autofocus would be a really tiny feature -- it sounds better to consider that part of the 'script' feature, if that's what re-enables it.

Media autoplay is currently a feature; it would be off by default in sandboxed frames by virtue of them being cross-origin with the main frame, I believe. I don't think that allow-scripts should re-enable that by itself; the autoplay policy should still take precedence.

Answering (2) may require more input from security folks. I'd like to get some insight into why there was never an "allow-*" sandbox attribute token defined for them.

There is also the distinction between allow-top-navigation and allow-top-navigation-by-user-activation, which I don't see captured in the explainer's "top navigation" feature.

This was an oversight; it's a bit tricky to add, and I'm not sure if one can override the other (what happens today if you have two nested sandboxed frames, each of which declares one of those flags, but not the other?) but I'll put some text to that effect in the doc.