WICG
Add a stable device identifier
The current spec does not provide an adequate way for script to distinguish multiple devices of the same model. Typically this is done by comparing USB serial numbers or Bluetooth MAC addresses which are set by the manufacturer and are expected to be unique.
To protect users' privacy, WebHID should not expose stable device IDs (including USB serial number or Bluetooth device address) as these can be used for fingerprinting.
Instead of exposing the serial number or Bluetooth address directly, perhaps we can hash information about the device with the origin URL to create a unique identifier for the origin/device pair. This would still allow an origin to recognize when a device is reconnected but would not be useful for tracking the user across origins.
I remember that at some point the websUSB spec had provisions to register vendorID to domain. Could the manufacturer, or vendor's domain, have exclusive access to the raw non-hashed USB serial ( UDID )? We've got about 20k device configurations, connection history and firmware status data stored by UDID which sync to those specific devices when connected through the use of a chrome.hid web store app. We could certainly re-pair that data to the new hashed identifier... if a user is logged in and had previously registered a device of that type. Also, device firmware could choose to replicate the UDID data to other locations and provide an endpoint to directly access it.
Regarding stable device ids, something for you guys to ponder:
Currently I'm implementing a firmware update for a device using web-hid.
- You need to click to get auth to connect to the device
- You send a hid command to put the device into bootloader mode
- You have to use the chooser to reauth again to reconnect to the device
I don't know enough about usb/hid etc if there's anything stable for a given device that is the same between application and bootloader mode, but it would be nice if step 3 would work.
Would love to see this happen. We haven't implemented yet, but we are working with scales for a warehouse to use for shipping orders. The less we have to have them tinker with the better.
Regarding stable device ids, something for you guys to ponder:
Currently I'm implementing a firmware update for a device using web-hid.
- You need to click to get auth to connect to the device
- You send a hid command to put the device into bootloader mode
- You have to use the chooser to reauth again to reconnect to the device
I don't know enough about usb/hid etc if there's anything stable for a given device that is the same between application and bootloader mode, but it would be nice if step 3 would work.
I don't know a ton about usb/hid either, but the products I'm developing for have a different modelID when I switch the device to boot mode. The uniqueID that is no longer surface level ( compared to chrome.hid ) remains the same.
I'm not sure what the decision will be on this, but seeing that i just saw the email from chrome about webstore apps ( chrome.hid ) no longer functioning as of June 2020, I'm scrambling to find another solution in the meantime. We have about 20k devices in the field with users' custom configurations stored by uniqueID. As a stop-gap, the embedded software engineer has thought to have the firmware, upon startup, write the uniqueID to a memory location from which I am already reading configuration data. If that uniqueID is not there, I can force a firmware update to the device.
If you're not tied to units in the field with older bootcode ( like me ), the bootcode usb interface can be designed to read this uniqueID when the device is sent the specified USB command to retrieve it. Lucky for me, that command still exists in the bootcode of some of our older products.