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

> Hey @clelland,
> 
> Thanks for filing for a review. A few questions from today's F2F discussion with @torgo, @sideshowbarker, @ylafon, @torgo, and @alice.
> 
> This work appears to be a follow-up from our suggestions in #159 that the allow attribute superset the set of sandbox attributes. Thanks for doing this.
> 
> * What's the interaction between a non-null `sandbox` policy and `allow`? E.g., if sandboxing prevents something, but `allow` enables it, who wins? The processing order doesn't seem to be specified.

Sandboxing only prevents things by *not* mentioning them -- an example of sandbox preventing modal dialogs, for instance, and FP enabling it would look like

    <iframe sandbox="allow-scripts" allow="dialogs">

I believe in that case the developer would expect the feature to be allowed. The model, in my head at least, is that:

1. The presence of the sandbox attribute disables a number of features in the frame
2. The sandbox attributes are able to re-enable those features (classic behaviour)
3. After this, the "allow" attribute is able to re-enable any still-disabled features, or further refine the set of origins where the features will be enabled (in the case of navigation in an allow-same-origin frame)

Does that make sense? (TAG input appreciated here, at least for ergonomics. This matches the way that FP handles the legacy `allowfullscreen` attribute, FWIW)


> * Do you have data about the usage of sandbox attributes? On what timeframe would a deprecation be possible?



> * As a meta point, the explainer doesn't really address the question of why this solves an important problem for developers. Given that this might make controlling feature use easier and provide a single way to do it, that seems worth calling out.

+1, will do.

> * An aside: it seems like there's some overlap between `document.featurePolicy.allowsFeature()` and the Permissions API. How is that going to be resolved? Are the semantics the same? Which one should a developer use? Are events sent to `document.featurePolicy` to note when things are relaxed or tightened?

They share some identifiers (permission-features are a subset of feature policy features), but the semantics are different -- the permissions API will only return true if the user has explicitly granted permission, while the JS API (#292) will return true if access the feature has been allowed by the browser / embedding page (and hence whether a permission prompt could even potentially be shown to a user.) I would expect developers to use the FP API to decide whether to even advertise that permission controlled features could be used -- for instance, deciding whether to include a "turn camera on" button on a page, based on the embedding context. If allowed by FP, then the permissions API would could be used to present the user with a prompt, and determine the user's response.

(This should probably be continued on #292, if there's more to discuss, or even on https://github.com/w3c/webappsec-feature-policy/issues/166)

> * What, if any mechanism, is being proposed to ensure that `allow` attributes continue to be a strict superset of `sandbox` policies? Are you asking the TAG to stay vigilant here? Should it go into our design guidance?

Good question -- unless we can enshrine it in specs, TAG vigilance might be the way we have to go -- any proposals for new sandbox flags should probably prompt the question "Should this just be a policy-controlled feature instead?", quickly followed by "Should we disable it by default in sandboxes?" I suspect that the answer to the first question is going to be yes in most cases.

-- 
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-461115034