Intent to Ship: 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

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.

This intent really covers two tightly intertwined changes to the API. The first is the syntactic change and rename of the existing header. The second is the semantic change, which is a bit more subtle. The change was motivated by developer feedback (see, for example, this issue), and would have been part of the Feature Policy spec even if it had not been renamed. I would prefer to make both of these changes at the same time, and change the behaviour of the existing header while also introducing the new header as a replacement, rather than having two headers control the same features in different ways, but there are some risks to that. The Interoperability and Compatibility section covers this in more detail.

Blink component

Blink>FeaturePolicy (Yeah, that should get updated too)

TAG review

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

TAG review status

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

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

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.

Gecko: Positive (https://github.com/w3c/webappsec-feature-policy/issues/359) 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: 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, or to use the allow attribute when possible, as its behaviour should be unchanged.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1095641

Link to entry on the Chrome Platform Status

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

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/As1ABvc2QdA/yZSpPXY4CAAJ

This intent message was mostly generated by Chrome Platform Status.

[Yoav Weiss]

The semantics change has some implications on Client Hints that I think need to be further discussed.

 

Gecko: Positive (https://github.com/w3c/webappsec-feature-policy/issues/359) 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.

While they are likely to be positive, it'd be better to ask for an official position on their standards position repo.

 

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: 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, or to use the allow attribute when possible, as its behaviour should be unchanged.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1095641

Link to entry on the Chrome Platform Status

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

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/As1ABvc2QdA/yZSpPXY4CAAJ

This intent message was mostly generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKS21GncbmU16mbhopJtZT4FWYpYS4FGomutrdpEsMnQA%40mail.gmail.com.

[Ian Clelland]

+1 -- let's kick that off in a GitHib issue; probably on the permissions-policy repo.

 

 

Gecko: Positive (https://github.com/w3c/webappsec-feature-policy/issues/359) 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.

While they are likely to be positive, it'd be better to ask for an official position on their standards position repo.

The link at mozilla-standards-position has actually been renamed to "Permissions Policy", linking to the current spec, and remains "Worth Prototyping", but the discussion in the related issue hasn't specifically touched on the header change issues. I'll reach out to see if there's any difference in their stance on this particular aspect of the spec.

[Ian Clelland]

Hi Roberto,

Reporting for violations is restricted to actions taken in that frame, for exactly that reason. If a subframe triggers a violation report, the parent frame cannot see that. The subframe would need to set up its own reporting configuration (or cooperate with its embedder to communicate through some other mechanism).

Ian

On Thu, Oct 8, 2020 at 3:51 AM Roberto Clapis <cl...@google.com> wrote:

One concern emerged during the security review for this feature: is it possible that reporting will introduce an XS-Leak?

For example if application maps.com only asks for geolocation if the user is logged in an attacker.com could iframe it and set a policy that does not allow for geolocation and detect if a report is sent (thus if the user is signed in).

[Roberto Clapis]

One concern emerged during the security review for this feature: is it possible that reporting will introduce an XS-Leak?

For example if application maps.com only asks for geolocation if the user is logged in an attacker.com could iframe it and set a policy that does not allow for geolocation and detect if a report is sent (thus if the user is signed in).

On Monday, October 5, 2020 at 9:05:37 PM UTC+2 icle...@chromium.org wrote:

[Yoav Weiss]

To update this thread: Ian opened an issue and a PR with a concrete proposal to align the semantics changes with a workable Client Hints model.

[Yoav Weiss]

LGTM1

After re-discussing this with Ian, I realized that the compat impact of the semantics change on existing use-cases, and in particular on Client Hints, is not awful - when delegating high-entropy hints to iframes, the header alone would not be enough and an allow attribute would be required.

While that's not great from an ergonomics perspective, I was convinced that it's required for other, risquier, permission types, and we want to maintain a consistent model.

Given that, and given the fact that the potential breakage is fairly limited, it seems worthwhile to align the Feature Policy behavior to the Permission Policy spec now rather than later, so reduce developer confusion.

 

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh-8%3DE_S45658jCykBg0Uiu-feNCap2hf_rCKo5sYUgAw%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-hVfxO8YYX_WAKNCD96sg_bnFmTDbYDsaL4pfw3s9f4A%40mail.gmail.com.