Re: [w3c/gamepad] Please don't restrict to a secure context (#145)

@jharris1993 @Brikwerk @cbmpvr 

Device APIs like WebUSB, WebHID, Web Serial, and Web Bluetooth have three levels of permissions. There's a default guard permission that configures the default Ask/Allow/Block behavior, guard permissions that override the Ask/Allow/Block behavior for specific origins, and device permissions that grant permission for a specific origin to access a specific device. I think it would be nice if Gamepad API integrated with other device APIs to make it easier to access advanced functionality provided through those APIs.

The current device permissions model carves up permissions by API. In high-level APIs this has the intended result of separating device permissions by capability. In low-level APIs, users may be confusingly prompted multiple times for the same device with no clear connection to the capabilities that would be exposed by granting each permission. This can happen if the device is implemented as multiple low-level interfaces, each of which is tracked by a separate permission.

Carving out some capabilities is important. If a gamepad has audio or video capture capabilities then they should be locked behind the appropriate high-level permissions. However, other capabilities like advanced haptics, speakers, LEDs, touchpads, and motion inputs could be bundled with low-level device APIs as a broad "Allow $ORIGIN to take control of $DEVICE" permission that no longer is specific to an API or capability.

That's where I'd like Gamepad API permissions to end up. It gives us a way to solve the issue for gamepad API access from locally hosted services but it's a huge amount of overhead just for that and won't be ready any time soon. Instead, I'm proposing Chrome commits to supporting `chrome://flags/#restrict-gamepad-access` as a [never-expire](https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/flag-never-expire-list.json) flag until [this issue](https://github.com/w3c/webappsec-secure-contexts/issues/60) is resolved since a flag specific to Gamepad API is better than pushing users to install self-signed certificates. Users of applications like Megapixel VR would be able to disable the flag to restore access in non-secure contexts.

Note that the current behavior of `chrome://flags/#restrict-gamepad-access` in Chrome 100 is not what we want. In secure contexts, getGamepads() should return an empty list (not throw an exception) to avoid breakage in apps that don't expect it to throw and don't need the API. Also it enforces the wrong permissions policy default allowlist which is too restrictive.

I've put together my current plan for migrating Gamepad API to secure context and feature policy integration here: [Securing Gamepad API in Chrome](https://docs.google.com/document/d/1Dj_7EpT9ttnI96BuNXtLEJkHEq0orHgoLeYaOBz9xsU/edit#)

Gamepad API has many surprising use cases and I feel that restricting it permanently is unnecessarily limiting. We should find ways to make it maximally useful while retaining as much user privacy as technically possible. If we add a permission I feel it should be primarily used for unlocking advanced features on the device and bypassing privacy protections, not providing basic access to gamepad button and axis inputs. There's no reason gamepad inputs can't be sanitized and exposed in a form similar to mouse and keyboard inputs.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/145#issuecomment-1093557633
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/145/1093557633@github.com>