Re: [w3ctag/design-reviews] Feature policy control over sandbox features (#339)

Sorry for missing that, @dbaron -- let me see if I can get the TAG up to speed here:

The biggest news is certainly the evolution of feature policy, and splitting [Document Policy](https://github.com/w3c/webappsec-feature-policy/blob/master/document-policy-explainer.md) off of it. I expect that document policy is the place that sandbox-y features would eventually end up. The explainer goes into what that would look like, but I can answer any questions you may have on that. I believe that the processing model for document policy, specifically around required document policies, matches the existing sandbox quite closely.

Re: https://github.com/w3ctag/design-reviews/issues/339#issuecomment-494424185, we've certainly given that a lot of thought. I would suggest that these models make sense for different kinds of features:

1. Feature Policy / allow -- This is suitable for permission-gated features, and for features which are powerful enough that we want to support them on the top-level origin only, unavailable in third-party frames unless delegated. The key principle here is delegation, and granting access to frames which would not otherwise have it.

2. Document Policy -- This is most suitable for restrictions, changing the way that a feature operates away from the default, or blocking an API that should generally be available to all content. This is where I think that new sandbox-like features should go.

3. Traditional sandboxing / iframe sandbox attribute -- This is a set of features that are all turned off as a group with the 'sandbox' attribute, coupled with an opaque origin. In my ideal world, these features are all also controllable separately, through something like Document Policy (hence this TAG review request), and 'sandbox' represents a carefully thought-out subset of features which should almost always be disabled together in a sandbox. (Sandbox also does not require any kind of acknowledgement from the embedded site, so we need to ensure that disabling features doesn't introduce any potential vulnerabilities in embedded content)

As far as TAG feedback, I think that I'm looking for guidance in these areas:

1. Is this a good idea (Policy control over individual features, even outside of a 'sandboxed' iframe)?

2. When 'sandbox' and a newer attribute both try to control a feature, which should take precedence? I'm personally leaning towards "old attribute must win", to ensure consistent behaviour even in old browsers, but I'm not sure that makes sense in this case, since the way to disable features with the 'sandbox' attribute is to *not* mention them.

3. For future sandbox-style features, we're considering requiring the embedded site to acknowledge the policy, to mitigate security risks, refusing to load the site if the policy is not accepted explicitly. This is clearly a huge barrier to adoption, and existing sandbox features don't require that. Does the TAG have any opinions on when that explicit acknowledgment might not be required?

And yes, I'll be at TPAC, and Feature Policy / Document policy / sandboxing are on the [agenda](https://github.com/w3c/webappsec/issues/555#issuecomment-524589986) for WebAppSec.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/339#issuecomment-530509276