Add API for requesting permission

[anssiko]

Generic Sensor API was defined with an expectation the generic navigator.permissions.request() would materialize at some point, but since request() seem not be gaining support among implementers we should look at other options. Currently, two approaches to programmatically request permission have been coined and one of them tried on the web platform:

• Generic navigator.permissions.request()
  • Spec: WICG spec spun off from Permissions API that defines navigator.permissions.query()
  • Implementations: none
• Concrete Foobar.requestPermission()
  • Spec: Notifications API, considered for Device Orientation; dropped from Payment Handler API
  • Implementations: Chrome seem to pass wpt test case (wpt.fyi not running these interactive tests), per MDN others implement too but unable to validate

Opened this issue to gauge interest to revisit concrete requestPermission() again given it has been getting some traction recently (see Device Orientation). If there's support for this idea, we could add informative guidance to Extensibility for concrete spec authors that subclass Sensor to utilize.

[tomayac]

Generic navigator.permissions.request()

• Spec: WICG spec spun off from Permissions API that defines navigator.permissions.query()
• Implementations: none

FWIW, on the Chrome side, Implement Permissions.request() and Permissions.revoke() has been started, which is still blocked on Implement navigator.permissions.requestAll(), but I can't find requestAll in the spec (it seems @mounirlamouri can say more about that).

I am in favor to try to push the generic approach, especially because I do find it worthwhile to explore the "multiple permissions at once" case given general permission fatigue.

[anssiko]

Related: Permissions API issue w3c/permissions#191 discusses bundling of permissions as a generic mechanism.

Since this discussion rightly is split across multiple repos, a clarification:

This issue #388 is to explore what is the preferred mechanism (if any) to programmatically request permission for concrete sensors that subclass Sensor. That mechanism might be an affordance specified in a future version of the Permissions API spec, its extension spec, or elsewhere.

[rwaldron]

@anssiko it might help if we compose a list of sensors that may need/want a permission API?

[anssiko]

@rwaldron, the list of sensors some implementers may want to gate behind a permission is basically all the concrete sensors that subclass Sensor: https://www.w3.org/das/roadmap

Currently "legacy" DeviceOrientationEvent and DeviceMotionEvent are behind a permission gate on iOS and Chrome is WIP, while the corresponding modern APIs are not.

@rakuco @reillyeon can probably comment on Chrome's permission-related plans for the APIs that subclass Sensor.

[reillyeon]

My proposal is to remove the permissions-related side effects from Sensor.start() and add an explicit Sensor.requestPermission() method. The reason to separate these is to avoid needing to start a sensor in the main frame just so that the page can request permission to use that sensor from a worker. In terms of avoiding permission prompts that come out-of-context (which was the argument on the Payment Request API) there isn't a meaningful difference between having two methods rather than one.

To @rwaldron's question, all sensor types will have a requestPermission() API. It is up to implementations how to manage permissions internally. Chrome currently tracks a single "sensor" permission type. The design of the API should, for example, allow an implementation to require permission for some sensors and not others, or to require permission for some polling frequencies and not others.

[anssiko]

@reillyeon wrote:

My proposal is to remove the permissions-related side effects from Sensor.start() and add an explicit Sensor.requestPermission() method.

All - please let us know if you have any concerns with this proposal.

Hearing none, I'd like us to start baking a PR to specify this in detail.

[reillyeon]

Discussed at TPAC 2019 F2F. Closing this issue without adding a static requestPermission() API. Relying on the existing side-effects in Sensor.start() and the Permissions API for more advanced use cases such as permissions bundling.

https://www.w3.org/2019/09/19-dap-minutes.html#x05