w3c / gamepad

Gamepad
https://w3c.github.io/gamepad/
Other
139 stars 49 forks source link

Make getGamepads API asyncronous to support permission request #70

Closed tomrittervg closed 2 years ago

tomrittervg commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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. :)

cvan commented 6 years ago

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

jasonanovak commented 6 years ago

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 commented 4 years ago

Related https://github.com/w3c/permissions/pull/200

mrmcpowned commented 4 years ago

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 commented 4 years ago

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 commented 2 years ago

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