Intent to Prototype: Permissions-Policy header

[Ian Clelland]

Contact emails

icle...@chromium.org

Explainer

https://github.com/w3c/webappsec-feature-policy/blob/master/permissions-policy-explainer.md

Specification

https://w3c.github.io/webappsec-permissions-policy

Design docs

https://github.com/w3c/webappsec-feature-policy/blob/master/permissions-policy-explainer.md

TAG review

https://github.com/w3ctag/design-reviews/issues/341

Summary

The 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.

Motivation

The 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.

Risks

Interoperability and Compatibility

Since 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.

    - This case will also continue to work exactly as before.

There is a more in-depth analysis of the web compatibility story, including results of the use counter which was added in M81, at https://docs.google.com/document/d/1yWZI4_7kzo6fJhZMGIZAW-01tCq5wCXdW105DMGl1js

Gecko: Positive (https://github.com/w3c/webappsec-feature-policy/issues/359) The initial impetus for this change came from a request from Firefox.

WebKit: No signal

Web 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.

Activation

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).

Security

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

Is this feature fully tested by web-platform-tests?

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.

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5745992911552512

This intent message was generated by Chrome Platform Status.