Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add API for requesting permission #388

Closed
anssiko opened this issue Mar 11, 2019 · 7 comments

Comments

@anssiko
Copy link
Member

commented Mar 11, 2019

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:

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

This comment has been minimized.

Copy link

commented Mar 12, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Mar 14, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

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

@anssiko

This comment has been minimized.

Copy link
Member Author

commented May 27, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented May 28, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Sep 19, 2019

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

@reillyeon reillyeon closed this Sep 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.