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

Summarizing the TPAC discussion.

* **Cross-origin communication**: WebHID allows simultaneous access to the same device from multiple origins. If a device supports read/write functionality it can be used as a side channel and breaks the same origin model. Proposed mitigations include read-only access, exclusive access. Read-only access breaks use cases that require two-way communication (ex: telephony devices). Exclusive access can only be enforced within a single browser instance since access at the OS level is typically shared. Also there are use cases where multiple origins may need to access the same device (ex: a streamer's gamepad viewer overlay requires HID access while the overlay tab is not focused).
* **Blocklist vs allowlist**: A blocklist is used to deny access to functionality that should not be exposed to the web. Narrow rules can be used to block partial functionality on a device while leaving other functionality available. An allowlist was considered but the long tail of HID devices makes it difficult to scale. WebUSB tried an allowlist and saw few upsides and many downsides. The WebHID blocklist is public ([hosted on the spec repo](https://github.com/WICG/webhid/blob/master/blocklist.txt)) and any vendor may contribute new rules by pull request.
* **Picker model**: WebHID requires user interaction to request device access permissions. In Chrome, when a device is requested by script the browser shows a picker UI for the user to select a device. The spec does not define the picker UI but should recommend the use of a picker for device selection. (The spec has since been modified to recommend a picker.)
* **Malicious devices**: A device may be intentionally designed to be malicious, or may be hacked in a way that enables it to be used maliciously. These devices may be accessible through WebHID. The security model for WebHID doesn't attempt to protect the user from these devices, it's up to the user to choose whether a site can access the device. A malicious device doesn't need the web browser's help to do bad things.

@cynthia Do you have any topics you'd like to follow up on?

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