Re: [w3ctag/design-reviews] Review request for Feature Policy (#159)

Thanks for bringing this to TAG review!  We're collecting feedback here ahead of opening issues:

* Glad to see you have an explainer!
* The cascade effect of parent header > `allow` attribute > iframe header is confusing.  For example, if a parent document defines `vibrate: ["self"]`, the iframe has `allow="vibrate"`, and the iframe policy header has `vibrate:[]`, then we *believe* this will prohibit vibrate in the iframe, but since the allow attribute is more visible to the developer this may cause significant head scratching.  We wonder how compelling are the use cases for the attribute, given the expressiveness of the header?
* If an iframe is permitted to use a feature but chooses to disable it in its own header, it presumably retains the power to re-enable it on an embedded iframe using an attribute, whereas if the feature was disabled by a policy in the parent document, it will not be allowed to re-enable it on a nested frame. Should there be a requirement for the UA to issue an expressive error if an allow attribute attempts to enable a feature that has been prohibited at a higher level?
* The allow attribute and the HTTP header have very different granularity. While the header takes a list of allowed origins, the attribute's syntax is essentially sugar for `featurename:["*"]`, with no ability to be more granular.  We recognise that this is similar to the relationship between the CSP header and the `sandbox` attribute, but it feels very inconsistent, and a higher than necessary learning curve.
* Under the default allowlists header, the phrase "The feature is allowed at the top level by default, and when allowed, is allowed by default to documents in child frames." is rather confusing, and suggests to us that perhaps the `allow` attribute is *required* in order to extend a feature-policy defined in the header, into child frames (which doesn't make a lot of sense because in that case there'd be no reason to have multiple origins listed in the header policy).  Perhaps this is a hangover from a previous version of the spec in which there was a disable attribute as well as the enable (now allow) one?
* The default behaviour of new features added in the future must depend on the shipping status of the feature in the platform. For example, if a `document.write` policy is added it must "fail open" in order to avoid breaking existing websites, and therefore the only safe scenario in which a feature could be introduced with a closed default status if is if support for the feature in feature policy is a required part of shipping the feature itself.  Is there a mechanism for tying together the introduction of a feature in the platform and the addition of a new token to this specification?  (see also registry point)
* The explainer includes reference to the ability to disable, as well as enable, features, but the current spec appears to only support allowlists
* The terms used in the Explainer and the spec are not consistent. Some examples in the explainer use `enable` and `disable` attributes, whereas the draft spec includes only `allow`
* There appears to be some overlap between the `sandbox` and `allow` attributes. Have the designers considered migrating `sandbox` directives to Feature Policy? This might enable equivalence between these, and eventual deprecation of sandbox in favour of allow:
    
    `<iframe sandbox="allow-forms allow-modals" allow="geolocation" ...>`
    `<iframe sandbox allow="forms modals geolocation" ...>`
    
    With the transitionary, compatible use of:

    `<iframe sandbox="allow-forms allow-modals" allow="forms modals geolocation" ...>`
    
* This spec introduces a new registry of names. What is the strategy for maintaining consistency between the [Permissions API registry](https://w3c.github.io/permissions/#permission-registry) and naming and the feature names in this spec? 
* Related, we acknowledge that registry maintainence is an unresolved issue in the platform. We're going look into development of a unified solution for many specs and will ping back here if we make progress.

-- 
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/159#issuecomment-297920860