Document when to use allow- attributes vs. extend the sandbox attribute value set for iframes
travisleithead opened this issue · 9 comments
For details, see minutes (https://pad.w3ctag.org/p/2017-02-08-minutes.md) for w3ctag/design-reviews#147.
If the feature is top-level browsing context accessible by default, then use an attribute to grant permission in the iframe.
Otherwise, if the feature is universally available, but you want to disallow it under sandbox (and then optionally re-enable it), then you add a sandbox attribute value.
The difference is the level of privacy/risk the feature has to being universally available.
(See HTML spec for which attributes / sandbox directives currently fall into these buckets.)
See whatwg/html#2259 (comment) for a slightly more broad overview of the different restriction models on the platform. I agree transposing the contents of that comment into the document, expanding on the gaps in it, and add some advice would be pretty helpful for people.
As @triblondon points out in w3ctag/design-reviews#341 one of the further pieces of guidance that the document documenting this should have is how to name the features.
...one important piece of naming advice is when to use positive versus negative names, e.g., what is being allowed or what is being denied. We have a history of inconsistency here.
I should note that I did start to write text for this but I didn't get very far.
So far what we have is...
- If the feature has a corresponding permission, you should use a permission policy and mint a corresponding
allow-attribute. - If the feature is gated by user activation, and there is potential for abuse, consider extending the sandbox flags.
Secure contexts are mentioned in the previous section so maybe we should remove that mention - it shouldn't really be used for feature gating. Document policy, given the maturity probably shouldn't be mentioned. CSP I don't have the slightest idea what to write as guidance.
- and mint a corresponding
allow-attribute.
I would say that new feature-specific allow attributes (like allowfullscreen="") must not be added. Instead people should use the generic allow="" attribute which works with everything defined in permissions policy.
Discussed this in-depth during our plenary today - I think we are generally in favor of preferring allow="" and permission policies, but a concern was raised on writing a principle which depends on a feature that is only fully implemented in only one engine. Would love to hear what @hober @annevk think about this.
Firefox supports allow="". (And we're positive on the Permissions-Policy header.)
According to MDN, Safari also supports allow="" since 2018.