USB API

Who will be responsible for this API? (Team please, not an individual)

Apps Extension API Team

OverviewThe USB API aims to provide access to fundamental low-level USB operations from within the context of an extension.

Use cases

- Devices which require third-party drivers to function in ChromeOS are currently unusable. One of the use cases for this API would be to provide the ability for a Chrome extension to function as a device driver and allow previously unusable devices to be used under ChromeOS.

- Conversely, this would also allow device driver implementors to be able to quickly deploy new driver versions to applications which are written within Chrome that make use of USB functionality, instead of depending on writing platform-dependent code.

Do you know anyone else, internal or external, that is also interested in this API?Not yet.

Could this API be part of the web platform?

Maybe. This API has the potential to be very controversial, and I believe there are people within the standards organization that would not back it.

Do you expect this API to be fairly stable? How might it be extended or changed in the future?

The API should remain fairly stable, as the fundamental mechanism for interacting with USB devices is standardized and does not change. This API will surface the underlying USB mechanisms for communication, and so itself should not need to change.

List every UI surface belonging to or potentially affected by your API:

- The extension installation dialog box (potentially). There should be a mechanism for informing users about the kinds of USB devices that an extension wishes to access, and this information should be surfaced.

How could this API be abused?

- This API could be used (without per-extension VID/PID lockdown) to map the devices attached to a computer, thereby gaining knowledge outside of the scope of the extension.

- This API could be used to cause physical devices to damage themselves or their surroundings. I've yet to see a printer catch fire due to software commands, but I would not rule the possibility out, for example.

Alright Doctor, one last challenge: Could a consumer of your API cause any permanent change to the user’s system using your API that would not be reversed when that consumer is removed from the system?

Yes. There are circumstances where a USB device could be put into a bad state (or frozen entirely!) that may be impossible to restore to a pristine state without physically reconnecting the device. The attached devices could also, for example, themselves leave a physical trace. A printer driver could print a page, a CD writer could write a disc, a robot karate arm could break a table, etc.

How would you implement your desired features if this API didn't exist?

By writing code that used libusb and then surfacing some form of WebSocket interface that would allow a client to communicate with my device-specific server.