anssiko
commented
4 years ago Closed pes10k closed 4 years ago
anssiko
commented
4 years ago anssiko
commented
4 years ago I assume you read the note on top of the security and privacy considerations section and that is where the concern ("unexpected statement") originates from, correct? Quote (emphasis mine):
The Generic Sensor API and its extension specifications are agnostic with respect to any user interface aspects. This specification defines an integration point to the Permissions API [PERMISSIONS] that implementers can use for explicit or implicit user consenting. [...]
To elaborate on that, that is to say Permissions API is the "central location". Generic Sensor API spec hooks into Permissions API spec in its request permission access abstract operation that is called into from the Sensor.start() algorithm step 4.3.
More recently, the group discussed this particular topic at its recent F2F. I'll summarize key parts of that discussion below since I think it is relevant:
Per resolution it was concluded the current state where the spec allows implementers to either (i) use the affordances provided by Permissions API and its extensions (such as request()) or (ii) implementation-specific explicit permission mechanisms in a non-blocking fashion relying on the existing side-effects in Sensor.start() provides implementers ability to innovate in permissions UX while preserving user privacy attributes. This resolution built upon understanding that it is still being debated whether explicit user consenting affordances are in scope of Permissions API or not. Currently request() is shunted into an extension spec with no wide consensus and limited implementer support.
Details in #388 and Fukuoka F2F minutes.
In the light of this further context, what are the concrete spec changes the group should consider? I think some clarifications to the above-mentioned note would be in order. @snyderp would you be in a position to propose a better wording for the said note?
pes10k
commented
4 years ago Thanks again for the background @anssiko !
My request is to remove this text from the #permissions section:
User agents use a number of criteria to grant access to the readings. Note that access can be granted without prompting the user.
And to also remove the 2nd and 3rd paragraphs from this note (the first par is great though, and rarely somehting i find in reviews. Points and appreciate to ya'll!). I appreciate that permission policy is a point of debate, and likely to be an increasingly heated one going forward. Because of that, I'm eager to do anything that'd prevent either of the following:
1) A suggestion that permissions in this spec should be handled differently than permissions anywhere else 2) Increase the amount of cross-spec revising that needs to be done if / once that aspect of permission policy is worked out.
Since this text seems to be at best redundant with what will be in the permission spec, and at worst would be in conflict with possible text in that spec and / or create implementor ambiguity, I think it should be removed from this spec. WDYT?
The spec makes the unexpected statement that permission-protected functionality does not require explicit user permission to grant. This is a pretty heavy deviation from how permissions are dealt with elsewhere in specs. If the web platform is going to move to a model of “inferred permissions” (with “how to infer” tbd), it would be much better to address that in the Permissions spec, or some other central location.