Repository navigation
Device-based security measures from WebUSB don't work here #228
Description
This API has the marvelous property of being unable to identify the thing that is on the other end of the cable. That makes the device-specific security considerations that this attempts to inherit from WebUSB inapplicable. And yet the security considerations attempts to apply them anyway. This is misleading.
Devices on the other end of a serial interface might be able to identify themselves, but not at a level at which this API can operate. Maybe you can talk to them and they will tell you, but you have to start using the interface in order to do that and there is no way to guarantee that an attempt to do that wouldn't end up doing unwanted things to a device that didn't understand your attempts to communicate.
In any case, this text is probably impossible to act on:
A list of device IDs for hardware which is known to be exploitable could be deployed with the user agent. Connections to listed devices would be blocked. An implementation could use its automatic update or experiment management system to deploy updates to this list on the fly to block an active attack.
The text later basically admits that. Wouldn't it be better not to create the impression that this sort of mitigation is effective?
Activity
reillyeon commentedon Apr 9, 2026
#227 (comment) discusses why devices are sometimes identifiable and Chromium implements such a blocklisting mechanism.
reillyeon commentedon Apr 9, 2026
Granted, the examples I quote on that issue are still filtering for specific generic USB vendor and product IDs, e.g. STM Microelectronics.
nondebug commentedon Oct 30, 2026
The concern is valid for:
As noted, many serial devices are USB devices with built-in serial adapters and typically have non-generic vendor/product IDs. Browsers can match against these identifiers to implement a blocklist.
Some types of Bluetooth serial devices are supported through WebSerial implementations:
When the serial port is part of a Bluetooth device, the user agent can rely on Bluetooth identifiers to determine which device is connected and potentially block it. Additionally, if it is a RFCOMM service then it has a service UUID which can be blocklisted.
reillyeon commentedon Oct 30, 2026
Discussed at TPAC 2026. We should update the specification to document that while this mitigation is not available for all devices it can still be useful for some devices. So we should acknowledge the limitation in the specification.