Permissions Policy Reporting and Report-Only mode

[clelland]

こんにちは TAG-さん!

I'm requesting a TAG review of Permissions Policy Reporting.

A document's permissions policy sets limits on what kinds of actions it can perform; what APIs are available. When a page tries to do something that is blocked by policy, the browser currently surfaces a message in developer tools -- this can be great when developing a site, but is often not enough when dealing with a site in production. It would be very useful to be able to collect reports about real problems that users are seeing.

We're addressing this by integrating permissions policy with the Reporting API. In the same way that sites can opt in to receiving reports about CSP violations or deprecations, they will now be able to receive reports about permissions policy violations in the wild.

• Explainer¹ (minimally containing user needs and example code): https://github.com/w3c/webappsec-permissions-policy/blob/main/reporting.md
• Specification URL: https://w3c.github.io/webappsec-permissions-policy/#reporting
• Tests: https://wpt.fyi/results/permissions-policy/reporting?label=experimental&label=master&aligned
• User research: Nope
• Security and Privacy self-review²: https://github.com/w3c/webappsec-permissions-policy/blob/main/security-privacy-questionnaire-reporting.md
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/webappsec-permissions-policy
• Primary contacts (and their relationship to the specification):
  • Ian Clelland (@clelland), Google, Spec Editor
• Organization(s)/project(s) driving the specification: Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification:
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5105435227455488

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: [please provide]
• The group where the work on this specification is currently being done: W3C (WebAppSec WG)
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): Same
• Major unresolved issues with or opposition to this specification: None that I'm aware of. This has been discussed positively in the WG several times.
• This work is being funded by: Google

You should also know that...

• Permissions Policy (née Feature Policy) has been reviewed by the TAG, as has the Reporting API. This review request is for the integration of the two, so that policy violations (and potential violations) can trigger reports.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.

[hadleybeeman]

Hi all! We are looking at this in our W3C TAG breakout session today.

We like the general shape of this and definitely understand the value to developers. We do have a few questions:

1. What are the unintended consequences for this API, or potential misuses? We wondered if the report-only mode could be used for fingerprinting the user or their user agent, especially state that the user set.
2. Is the reporting going to a third party? We assume so, but that makes the privacy angle more salient.
3. We appreciate the inclusion of info regarding the privacy implications of reporting on embedded frames — maybe this should go into a security & privacy considerations section in the explainer?

[torgo]

Hi @clelland do you have any update on this - or any answer to @hadleybeeman's questions? Thanks.

[clelland]

Sorry, that notification got lost in my inbox -- thank goodness for end-of-year cleanup time :)

1. I don't know of any unintended consequences; the intended consequences are that the site owner can tell if a script on their page is attempting to use an API that was blocked by policy (note that this is not the same thing as being blocked by the user denying permission; in the enforcing mode, the user will never even have been prompted, as the feature was already being blocked by policy.) The policy is set by the structure of the web site, through headers, and the allow attribute on iframes, which would not be useful for fingerprinting a particular browser or user. The fact that reporting is available at all does provide a very coarse fingerprinting signal, but it is equivalent to knowing the model+version of the browser itself. This is the same as using any other feature-detection to deduce the browser version.

2. The reports can be sent to a third party, at the site owner's discretion. Third-party reports have a few additional restrictions (the receiving server must support CORS, and the reports will not include any credentials; see https://w3c.github.io/reporting/#try-delivery)

3. I'll add that to the explainer, thanks!

[torgo]

We would really appreciate if you could do some additional review about unintended privacy consequences... Could that work happen in WebAppSec maybe?

We remain concerned about lack of multi-implementer support for Permission Policy itself, as well as this proposal. Although this is out of scope for this review, it remains a general concern. We'd like to encourage you to continue the multi-implementer discussions for permission policy. Also do we have any indication of support from other implementers or stakeholders on this specific proposal?

[torgo]

Hi @clelland just checking in on this - I think we are waiting on an updated explainer... Thanks!

[clelland]

We remain concerned about lack of multi-implementer support for Permission Policy itself, as well as this proposal. Although this is out of scope for this review, it remains a general concern. We'd like to encourage you to continue the multi-implementer discussions for permission policy. Also do we have any indication of support from other implementers or stakeholders on this specific proposal?

Permissions Policy itself is now supported well in WebKit, as of https://github.com/WebKit/WebKit/commit/061e4cd3970fe03212bc57c761cb3d5e4088421f

In Firefox, the implementation is well behind the spec, with no support for the current header syntax, and only flagged support for the original Feature-Policy header. I'll see what I can do to unblock compatibility there.

I will poke at the standards position issues to gauge implementer support for reporting. For reference, those are here:

• https://github.com/mozilla/standards-positions/issues/909
• https://github.com/WebKit/standards-positions/issues/269

[torgo]

Hi @clelland - thanks for that feedback - it's good to see additional implementations happening. 👍🏻

Re: our original feedback on "unintended consequences" - one of the main things we were looking for, and which still seems to be missing from the explainer, is any discussion of abuse cases and mitigations against those cases. This could fit into a "security & privacy" discussion in the explainer. If you need help thinking about this you could review our Self-Review Questionnaire: Security and Privacy.