Integration with permissions API

[pes10k]

This issue is filed as part of the PING review requested here w3cping/privacy-request#138

Both to address the potential misuse of the API to create a cross-device / cross-context covert channel (and to standardize the behavior of the discussed cases of when the user agent might want to deny access to the API to prevent user annoyance), the API should integration with the permissions API (even if the expected UX for access / denial of that permission isn't a standard permission dialog)

[anssiko]

@pes10k and the PING folks, thanks for your timely review!

We will be discussing this issue at TPAC F2F w3c/devicesensors-wg#69 in context of overall wide review feedback dissemination. We'd love to pull you into that discussion, or visit an applicable PING session, to bring this issue to closure. For background, historical context relevant to your suggestion below, also included is questionnaire feedback for your consideration.

History first:

The group discussed Permissions API integration early on #10 and deferred the integration to a later version awaiting further implementation experience. Later, Chrome chose to implement user activation-gating #29 instead and that is what the latest editor's draft now reflects. IIRC that design decision was made informed by large-scale trials for both cross-origin and same-origin user activation-gating separately.

Then some feedback related to questionnaire stemming from this context. I hope this is helpful:

It appeared to me Web Platform Design Principles talks about user user activation and meaningful consent:
https://www.w3.org/TR/design-principles/#require-user-activation
https://www.w3.org/TR/design-principles/#consent

However, I believe there would be an opportunity also for the Security and Privacy Questionnaire to provide further advice on how these two mechanisms should work together from a privacy perspective. When to choose one over another, or use both. Currently, the questionnaire ED talks about user activation in context of BFCache. A more general advice would make this consideration more visible to folks who conduct their self-reviews.

[anssiko]

@pes10k, we discussed this issue at TPAC. Implementers present considered other mitigations in place sufficient, and shared they do not intent to implement Permissions API integration. However, Permissions Policy integration was considered possible future work. The group's immediate aim is to refresh the specification at TR (and obsolete the current Rec) to first match existing implementations, and then work on further improvements in subsequent updates with implementers.

The group would now like to receive a signal from you that we can move ahead with the publication plan. We'd keep this issue open as future work. Thank you!

[anssiko]

@pes10k sorry to nudge you about this, but we're looking to wrap up the wide review. Do you have comments or concerns with the group response outlined in #42 (comment)?

In the short term, we're bound to move with implementers on this issue. However, I'd like to keep this issue open to solicit more input. Should we keep this type of future work issues labeled with privacy-needs-resolution Issue the Privacy Group has raised and looks for a response on. or transition to privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. ?

[pes10k]

Hi @anssiko, apologies for the delay getting back to you. After talking with a couple other folks PING side, i'm comfortable making these issues non-blocking, and for them to be tackled in the next version. I've changed the label from privacy-needs-resolution to privacy-tracker to reflect this. So, you should be good to go

[anssiko]

Thanks again @pes10k and PING folks for your review! We'll consider this issue non-blocking for the CRS publication.

[himorin]

@pes10k I'm not sure from which cause w3cbot remarks as needs-resolution, but let me change label of both this issue and tracker issue.