(Yeah, that should get updated too)
TAG review statusPending - TAG seems to be generally happy with the proposal, with remaining issues around Permissions-Policy focussed on the need to define a more formal feature registry.
Interoperability and CompatibilitySince the Feature-Policy header has already shipped, and has been deployed by sites, there is a degree of compatibility risk here. We are planning on mitigating this by accepting both headers in Chrome for some time, until we see significant decline in the use of the Feature-Policy header. Where there is conflict, the Permissions-Policy header will take precedence. The interop risk is lessened by the fact that Firefox has not yet shipped the Feature-Policy header, and would no longer do so now that the spec has changed. This should incentivize developers to switch to Permissions-Policy once it is available in Chrome, in order to get interoperability between browsers. We also believe that the change in header semantics is largely web-compatible. Analysis of use in the wild shows that Feature Policy is generally used in two ways:
- The Feature-Policy header is almost always used to disable features, with an explicit allowlist of 'none', and no iframe attributes are used to override that.
- These cases will continue to work as before, with the added safety that even a malicious actor who could manipulate the DOM can no longer delegate disabled features to subframes.
- When features are delegated to frames, they are almost always delegated frame-by-frame with the allow attribute, and not mentioned in an HTTP header at all.
- This case will also continue to work exactly as before.
That being said, we do have the option of *not* changing the behavior of the Feature-Policy header, and only shipping the new semantics as part of the Permissions-Policy header. That would be 100% backwards-compatible, but at the cost of giving developers two different models to consider when deploying Permissions Policy. Having two headers control the same features, in a subtly different way, may lead to confusion, and will mean that the transformation between the legacy CSP-style Feature-Policy header and the structured Permissions-Policy header is not purely mechanical.
) The initial impetus for this change came from a request from Firefox. Like Safari, Firefox does not currently have support implemented for the existing Feature-Policy header.WebKit:
No signal (https://lists.webkit.org/pipermail/webkit-dev/2020-September/031428.html
) Safari implements the allow attribute, which is essentially unchanged by this update, but does not currently support the (now legacy) Feature-Policy header.Web developers:
) There is support (for example, the link above) from developers for the header semantics change; a number of developers have expressed the view that blocking a site in the HTTP header should not be overridable in markup.
The biggest challenge will be that developers will eventually need to rewrite any existing Feature-Policy headers in the new structured syntax. Documentation will help, tools could be used to translate from one syntax to the other (this is a very mechanical change).
The behavioural change to the header was made in order to allow some sites to increase their security, by giving them a way to completely disable some features, in a way that even a malicious actor with DOM manipulation capabilities cannot override.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes.Yes.
Web Platform Tests under the /feature-policy/ directory are being rewritten to use the new header, to verify that it works as well as the old one. New tests are added for the header behaviour change as well. Other feature tests which integrate with the policy mechanism are similarly being changed to use the new header, if they used the old one previously, or to use the allow attribute when possible, as its behaviour should be unchanged.
Link to entry on the Chrome Platform Statushttps://www.chromestatus.com/feature/5745992911552512
Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/As1ABvc2QdA/yZSpPXY4CAAJ