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

Thanks Cynthia!

> Blunt question: will the device selector dialog come up every time the user tries to access the same device on an already approved origin?

No, the final implementation will persist permissions so that the chooser dialog only needs to be shown once per origin/device pair.

> One simple actionable point of feedback is that this HID should only be available to the current active tab. If you had particular use cases in mind that allow HID devices to be read from multiple tabs, we'd like to hear what you have in mind.

I'm not aware of any use cases that would require a single HID device to be accessible from multiple tabs at the same time, perhaps we can restrict access to a single tab per device. However, at the OS level the device is still accessible to other apps which could allow access from multiple tabs (eg, a second browser instance).

If HID is only available from the active tab then this will break use cases where the tab accessing the device is expected to be in the background. It would also make it impossible to access HID from contexts with no active tab, e.g. Service Worker.

Ex: USB headsets often provide advanced features using HID (mute button, volume controls, status LEDs). A user is using her USB headset to make a call in one tab, then switches to another tab. The audio functionality of the headset will continue to work but HID-based features will not work until she switches back.

Ex: WebHID can be used to control LEDs on connected HID devices. This could be used to match the color of RGB LEDs to the action of a game, or to match colors across multiple connected devices. If WebHID is only accessible to the current active tab then the LED colors cannot be changed when the tab is backgrounded, limiting possibilities for animated patterns.

> From a user's perspective, input hitting multiple tabs would be analogous to keyboard events being broadcasted to all tabs.

This is dangerous for keyboards, but keyboard inputs will not be accessible through WebHID. For other types of HID devices, shared access is expected. For instance, gamepad inputs are typically available in all apps (or browser tabs) simultaneously.

> One more bit is we aren't quite sure if providing lots of device specific details to be readable would outweight the benefits of increasing the fingerprinting surface. Would obstructing this information away be problematic?

Can you point out which details you are concerned about? Most of the device-specific details are in the HIDDevice.collections member which is a representation of the information in the HID report descriptor. The report descriptor allows the host to detect a device's capabilities without specific knowledge about the device. If we obscure too much information in the report descriptor we may prevent apps from building generic device drivers, which would be a shame since this is one of the greatest advantages of the HID protocol.

The report descriptor is typically going to be identical for any two devices with the same vendor and product IDs. As such, it usually does not expose more fingerprinting surface than just exposing the IDs.

Other device details in HIDDevice are necessary:

Vendor/Product ID are used to identify the device. Removing these IDs would make it impossible to detect when specific devices are connected.

The product name is the string shown in the chooser dialog and is the only user-facing identifier for the device. In some cases the site will need its own chooser (separate from the permissions dialog) to allow the user to select from multiple connected devices. In this scenario, it is best if the device identifier used by the site's chooser matches the identifier used by Chrome's permissions dialog.

-- 
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-531435913