Re: [w3c/gamepad] Add vendorId, productId, name attributes (PR #202)

> 1 may be fun but not sure it's important enough.

Displaying the correct button labels is important for gaming services where players are expected to bring their own gamepad. It's confusing when the game tells you to press the "X button" but you're not sure if it means Xbox X button (buttons[2]), PlayStation Cross button (buttons[0]) or Switch X button (buttons[3]). The gamepad itself doesn't know what the correct labels are so applications need a way to decide which labels to use.

> how can I identify each controller by name if I have 4 Xbox 360 controllers connected?

I think it's not necessary for the human-readable identifier to distinguish between devices that can't be distinguished by a human. If the controllers are identical then (in my opinion) it's fine to use the same identifier.

Sometimes the product name is identical but the device itself may provide additional device-specific distinguishing information. For instance, it's possible to query a Switch Joy-Con's color. As specified in this PR it would be acceptable for a user agent to add the color information to the name string as an additional distinguishing detail. However, most gamepads don't provide a programmatic way to distinguish between cosmetic variations of the same product.

On consoles this problem is solved by assigning each connected gamepad to a slot and using light indicators to distinguish slots. There's a separate proposal #143 to allow applications to set the light indicator state which could be used to distinguish otherwise identical gamepads. This approach is limited by the reality that not all gamepads have light indicators, and those that do only have a limited number of distinct configurations for representing slots.

> Should the application instead vibrate each controller for example so that I can know which is which?

Applications shouldn't rely on vibration since not all gamepads support vibration. Even gamepads that support the feature may give the user a way to disable it, for instance with a physical on-off switch on the gamepad. We can't assume that sending a vibration command to a gamepad will actually cause it to vibrate in a way the user will notice, but vibration could be useful in conjunction with other signals.

> I'd rather discuss removing id to resist fingerprinting and add missing features that this might solve

I don't think removing Gamepad.id is feasible because too many applications already rely on it.

As a fingerprinting mitigation I think it would be reasonable for Gamepad API to offer tiered access to gamepads so that Gamepad.id is safe by default. Perhaps by default a site receives only generic information about connected gamepads similar to how PointerEvents provides almost no information about the connected pointing device. Only the standard buttons/axes are exposed and capabilities like vibration are disabled to resist fingerprinting. After granting a permission, the site would be allowed to access all information about the gamepad, including device IDs. I expect we will need to add a permission model anyway since we want to add support for more powerful gamepad capabilities that wouldn't be appropriate without stronger user consent.

> I think two feature-equivalent gamepads should be perceived equivalent to Gamepad API even if those are different products.

I disagree mainly because of the button labels problem. Other capabilities can be automatically detected, but displaying the correct button labels requires device identification because the labels are never provided by the device itself.

If we want to hide device IDs from the application then the user agent needs to provide the necessary information to select the correct button labels. I expect the fingerprinting risk of exposing labeling information is roughly equivalent to exposing the vendor/product/name since we expect these values to be highly correlated. If the API is responsible for providing this information then it increases the burden on the user agent proportional to the number of supported gamepads. If the fingerprinting risk is roughly equivalent then I think we should save ourselves the effort and let applications developers build tables of button labels for the devices they care about.

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

Message ID: <w3c/gamepad/pull/202/c2118548242@github.com>