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

Make getGamepads API asyncronous to support permission request #70

Closed
tomrittervg opened this issue Jun 1, 2018 · 8 comments
Closed
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. wide review

Comments

@tomrittervg
Copy link

Gamepads are in the long tail of things that make the web a great experience but are used very infrequently. Can this API be designed to support a permission by making things like getGamepads async? UAs don't need to implement a permission, but with synchronous APIs it becomes impossible to gate releasing user information via a permission.

@luser
Copy link
Contributor

luser commented Jun 1, 2018

I don't think we can change navigator.getGamepads to be async at this point, it's implemented in multiple browsers and has been shipping for a long time. I believe most real-world usage of the API should be amenable to gating access on a permission dialog however, since the spec says that the browser should not expose devices that the user has not interacted with, so users must press a button on a gamepad in order for it to show up. The spec also describes gamepadconnected and gamepaddisconnected events that can be used in place of polling, so browsers could simply delay firing those events + exposing the gamepads in the array returned by navigator.getGamepads() until the user approves the permission.

However, given the spec text around not exposing devices without user interaction I would hope the fingerprinting risk here would be minimal (modulo implementation bugs). Is that not true in practice?

@tomrittervg
Copy link
Author

Is that not true in practice?

I haven't tested, but see #71 and #72 for how I'm not actually sure how that's supposed to work in practice from the spec. :)

@LJWatson LJWatson added wide review security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. labels Jun 4, 2018
@cvan
Copy link
Contributor

cvan commented Jun 4, 2018

could user activation be activated by a "granted" state via a request to the Permissions API (i.e., navigator.permissions.query({name: "gamepad"}?

@npdoty npdoty added the privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. label Jun 7, 2018
@jasonanovak
Copy link

Discussed in PING during June 7th call and think that necessity of prompting is dependent on the outcomes of #71, #72, #73. If the gamepad API ends up revealing a unique ID or is accessible to embedded content, seems more likely we’ll need a prompt.

@marcoscaceres
Copy link
Member

Related w3c/permissions#200

@mrmcpowned
Copy link

could user activation be activated by a "granted" state via a request to the Permissions API (i.e., navigator.permissions.query({name: "gamepad"}?

How would this kind of interaction flow work in embedded contexts, such as accessing the API via Chromium Embedded Framework (CEF)? The permissions API exposes consent requests through the User Agent's UI, but something like CEF has no UI.

@tomrittervg
Copy link
Author

How would this kind of interaction flow work in embedded contexts, such as accessing the API via Chromium Embedded Framework (CEF)?

An async API doesn't preclude answering it immediately without prompting the user if the application knows the answer at time of request. This could because the user has stored a permission for that origin or because the browser chooses not to prompt the user in any case (like they do now.)

If a game that the user installs (either a separate application or some sort of web extension) wants to support gamepads it would be silly to prompt the user; the user already explicitly took action to 'install' the game and granted it some elevated trust in doing so.

@marcoscaceres
Copy link
Member

Closing as we think the current mitigations are sufficient (i.e., the use must interact with the gamepad to enable it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. wide review
Projects
None yet
Development

No branches or pull requests

8 participants