search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
318 stars 55 forks source link

Permissions Policy Reporting and Report-Only mode #909

Open clelland opened 8 months ago

clelland commented 8 months ago

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

You should also know that...

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 commented 7 months ago

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 commented 6 months ago

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

clelland commented 6 months ago

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 commented 5 months ago

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 commented 3 months ago

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

clelland commented 1 month ago

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:

torgo commented 2 weeks ago

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.