#909: Permissions Policy Reporting and Report-Only mode

Visit on Github.

Opened Oct 17, 2023

こんにちは 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.

Further details:

  • 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/.

Discussions

Discussed Nov 1, 2023 (See Github)

Hadley: report-only mode - that feels like a fingerprinting thing... sending a lot of info without the user being aware of it... Could it be misused?

Yves: you could intentionally generate errors... But probably other ways of doing that... especially if there is a possibility of sending the report to another host...

Peter: most things - like CSP - let you send it to a 3rd party service... some require it.

we discuss writing a comment to ask what abuse scenarios there are and what mitigations might exist?

Peter: the same information can be gotten via an API https://w3c.github.io/permissions/

Comment by @hadleybeeman Nov 20, 2023 (See Github)

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?
Discussed Dec 1, 2023 (See Github)

Dan: waiting for their response - wrote comment asking for update

Comment by @torgo Dec 19, 2023 (See Github)

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

Comment by @clelland Dec 19, 2023 (See Github)

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!

Discussed Jan 1, 2024 (See Github)

Hadley: they responded to us ... I'm a little concerned that Ian doesn't know of any unintended consequences...

Dan: we've raised the issue ...

Hadley: we can't make him explore the unintended consequences...

discussion of security & privacy

Sangwhan: i don't think this exposes additional bits of entropy... if you have prior knowledge of what features are available in a UA then you have same level of bits... however you'll get more info about the user and be able to triangulate the user better.. but don't know if this exposes extra info on that regard.

Hadley: that sounds consistent with Ian's review.

discussion on how to push

Sangwhan: it's not going to have multi-stakeholder support since permission policy is a chrome-only feature...

Dan: we should talk about this... why does permission policy not have better support?

Dan: suggest we close this as satisfied with concerns where the "concerns" are multi-implementer support.

Hadley: sounds sensible.

Sangwhan: feature / permission policy did have multi-stakeholder support... just hasn't been implemented... We could ask again... [So I'd prefer "satisfied"]

Hadley: but that's a signal... We have other labels to indicate "please don't do this"...

Sangwhan: sometimes implementers aren't building it but not against it ...

Hadley: important for us to champion multi-implementer support... a web that's interoperable...

<blockquote>

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?

</blockquote>

Dan: ok we can come back to it in the plenary.

Discussed Jan 1, 2024 (See Github)

Dan: doesn't look like there has been a reply to us. Should this be with concerns? We need to probe more about what Mozilla's views are on this proposal, and their approach to permission policy

Hadley: agree

Comment by @torgo Jan 9, 2024 (See Github)

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?

Discussed Feb 1, 2024 (See Github)

bumped

Discussed Mar 1, 2024 (See Github)

Dan: I will reach out to Chris Harrelson

Max: they promised to update the explainer to analyze unintended consequences and also the party who receives the report... but no update yet.

Dan: leaves note on issue

Comment by @torgo Mar 25, 2024 (See Github)

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

Discussed May 1, 2024 (See Github)

Dan: sends a note to Chris Harrelson to see if there has been any update

Comment by @clelland May 21, 2024 (See Github)

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:

Discussed Jun 1, 2024 (See Github)

Dan leaves comment

Comment by @torgo Jun 19, 2024 (See Github)

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.