Repository navigation
Usefulness of reporting in Permissions Policy #386
Description
I'm looking at adding reporting integration with the Permissions Policy spec, but as I do, I'm realizing that most of the compelling reasons for reporting were centered around the use cases that are now handled by Document Policy.
It's a given that reporting can only reflect actions defined in the document that configured reporting -- we can't report on actions in other frames, and can't set a reporting configuration for those frames either, for privacy.
Report-only mode is also less useful, as the frame which sets the policy will usually not see the results, as it is third-party frames which are restricted.
For permissions, then, it seems that the only reportable event is a failed permission request, or a failed attempt to use the covered feature, where that failure is because of the policy, rather than a user denying. That would cover the cases where the reporting document was embedded with a restricted policy, or has restricted itself.
Is this useful? Would developers get enough value out of this to make it work adding to the spec? Or are there other reportable events? Not everything is routed through the Permissions API, so maybe the value in being able to report failed fullscreen or wake-lock attempts is sufficient.
Activity
ScottHelme commentedon Nov 16, 2020
Transparency: I'm the founder of https://report-uri.com which is a service that would likely ingest these reports.
To me as a website operator it seems useful to know if a page is trying to use a feature restricted by my policy, that could indicate quite a problem or a misconfiguration, either of which need attention. It would seem better to have this reporting mechanism than to not have it in my eyes.
As a service, Report URI will ingest any type of report the browser is capable of sending so it doesn't really change much for us. If Permissions Policy gets reporting then we will of course add support.
bartoszniemczura commentedon Sep 14, 2022
I'd really like to see this getting implemented. As a site developer, being able to know what policy violations already occur on individual endpoints makes the large-scale adoption process much smoother without risking wide breakages or unintentional side-effects.
annevk commentedon Sep 27, 2022
I think in part this ties in with the API discussion and what information this ends up revealing that wouldn't otherwise be revealed. Do we need to reveal to the embedded website that it was a policy vs a user decision for instance? I'd rather not.
Reporting that is strictly aligned with the Permissions API (i.e.,
permissions.query()) might be acceptable.cc @marcoscaceres
csharrison commentedon Oct 11, 2022
Chiming in here to say that the Attribution Reporting API (which uses permission policy) has a request for functionality like this in WICG/attribution-reporting-api#525 (doesn't mention permission policy explicitly but asks for error reporting for all cases when the API is not working properly). We can't use the existing permission policy JS APIs for this because Attribution Reporting has the capability to work without any JS at the network layer (a separate deployment with JS access confirmed that
getAllowlistForFeaturemeets the use-case in WICG/attribution-reporting-api#562)We are building out a specific "debug reporting" functionality for the API, but we cannot integrate permission policy errors into that framework because the API being disabled by Permission Policy probably ought to disable all aspects of the API, even debug reporting.
cc @linnan-github
clelland commentedon Oct 30, 2023
Closing this out as we have integrated reporting into the spec with #529
annevk commentedon Oct 30, 2023
@clelland is there a summary available somewhere that answers my question above?
clelland commentedon Oct 30, 2023
I don't have one, but I can try to write something up on the current thinking about the relationship between Permissions and Permissions Policy. @miketaylr and @marcoscaceres, I'll probably run that past you as well.
I do think that reporting is one place that it makes sense to separate the two, as we want to try to surface actions that a site took that ignored the policy, and not just cases where the user said 'no' to a permission prompt.