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

@roderickc

> From the security side you can issue a feature report to get the MAC address, firmware version and some more, so finger printing is an issue.

Access to device information and input/output/feature reports is gated behind a chooser dialog. By default, an origin cannot access any information about connected devices. This protects users from fingerprinting in the common case where an origin has no permissions for any devices.

In the case where permission is already granted, WebHID avoids exposing sensitive identifiers like USB serial number or Bluetooth MAC address. However, there is always the potential for vendor-specific functionality (like DS4's MAC address report) that can be used to create a persistent identifier.

Some devices are too sensitive to be exposed to script at all. In Chrome, we maintain an internal block list of USB vendor/product IDs, perhaps DS4 should be added to that list.

> What for me is even scarier than finger printing is that you can issue feature reports to perform firmware updates. A naughty website could brick controllers.

I agree this is scary. There are probably many devices that support unsigned firmware upgrades through HID. These devices could be hijacked by a malicious script and reprogrammed to do any number of terrible things.

When a device is known to be vulnerable, we can add it to the block list or otherwise restrict access to the vulnerable reports. Let's discuss potential mitigations for Sony devices off-thread. In the general case it's not possible to know whether a device supports unsigned firmware updates or other dangerous features.

On some level, the risk here is no different than the risk of accessing a device through WebUSB. Both APIs use a similar chooser-based permission model. With WebUSB device access you can create persistent identifiers, rewrite firmware, etc.

> anyone using raw HID with our controllers (even when not using audio) e.g. for rumble or lights would cause interference

This is something that must be addressed at the platform level with an exclusive driver. Desktop OSes generally default to non-exclusive access to HID devices, so the expectation should be that multiple applications could access the device at the same time.

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