Re: [w3ctag/design-reviews] WebHID API (Human Interface Device) (#370)

It is possible for a stateful HID device to be used to communicate an identifer across origins.

Ex: ThingM Blink(1) is a USB HID device with an RGB LED that can be controlled using HID reports as described [here](https://github.com/todbot/blink1/blob/master/docs/blink1-hid-commands.md). Note the presence of both "Set RGB color now" and "Read current RGB color" reports. It wouldn't be difficult to implement serial communication between two origins using these reports.

I agree that exposing an identifier like a serial number is a major concern for this API. WebHID will need to capture a stable identifier in order to implement persistent permissions. The stable identifier will only be used internally and will never be exposed to script. For USB we plan to use the USB serial number (fetched along with the USB device descriptor when the device is connected) and for Bluetooth we plan to use the Bluetooth MAC address. (Other transports may not support persistent permissions due to the lack of a suitable stable ID.)

These identifiers are provided by the transport-level protocols and are generally not accessible at the HID level. However, it is possible to access this information on some devices using device-specific reports.

Ex: Sony DualShock 4 is a HID gamepad that supports both USB and Bluetooth modes, and may be concurrently connected to the same host over both transports. In USB mode, the device has a HID report that exposes the Bluetooth MAC address. The host can use this to detect when the device is double-connected. Blocking this report would require device-specific logic.

> I'm not quite sure if this is intended design, or an oversight. From the back of my head this doesn't feel right. Will take a look at the spec on this and report back.

The [Gamepad API](https://www.w3.org/TR/gamepad/) working draft doesn't specify, and behavior varies between browser implementations. Chrome and Firefox provide simultaneous access to all tabs. In Safari, any tab can see the list of connected gamepads but only the active tab receives gamepad inputs.

At the OS level, shared access is typical. For instance, if Firefox has already opened a connection to a gamepad device, Chrome is not blocked from accessing the same device.

> LED control can potentially race (one game flashing it in orange, while one game trying to flash it in green will definitely look completely bizarre), which we believe can confuse users

Agreed that this is confusing. Gamepad API has a similar concern where multiple tabs can issue vibration commands to the same device. For LEDs or gamepads it is relatively easy for the user to diagnose the issue and close the other tab, but for other types of HID devices it may not be as obvious why the device is behaving strangely.

I think introducing the concept of exclusive access would be helpful, but it comes with its own potential for confusion. For instance, if one tab has exclusive access to a device it may not be obvious why the device is unavailable in another tab. This can be mitigated by displaying a tab indicator icon when a HID device is in use, but it doesn't help for service workers which have no suitable indicator area.

Exclusive access needs to be implemented carefully. If one tab takes exclusive access of a device, other tabs can observe this change by trying to open the device and detecting failure. It may be appropriate to signal other tabs about the access change by simulating disconnection until the tab releases exclusive access. However, this would allow a tab to flood other tabs with connect/disconnect events by rapidly taking and releasing exclusive access. This could be mitigated by requiring a user activation for requesting exclusive access or imposing a cooldown after releasing access (connection events would be delayed until the end of this cooldown in case the tab re-acquires exclusive access). It might make sense to restrict some API features (like write access) to exclusive access mode.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/370#issuecomment-531999269