Repository navigation
Don't expose USB serial port details #227
Description
The API currently proposes that the API reveal details of the vendor and device identifier of a USB serial port adapter in two ways:
- As part of the filtering logic when a port is requested.
- Through information revealed about the port when one has been obtained.
In neither case is this relevant information. The information that is relevant to what people might want to achieve is not available. That is to say: the identity of the thing that is plugged into the other end of the cable.
In the interests of YAGNI, I suggest that this information be removed from the API. In both requestPort() filtering and getInfo().
I understand that there might be some circumstances in which a USB-attached serial interface might cause problems that sites are aware of, but that is an internal matter for the host system. There is also the possibility that there are "serial" devices that are fused into a single unit, where the identity of the serial port is really the identity of the device and so knowing the identity of the port gives you the identity of the device. Neither case seems cause enough to justify breaking the rules here.
Activity
reillyeon commentedon Apr 9, 2026
Your analysis is unfortunately incorrect. While there are many cases where a generic USB to serial adapter is being used which creates a situation where the identity of the USB device is not the same as "the device on the other end of the cable" in the modern era where most "serial" devices are USB devices implementing the standard USB CDC-ACM class, or customized ICs from vendors like FTDI which return device-specific identifiers this information is in fact quite useful for sites to provide a better UX than returning the full list of all available serial ports.
While some generic tools such as web.esphome.io do not filter because they support such a large variety of devices that updating the filter would be burdensome tools designed for specific devices such as app.betaflight.com and web.unleashedflip.com do.
reillyeon commentedon Apr 9, 2026
Issue #178 is a related example of a "fused" device where additional USB information (not just USB vendor and product IDs) is substantially useful for a site trying to communicate with the device correctly.
nondebug commentedon Oct 30, 2026
I agree that USB vendor/product ID is relevant to applications trying to connect to the serial port but I think it's not appropriate to have USB-specific device identifiers exposed through SerialPort. It would be cleaner if we exposed this information as a relationship between the WebSerial port and the WebUSB device (which already has the relevant identifiers), perhaps by adding the UsbDevice object as a member to the SerialPortInfo struct.
Since WebSerial and WebUSB require different permission grants, the UsbDevice object accessed this way would not automatically allow the caller read/write access to the USB device. The caller would still need to use navigator.usb.requestDevice() to request permission to the device. Perhaps it would also make sense to expose a requestPermission() method on UsbDevice to request specific access.