SummaryThe Permissions-Policy HTTP header replaces the existing Feature-Policy header for controlling delegation of permissions and powerful features. The header uses a structured syntax, and allows sites to more tightly restrict which origins can be granted access to features.
MotivationThe Feature Policy API was recently renamed to "Permissions Policy", and the HTTP header has been renamed along with it. At the same time, the community has settled on a new syntax, based on Structured Field Values for HTTP.
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 one of 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.
: Positive (https://github.com/w3c/webappsec-feature-policy/issues/359
) The initial impetus for this change came from a request from Firefox.WebKit
: No signalWeb developers
: Positive (https://github.com/w3c/webappsec-permissions-policy/issues/357#issuecomment-562744161
) 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)?YesYes
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.
Link to entry on the Chrome Platform Statushttps://www.chromestatus.com/feature/5745992911552512