#909: Permissions Policy Reporting and Report-Only mode
Discussions
2023-11-20
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/
2024-01-08
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.
2024-01-15
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
2024-03-25
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
OpenedOct 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:
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/.