WebUSB API

1. Introduction

This section is non-normative.

The Universal Serial Bus (USB) is the de-facto standard for wired peripherals. Most USB devices implement one of roughly a dozen standard "device classes" which specify a way for the device to advertise the features it supports and commands and data formats for using those features. Standard device classes include keyboard, mice, audio, video and storage devices. Operating systems support such devices using the "class driver" provided by the OS vendor. There is however a long tail of devices that do not fit into one of the standardized device classes. These devices require hardware vendors to write native drivers and SDKs in order for developers to take advantage of them and this native code prevents these devices from being used by the web.

The WebUSB API provides a way to safely expose USB device services to the web. It provides an API familiar to developers who have used existing native USB libraries and exposes the device interfaces defined by existing specifications. With this API hardware manufacturers will have the ability to build cross-platform JavaScript SDKs for their devices. This will be good for the web because, instead of waiting for a new kind of device to be popular enough for browsers to provide a specific API, new and innovative hardware can be built for the web from day one.

For more information about USB see § 10 Appendix: A Brief Introduction to USB.

2. Motivating Applications

This section is non-normative.

2.1. Educational Devices

The software delivery model of the web is a key enabler for educational applications because they can be quickly loaded on any computer without questions of platform compatibility or administrative credentials. Science classes are incorporating computerized measurement and data logging into their lessons. These tools require bundled software that may be difficult to install on managed computers as every new native application adds overhead to an already stressed IT department. Web-based hardware APIs allow support for these devices to be built directly into existing online course materials, providing a completely seamless experience.

Students learning to code with one of the many microcontroller development kits can take advantage of online developer tools to write and upload their code. These tools already exist however they require a native component to interface between the browser and the hardware. These native extensions add a barrier to entry and may expose the user to security vulnerabilities in a way that that code running in the sandboxed web environment does not.

2.2. Web Drivers

The composablity of the web allows a new ecosystem of hardware support to be built entirely from web technology. Taking 3D printers an example, imagine that a site hosting 3D object designs wants to integrate printing directly into their page. The web supports 2D printing but there is no API for the 3D variety. If manufacturers host embeddable pages that use the WebUSB API to send data to their printers, sites can use these pages to integrate support for the hardware in the same way that features such as embedded maps are added to many existing sites.

2.3. Devices Updates and Diagnostics

While wireless protocols such as Bluetooth are often the more convenient choice for consumer devices USB ports continue to proliferate because they are an easy solution for power delivery and can serve as the connection of last resort when the device isn’t working. By integrating update and diagnostic tools into their support site a hardware manufacturer can provide tools for customers on any platform and collect better diagnostic data when a customer reaches out for support through their website. The landing page provides a way for the device manufacturer to direct the user to the right part of their website for help with their device.

3. Security and Privacy Considerations

This section is non-normative.

The WebUSB API is a powerful feature and has the possibility to expose users to a number of new privacy and security risks. These risks can be broadly divided into three categories that will be described in the sections below.

3.1. Abusing Access to a Device

Peripheral devices can serve a number of purposes. They may store data, as a flash drive does. They may collect information about the outside world as a camera or microphone does. They may manipulate objects in the outside world as a printer does. Each of the examples above have high-level APIs in the web platform with security features that aim to prevent their abuse by a malicious website. Storing data to or from an external drive requires the user to select the file manually. Turning on the microphone or camera requires permission from the user and may activate an indicator to let the user know data collection is in progress. Printing a document requires explicit action as well. This API provides a generic mechanism to connect to devices not covered by these existing high-level APIs and so it requires a similarly generic mechanism for preventing a malicious page from abusing a device.

The first of these protections is the requestDevice() function. The UA may display a permission prompt when this function is called. Even for a non-malicious page this action also preserves user privacy by preventing a site from connecting to a device before the user is aware that such a connection is possible. The UA may also display an indicator when a device connection is active.

Secondly, this specification requires that only secure contexts as described in [powerful-features] can access USB devices. This ensures both the authenticity of the code executing on behalf of the origin and that data read from the device may not be intercepted in transit.

Lastly, since USB devices are unable to distinguish requests from multiple sources, operating systems only allow a USB interface to have a single owning user-space or kernel-space driver. The UA acts as a user-space driver, therefore allowing only a single execution context to claim a USB interface at a time. The claimInterface() function will fail if multiple execution contexts attempt to claim an interface.

3.2. Attacking a Device

Historically, unless they were created for high security applications, USB devices have been designed to trust the host they are connected to and so the host is the traditional guardian of access to the capabilities a device provides. In the development of this specification two possibilities were considered. First, the UA could notify the device of the origin from which a request originated. This would be similar to the Referrer header included in HTTP request. The difficulty of this approach is that it places the burden of access control on the device. Devices often have very limited processing and storage capabilities and so an effort was made to limit the amount of work necessary on the part of the device.

The approach initially chosen during drafting of this specification was to instead require that the UA control access though a mechanism similiar to [CORS]. The device could provide the UA with a set of static data structures defining a set of origins that are allowed to connect to it. To support a transition period for existing devices it was proposed that information about allowed origins could also be provided out of band through some kind of public registry.

A downside of this approach was two-fold. First, it required vendors to build new devices with WebUSB in mind or rely on a public registry system that proved difficult to specify. Product development cycles are long and as only an Editor’s Draft this specification does not have the clout necessary to influence product planning. Second, it provided no mechanism for third-party developers to use this API with a device. This limited innovation and the number of developers who could take advantage of this new capability.

After considering these options the authors have decided that the permission prompt encouraged by the requestDevice() method and the integration with § 8.1 Permissions Policy provide adequate protection against unwanted access to a device.

3.3. Attacking the Host

If a device is compromised then in addition to abusing its own capabilities the attacker may also use it to in turn attack the host to which it is connected or if the exploit is persistent any host it is connected to later. The methods above are the ways in which this specification attempts to mitigate this attack vector for once the device is under the control of an attacker (for example, by uploading a malicious firmware image) there is nothing that can be done by the UA to prevent further damage.

This specification recommends device manufacturers practice defense in depth by designing their devices to only accept signed firmware updates and/or require physical access to the device in order to apply some configuration changes.

4. WebUSB Descriptors and Requests

This specification defines descriptors and commands the UA MAY use to gather information about the device specific to implementing this API.

4.1. WebUSB Platform Capability Descriptor

A device announces support for the WebUSB command set by including the following Platform Descriptor in its Binary Object Store:

The iLandingPage field, when non-zero, indicates a landing page which the device manufacturer would like the user to visit in order to control their device. The UA MAY suggest the user navigate to this URL when the device is connected.

Note: The USB is a little-endian bus and so according to [RFC4122] the UUID above MUST be sent over the wire as the byte sequence {0x38, 0xB6, 0x08, 0x34, 0xA9, 0x09, 0xA0, 0x47, 0x8B, 0xFD, 0xA0, 0x76, 0x88, 0x15, 0xB6, 0x65}.

4.2. WebUSB Device Requests

All control transfers defined by this specification are considered to be vendor-specific requests. The bVendorCode value found in the WebUSB Platform Capability Descriptor provides the UA with the bRequest the device expects the host to use when issuing control transfers these requests. The request type is then specified in the wIndex field.

4.2.1. Get URL

This request fetches the URL descriptor with the given index.

The device MUST respond with the URL Descriptor at the given index or stall the transfer if the index is invalid.

4.3. WebUSB Descriptors

These descriptor types are returned by requests defined in this specification.

4.3.1. URL Descriptor

This descriptor contains a single URL and is returned by the Get URL request.

The bScheme field MUST be one of these values:

The special value 255 indicates that the entire URL, including scheme, is encoded in the URL field.

5. Device Enumeration

dictionary USBDeviceFilter {
  unsigned short vendorId;
  unsigned short productId;
  octet classCode;
  octet subclassCode;
  octet protocolCode;
  DOMString serialNumber;
};

dictionary USBDeviceRequestOptions {
  required sequence<USBDeviceFilter> filters;
  sequence<USBDeviceFilter> exclusionFilters = [];
};

[Exposed=(Worker,Window), SecureContext]
interface USB : EventTarget {
  attribute EventHandler onconnect;
  attribute EventHandler ondisconnect;
  Promise<sequence<USBDevice>> getDevices();
  [Exposed=Window] Promise<USBDevice> requestDevice(USBDeviceRequestOptions options);
};

[Exposed=Window, SecureContext]
partial interface Navigator {
  [SameObject] readonly attribute USB usb;
};

[Exposed=Worker, SecureContext]
partial interface WorkerNavigator {
  [SameObject] readonly attribute USB usb;
};

document.addEventListener('DOMContentLoaded', async () => {
  let devices = await navigator.usb.getDevices();
  devices.forEach(device => {
    // Add |device| to the UI.
  });
});

navigator.usb.addEventListener('connect', event => {
  // Add |event.device| to the UI.
});

navigator.usb.addEventListener('disconnect', event => {
  // Remove |event.device| from the UI.
});

let button = document.getElementById('request-device');
button.addEventListener('click', async () => {
  let device;
  try {
    device = await navigator.usb.requestDevice({ filters: [{
        vendorId: 0xABCD,
        classCode: 0xFF, // vendor-specific
        protocolCode: 0x01
    }]});
  } catch (err) {
    // No device was selected.
  }

  if (device !== undefined) {
    // Add |device| to the UI.
  }
});

A USB device device matches a device filter filter if the following steps return match:

1. Let deviceDesc be device’s device descriptor.

2. If filter.vendorId is present and deviceDesc.idVendor does not equal filter.vendorId, return mismatch.

3. If filter.productId is present and deviceDesc.idProduct does not equal filter.productId, return mismatch.

4. If filter.serialNumber is present then, let serialNumber be the string descriptor with index deviceDesc.iSerialNumber. If device returns an error when requesting serialNumber or serialNumber is not equal to filter.serialNumber, return mismatch.

5. If filter.classCode is present and, for any of device’s interface’s interface, interface matches the interface filter filter, return match.

6. If filter.classCode is present and deviceDesc.bDeviceClass is not equal to filter.classCode, return mismatch.

7. If filter.subclassCode is present and deviceDesc.bDeviceSubClass is not equal to filter.subclassCode, return mismatch.

8. If filter.protocolCode is present and deviceDesc.bDeviceProtocol is not equal to filter.protocolCode, return mismatch.

9. Return match.

Note: The steps above treat the bDeviceClass, bDeviceSubClass and bDeviceProtocol fields of the device descriptor as though they were part of an interface descriptor which is also compared against the provided filter.

A USB interface interface matches an interface filter filter if the following steps return match:

1. Let desc be interface’s interface descriptor.

2. If filter.classCode is present and desc.bInterfaceClass is not equal to filter.classCode, return mismatch.

3. If filter.subclassCode is present and desc.bInterfaceSubClass is not equal to filter.subclassCode, return mismatch.

4. If filter.protocolCode is present and desc.bInterfaceProtocol is not equal to filter.protocolCode, return mismatch.

5. Return match.

A USBDeviceFilter filter is valid if the following steps return valid:

1. If filter.productId is present and filter.vendorId is not present, return invalid.

2. If filter.subclassCode is present and filter.classCode is not present, return invalid.

3. If filter.protocolCode is present and filter.subclassCode is not present, return invalid.

4. Return valid.

The UA MUST be able to enumerate all devices attached to the system. It is, however NOT required to perform this work each time an algorithm requests an enumeration. The UA MAY cache the result of the first enumeration it performs and then begin monitoring for device connection and disconnection events, adding connected devices to its cached enumeration and removing disconnected devices. This mode of operation is preferred as it reduces the number of operating system calls made and amount of bus traffic generated by the getDevices() and requestDevice() methods.

The onconnect attribute is an Event handler IDL attribute for the connect event type.

The ondisconnect attribute is an Event handler IDL attribute for the disconnect event type.

The getDevices() method, when invoked, MUST return a new Promise and run the following steps in parallel:

1. Let document be this’s relevant global object's associated Document, or null if there is no associated Document.

2. Let storage be:

   1. The USBPermissionStorage object in the script execution environment of the associated service worker client, if this's relevant global object is a ServiceWorkerGlobalScope.

   2. Otherwise, the USBPermissionStorage object in the current script execution environment.

3. Enumerate all devices attached to the system. Let this result be enumerationResult.

4. Let devices be a new empty Array.

5. For each device in enumerationResult:

   1. If device is blocklisted for document, continue.

   2. If this is the first call to this method, check permissions for device with storage.

   3. Search for an element allowedDevice in storage.allowedDevices where device is in allowedDevice@[[devices]]. If no such element exists, continue to the next device.

   4. Add the USBDevice object representing device to devices.

6. Resolve promise with devices.

The requestDevice() method, when invoked, MUST run the following steps:

1. Request permission to use the following descriptor,

   {
     name: "usb"
     filters: options.filters
     exclusionFilters: options.exclusionFilters
   }
   

   Let permissionResult be the resulting Promise.

2. Upon fulfillment of permissionResult with result run the following steps:

   1. If result.devices is empty, throw a NotFoundError and abort these steps.

   2. Return result.devices[0].

To request the "usb" permission, given a Document document, a USBPermissionStorage storage, a USBPermissionDescriptor options and a USBPermissionResult status, the UA MUST return a new Promise promise and run the following steps in parallel:

1. For each filter in options.filters if filter is not a valid filter reject promise with a TypeError and abort these steps.

2. For each exclusionFilter in options.exclusionFilters if exclusionFilter is not a valid filter reject promise with a TypeError and abort these steps.

3. Check that the algorithm was triggered while the relevant global object had a transient activation. Otherwise, reject promise with a SecurityError and abort these steps.

4. Set status.state to "ask".

5. Enumerate all devices attached to the system. Let this result be enumerationResult.

6. Remove devices from enumerationResult if they are blocklisted for document.

7. Remove devices from enumerationResult if they do not match a device filter in options.filters.

8. Remove devices from enumerationResult if they match a device filter in options.exclusionFilters.

9. Display a prompt to the user requesting they select a device from enumerationResult. The UA SHOULD show a human-readable name for each device.

10. Wait for the user to have selected a device or cancelled the prompt.

11. If the user cancels the prompt, set status.devices to an empty FrozenArray, resolve promise with undefined, and abort these steps.

12. Add device to storage.

13. Let deviceObj be the USBDevice object representing device.

14. Set status.devices to a new FrozenArray containing deviceObj as its only element.

15. Resolve promise with undefined.

To add an allowed USB device device to USBPermissionStorage storage, the UA MUST run the following steps:

1. Search for an element allowedDevice in storage.allowedDevices where device is in allowedDevice@[[devices]]. If one is found, abort these steps.

2. Let vendorId and productId be device’s vendor ID and product ID.

3. Let serialNumber be device’s serial number if it has one, otherwise undefined.

4. Append { vendorId: vendorId, productId: productId, serialNumber: serialNumber }, with a [[devices]] internal slot containing a single entry device to storage.allowedDevices.

To check permissions for a new USB device device, given a USBPermissionStorage storage, the UA MUST run the following steps:

1. Let vendorId and productId be device’s vendor ID and product ID.

2. Let serialNumber be device’s if it has one, otherwise undefined.

3. Search for an element allowedDevice in storage.allowedDevices where:

   • allowedDevice.vendorId equals vendorId.

   • allowedDevice.productId equals productId.

   • allowedDevice.serialNumber equals serialNumber.

4. If no such element exists, return null.

5. Add device to allowedDevice@[[devices]].

6. Return allowedDevice.

To remove an allowed USB device device, given a USBPermissionStorage storage, the UA MUST run the following steps:

1. Search for an element allowedDevice in storage.allowedDevices where device is in allowedDevice@[[devices]], if no such element exists, abort these steps.

2. Remove allowedDevice from storage.allowedDevices.

5.1. Events

dictionary USBConnectionEventInit : EventInit {
    required USBDevice device;
};

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBConnectionEvent : Event {
  constructor(DOMString type, USBConnectionEventInit eventInitDict);
  [SameObject] readonly attribute USBDevice device;
};

Note: Workers may register event listeners for connect and disconnect events but the event listener will not be invoked unless the worker is active.

When the UA detects a new USB device device connected to the host it MUST perform the following steps for each script execution environment:

1. Let storage be the USBPermissionStorage object in the current script execution environment.

2. Check permissions for device with storage and let allowedDevice be the result.

3. If allowedDevice is null, abort these steps.

4. Let deviceObj be the USBDevice object representing device.

5. Fire an event named connect on device’s relevant global object's Navigator object’s usb, using USBConnectionEvent, with the device attribute set to deviceObj.

When the UA detects a USB device device has been disconnected from the host it MUST perform the following steps for each script execution environment:

1. Let storage be the USBPermissionStorage object in the current script execution environment.

2. Search for an element allowedDevice in storage.allowedDevices where device is in allowedDevice@[[devices]], if no such element exists, abort these steps.

3. Remove device from allowedDevice@[[devices]].

4. If allowedDevice.serialNumber is undefined and allowedDevice@[[devices]] is empty remove allowedDevice from storage.allowedDevices.

5. Let device be the USBDevice object representing device.

6. Fire an event named disconnect on device’s relevant global object's Navigator object’s usb, using USBConnectionEvent, with the device attribute set to device.

6. Device Usage

await device.open();
if (device.configuration === null)
  await device.selectConfiguration(1);
await device.claimInterface(1);

await device.controlTransferOut({
    requestType: 'vendor',
    recipient: 'interface',
    request: 0x01,  // vendor-specific request: enable channels
    value: 0x0013,  // 0b00010011 (channels 1, 2 and 5)
    index: 0x0001   // Interface 1 is the recipient
});

while (true) {
  let result = await device.transferIn(1, 6);

  if (result.data && result.data.byteLength === 6) {
    console.log('Channel 1: ' + result.data.getUint16(0));
    console.log('Channel 2: ' + result.data.getUint16(2));
    console.log('Channel 5: ' + result.data.getUint16(4));
  }

  if (result.status === 'stall') {
    console.warn('Endpoint stalled. Clearing.');
    await device.clearHalt(1);
  }
}

6.1. The USBDevice Interface

enum USBTransferStatus {
  "ok",
  "stall",
  "babble"
};

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBInTransferResult {
  constructor(USBTransferStatus status, optional DataView? data);
  readonly attribute DataView? data;
  readonly attribute USBTransferStatus status;
};

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBOutTransferResult {
  constructor(USBTransferStatus status, optional unsigned long bytesWritten = 0);
  readonly attribute unsigned long bytesWritten;
  readonly attribute USBTransferStatus status;
};

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBIsochronousInTransferPacket {
  constructor(USBTransferStatus status, optional DataView? data);
  readonly attribute DataView? data;
  readonly attribute USBTransferStatus status;
};

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBIsochronousInTransferResult {
  constructor(sequence<USBIsochronousInTransferPacket> packets, optional DataView? data);
  readonly attribute DataView? data;
  readonly attribute FrozenArray<USBIsochronousInTransferPacket> packets;
};

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBIsochronousOutTransferPacket {
  constructor(USBTransferStatus status, optional unsigned long bytesWritten = 0);
  readonly attribute unsigned long bytesWritten;
  readonly attribute USBTransferStatus status;
};

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBIsochronousOutTransferResult {
  constructor(sequence<USBIsochronousOutTransferPacket> packets);
  readonly attribute FrozenArray<USBIsochronousOutTransferPacket> packets;
};

[Exposed=(DedicatedWorker,SharedWorker,Window), SecureContext]
interface USBDevice {
  readonly attribute octet usbVersionMajor;
  readonly attribute octet usbVersionMinor;
  readonly attribute octet usbVersionSubminor;
  readonly attribute octet deviceClass;
  readonly attribute octet deviceSubclass;
  readonly attribute octet deviceProtocol;
  readonly attribute unsigned short vendorId;
  readonly attribute unsigned short productId;
  readonly attribute octet deviceVersionMajor;
  readonly attribute octet deviceVersionMinor;
  readonly attribute octet deviceVersionSubminor;
  readonly attribute DOMString? manufacturerName;
  readonly attribute DOMString? productName;
  readonly attribute DOMString? serialNumber;
  readonly attribute USBConfiguration? configuration;
  readonly attribute FrozenArray<USBConfiguration> configurations;
  readonly attribute boolean opened;
  Promise<undefined> open();
  Promise<undefined> close();
  Promise<undefined> forget();
  Promise<undefined> selectConfiguration(octet configurationValue);
  Promise<undefined> claimInterface(octet interfaceNumber);
  Promise<undefined> releaseInterface(octet interfaceNumber);
  Promise<undefined> selectAlternateInterface(octet interfaceNumber, octet alternateSetting);
  Promise<USBInTransferResult> controlTransferIn(USBControlTransferParameters setup, unsigned short length);
  Promise<USBOutTransferResult> controlTransferOut(USBControlTransferParameters setup, optional BufferSource data);
  Promise<undefined> clearHalt(USBDirection direction, octet endpointNumber);
  Promise<USBInTransferResult> transferIn(octet endpointNumber, unsigned long length);
  Promise<USBOutTransferResult> transferOut(octet endpointNumber, BufferSource data);
  Promise<USBIsochronousInTransferResult> isochronousTransferIn(octet endpointNumber, sequence<unsigned long> packetLengths);
  Promise<USBIsochronousOutTransferResult> isochronousTransferOut(octet endpointNumber, BufferSource data, sequence<unsigned long> packetLengths);
  Promise<undefined> reset();
};

Instances of USBDevice are created with the internal slots described in the following table:

All USB devices MUST have a default control pipe which is endpointNumber 0.

6.1.1. Attributes

usbVersionMajor, of type octet, readonly

usbVersionMinor, of type octet, readonly

usbVersionSubminor, of type octet, readonly

The usbVersionMajor, usbVersionMinor and usbVersionSubminor attributes declare the USB protocol version supported by the device. They SHALL correspond to the value of the bcdUSB field of the device descriptor such that a value of 0xJJMN has major version JJ, minor version M and subminor version N.

deviceClass, of type octet, readonly

deviceSubclass, of type octet, readonly

deviceProtocol, of type octet, readonly

The deviceClass, deviceSubclass and deviceProtocol attributes declare the communication interface supported by the device. They MUST correspond respectively to the values of the bDeviceClass, bDeviceSubClass and bDeviceProtocol fields of the device descriptor.

vendorId, of type unsigned short, readonly

productId, of type unsigned short, readonly

The vendorId and productId MUST be equal to the device’s vendor ID and product ID.

deviceVersionMajor, of type octet, readonly

deviceVersionMinor, of type octet, readonly

deviceVersionSubminor, of type octet, readonly

The deviceVersionMajor, deviceVersionMinor and deviceVersionSubminor attributes declare the device release number as defined by the device manufacturer. It SHALL correspond to the value of the bcdDevice field of the device descriptor such that a value of 0xJJMN has major version JJ, minor version M and subminor version N.

manufacturerName, of type DOMString, readonly, nullable

productName, of type DOMString, readonly, nullable

serialNumber, of type DOMString, readonly, nullable

The manufacturerName, productName and serialNumber attributes SHOULD contain the values of the string descriptors indexed by the iManufacturer, iProduct and iSerialNumber fields of the device descriptor if each is defined.

configuration, of type USBConfiguration, readonly, nullable

The configuration attribute contains the currently selected configuration for the device and SHALL be one of the USBConfiguration in configurations.

The configuration getter steps are:

1. Return the result of finding the current configuration with this.

configurations, of type FrozenArray<USBConfiguration>, readonly

The configurations attribute contains a sequence of USBConfiguration representing configurations supported by the device.

The configurations getter steps are:

1. Return this.[[configurations]].

opened, of type boolean, readonly

The opened attribute SHALL be set to true when the device is opened by the current execution context and SHALL be set to false otherwise.

6.1.2. Methods

6.2. The USBControlTransferParameters Dictionary

enum USBRequestType {
  "standard",
  "class",
  "vendor"
};

enum USBRecipient {
  "device",
  "interface",
  "endpoint",
  "other"
};

dictionary USBControlTransferParameters {
  required USBRequestType requestType;
  required USBRecipient recipient;
  required octet request;
  required unsigned short value;
  required unsigned short index;
};

6.2.1. Members

requestType, of type USBRequestType

The requestType attribute populates part of the bmRequestType field of the setup packet to indicate whether this request is part of the USB standard, a particular USB device class specification or a vendor-specific protocol.

recipient, of type USBRecipient

The recipient attribute populates part of the bmRequestType field of the setup packet to indicate whether the control transfer is addressed to the entire device, or a specific interface or endpoint.

request, of type octet

The request attribute populates the bRequest field of the setup packet. Valid requests are defined by the USB standard, USB device class specifications or the device vendor.

value, of type unsigned short

The value and index attributes populate the wValue and wIndex fields of the setup packet respectively. The meaning of these fields depends on the request being made.

6.3. The USBConfiguration Interface

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBConfiguration {
  constructor(USBDevice device, octet configurationValue);
  readonly attribute octet configurationValue;
  readonly attribute DOMString? configurationName;
  readonly attribute FrozenArray<USBInterface> interfaces;
};

Instances of USBConfiguration are created with the internal slots described in the following table:

6.3.1. Constructors

6.3.2. Attributes

configurationValue, of type octet, readonly

Each device configuration SHALL have a unique configurationValue that matches the bConfigurationValue fields of the configuration descriptor that defines it.

configurationName, of type DOMString, readonly, nullable

The configurationName attribute SHOULD contain the value of the string descriptor referenced by the iConfiguration field of the configuration descriptor, if defined.

interfaces, of type FrozenArray<USBInterface>, readonly

The interfaces attribute SHALL contain a list of interfaces exposed by this device configuration.

The interfaces getter steps are:

1. Return this.[[interfaces]].

Include some non-normative information about device configurations. [Issue #46]

6.4. The USBInterface Interface

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBInterface {
  constructor(USBConfiguration configuration, octet interfaceNumber);
  readonly attribute octet interfaceNumber;
  readonly attribute USBAlternateInterface alternate;
  readonly attribute FrozenArray<USBAlternateInterface> alternates;
  readonly attribute boolean claimed;
};

Instances of USBInterface are created with the internal slots described in the following table:

An interface descriptor interface has a protected interface class if and only if interface’s bInterfaceClass is equal to one of the following values.

Note: This specification attempts to strike a balance between protecting users from malicious content by limiting access to sensitive devices while enabling support for as many devices as possible. As stated in the introduction the goal of this API is to support devices which are not covered by other, more high level APIs. The list above includes interface classes for which such high level APIs exist and provide greater protection for user privacy and security than low level access through this API would.

6.4.1. Constructors

6.4.2. Attributes

interfaceNumber, of type octet, readonly

Each interface provides a collection of alternates identified by a single bInterfaceNumber field found in their interface descriptors. The interfaceNumber attribute MUST match this field.

The interfaceNumber getter steps are:.

1. Return this.[[interfaceNumber]].

alternate, of type USBAlternateInterface, readonly

The alternate attribute SHALL be set to the USBAlternateInterface that is currently selected for this interface, which by default SHALL be the one with bAlternateSetting equal to 0.

The alternate getter steps are:

1. Return the result of finding the alternate interface for the current alternate setting with this.

alternates, of type FrozenArray<USBAlternateInterface>, readonly

The alternates method provides a collection of USBAlternateInterface objects identified by a single bInterfaceNumber field found in their interface descriptors.

The alternates getter steps are:

1. Return this.[[alternates]].

claimed, of type boolean, readonly

The claimed attribute SHALL be set to true when the interface is claimed by the current execution context and SHALL be set to false otherwise.

The claimed getter steps are:

1. Return the result of finding if the interface is claimed with this.

6.5. The USBAlternateInterface Interface

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBAlternateInterface {
  constructor(USBInterface deviceInterface, octet alternateSetting);
  readonly attribute octet alternateSetting;
  readonly attribute octet interfaceClass;
  readonly attribute octet interfaceSubclass;
  readonly attribute octet interfaceProtocol;
  readonly attribute DOMString? interfaceName;
  readonly attribute FrozenArray<USBEndpoint> endpoints;
};

Instances of USBAlternateInterface are created with the internal slots described in the following table:

6.5.1. Constructors

6.5.2. Attributes

alternateSetting, of type octet, readonly

Each alternative interface configuration SHALL have a unique alternateSetting within a given interface that matches the bAlternateSetting field of the interface descriptor that defines it.

interfaceClass, of type octet, readonly

interfaceSubclass, of type octet, readonly

interfaceProtocol, of type octet, readonly

The interfaceClass, interfaceSubclass and interfaceProtocol attributes declare the communication interface supported by the interface. They MUST correspond respectively to the values of the bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol fields of the interface descriptor.

interfaceName, of type DOMString, readonly, nullable

The interfaceName attribute SHOULD contain the value of the string descriptor indexed by the iInterface field of the interface descriptor, if defined.

endpoints, of type FrozenArray<USBEndpoint>, readonly

The endpoints attribute SHALL contain a list of endpoints exposed by this interface. These endpoints SHALL by populated from the endpoint descriptors contained within this interface descriptor and the number of elements in this sequence SHALL match the value of the bNumEndpoints field of the interface descriptor.

The endpoints getter steps are:

1. Return this.[[endpoints]].

6.6. The USBEndpoint Interface

enum USBDirection {
  "in",
  "out"
};

enum USBEndpointType {
  "bulk",
  "interrupt",
  "isochronous"
};

[
  Exposed=(DedicatedWorker,SharedWorker,Window),
  SecureContext
]
interface USBEndpoint {
  constructor(USBAlternateInterface alternate, octet endpointNumber, USBDirection direction);
  readonly attribute octet endpointNumber;
  readonly attribute USBDirection direction;
  readonly attribute USBEndpointType type;
  readonly attribute unsigned long packetSize;
};

Instances of USBEndpoint are created with the internal slots described in the following table:

6.6.1. Constructors

6.6.2. Attributes

endpointNumber, of type octet, readonly

direction, of type USBDirection, readonly

Each endpoint within a particular device configuration SHALL have a unique combination of endpointNumber and direction. The endpointNumber MUST equal the 4 least significant bits of the bEndpointAddress field of the endpoint descriptor defining the endpoint.

The direction attribute declares the transfer direction supported by this endpoint and is equal to "in" if the most significant bit of the bEndpointAddress is set and "out" otherwise. An endpoint may either carry data IN from the device to host or OUT from host to device.

type, of type USBEndpointType, readonly

The type attribute declares the type of data transfer supported by this endpoint.

The type getter steps are:

1. Let endpointDescriptor be the result of finding the endpoint descriptor with this.

2. Let attr be bmAttributes of endpointDescriptor.

3. Let typeBits be attr & 0x3.

4. If typeBits is equal to b01, return "isochronous".

5. If typeBits is equal to b10, return "bulk".

6. If typeBits is equal to b11, return "interrupt".

Note: There shouldn’t be any endpoint object belongs to Control Transfer Type according to the steps in USBAlternateInterface(deviceInterface,alternateSetting).

packetSize, of type unsigned long, readonly

The packetSize attribute declares the packet size employed by this endpoint and MUST be equal to the value of the wMaxPacketSize of the endpoint descriptor defining it. In a High-Speed, High-Bandwidth endpoint this value will include the multiplication factor provided by issuing multiple transactions per microframe. In a SuperSpeed device this value will include the multiplication factor provided by the bMaxBurst field of the SuperSpeed Endpoint Companion descriptor.

The packetSize getter steps are:

1. Let endpointDescriptor be the result of finding the endpoint descriptor with this.

2. Return wMaxPacketSize of endpointDescriptor.

7. The USB Blocklist

// USBBlocklistEntry is never exposed.
dictionary USBBlocklistEntry {
  required unsigned short idVendor;
  required unsigned short idProduct;
  required unsigned short bcdDevice;
};

This specification relies on a blocklist.txt file in this repository to restrict the set of devices a website can access.

The result of parsing the blocklist at a URL url is a list of USBBlocklistEntry objects produced by the following algorithm:

1. Fetch url and let contents be its body, decoded as UTF-8.

2. Let lines be the result of strictly splitting contents starting from the beginning of contents on code point '\n'.

3. Let blocklist be an empty list.

4. For each line of lines:

   1. Set line to the result of collecting a sequence of code points not equal to '#' from line starting from the beginning of line.

   2. Set line to the result of stripping leading and trailing ASCII whitespace from line.

   3. Let components be the result of strictly splitting line starting from the beginning of line on code point ':'.

   4. If the size of components is not 2 or 3, continue.

   5. Let idVendor be the result of interpreting components[0] as a hexadecimal number.

   6. Let idProduct be the result of interpreting components[1] as a hexadecimal number.

   7. Let bcdDevice be 0xFFFF.

   8. If the size of components is 3, set bcdDevice to the result of interpreting components[2] as a hexadecimal number.

   9. Append a new USBBlocklistEntry with idVendor, idProduct, and bcdDevice to blocklist.

5. Return blocklist.

The USB blocklist is the result of parsing the blocklist at https://raw.githubusercontent.com/WICG/webusb/main/blocklist.txt. The UA should re-fetch the blocklist periodically, but it’s unspecified how often.

A USBDevice device is blocklisted for a Document document if the following steps return "blocked":

1. If document is not null and document is allowed to use the policy-controlled feature named "usb-unrestricted", return "not blocked".

2. For each entry of the USB blocklist:

   1. If device.vendorId is not equal to entry.idVendor, continue.

   2. If device.productId is not equal to entry.idProduct, continue.

   3. Let bcdDevice be device.deviceVersionMajor << 8 + device.deviceVersionMinor << 4 + device.deviceVersionSubminor.

   4. If bcdDevice is less than or equal to entry.bcdDevice, return "blocked".

3. Return "not blocked".

8. Integrations

8.1. Permissions Policy

This specification defines a policy-controlled feature, identified by the token "usb", that controls whether the usb attribute is exposed on the Navigator object.

The default allowlist for this feature is ["self"].

This specification defines a second policy-controlled feature, identified by the token "usb-unrestricted", that controls whether blocklisted USB devices and device interfaces with protected classes can be accessed. This feature MUST only be enabled for Isolated Web Apps that declare the feature in the Web Application Manifest [APPMANIFEST].

The default allowlist for this feature is ["self"]. Typically this would imply that the feature is allowed in Documents in top-level traversables by default. However, due to the requirement that this feature is only enabled for Isolated Web Apps with the feature declared in the manifest, the effective default allowlist is ["none"].

8.2. Permission API

The [permissions] API provides a uniform way for websites to request permissions from users and query which permissions they have.

The "usb" powerful feature is defined as follows:

permission descriptor type

dictionary USBPermissionDescriptor : PermissionDescriptor {
  sequence<USBDeviceFilter> filters;
  sequence<USBDeviceFilter> exclusionFilters;
};

extra permission data type

USBPermissionStorage, defined as:

dictionary AllowedUSBDevice {
  required octet vendorId;
  required octet productId;
  DOMString serialNumber;
};

dictionary USBPermissionStorage {
  sequence<AllowedUSBDevice> allowedDevices = [];
};

AllowedUSBDevice instances have an internal slot [[devices]] that holds an array of USB devices.

permission result type

[Exposed=(DedicatedWorker,SharedWorker,Window)]
interface USBPermissionResult : PermissionStatus {
  attribute FrozenArray<USBDevice> devices;
};

permission query algorithm

To query the "usb" permission with a USBPermissionDescriptor desc, a USBPermissionStorage storage, and a USBPermissionResult status, the UA must:

1. If desc.filters is set then, for each filter in desc.filters if filter is not a valid filter then raise a TypeError and abort these steps.

2. If desc.exclusionFilters is set then, for each exclusionFilter in desc.exclusionFilters if exclusionFilter is not a valid filter then raise a TypeError and abort these steps.

3. Set status.state to "prompt".

4. Let matchingDevices be a new Array.

5. For each allowedDevice in storage.allowedDevices and for each device in allowedDevice@[[devices]], run the following substeps:

   1. If desc.filters is set and device does not match a device filter in desc.filters, continue to the next device.

   2. If desc.exclusionFilters is set and device matches a device filter in desc.exclusionFilters, continue to the next device.

   3. Get the USBDevice representing device and add it to matchingDevices.

6. Set status.devices to a new FrozenArray whose contents are matchingDevices.

permission request algorithm

Request the "usb" permission.

9. Terminology

This specification uses several terms taken from [USB31]. While reference is made to version 3.1 of the Universal Serial Bus many of these concepts exist in previous versions as well. Significant differences between USB versions that have bearing on this specification will be called out explicitly.

Descriptors are binary data structures that can be read from a device and describe its properties and function:

• The device descriptor contains information applicable to the entire devices and is described in section 9.6.1 of [USB31].

• A configuration descriptor describes a particular set of device interfaces and endpoints that can be selected by the host. Its fields are described in section 9.6.3 of [USB31].

• An interface descriptor describes the interface of a particular functional component of a device including its protocol and communication endpoints. Its fields are described in section 9.6.5 of [USB31].

• An interface association descriptor creates an association between multiple interfaces that are part of a single functional unit of a device. Its fields are described in section 9.6.4 of [USB31].

• An endpoint descriptor describes a channel through which data is either sent to or received from the device. Its fields are described in section 9.6.6 of [USB31].

• A string descriptor contains a single UTF16-LE string and is referenced by index by other descriptors. Its fields are described in section 9.6.9 of [USB31].

The Binary Object Store (BOS) is an additional set of descriptors that are more free-form than the standard device descriptors. Of note is the Platform Descriptor type which allows third parties (such as this specification) to declare their own types of descriptors. Each of these is identified by a UUID. The Binary Object Store is described in section 9.6.2 of [USB31].

A USB device has a single device descriptor which links to one or more configuration descriptors. It’s vendor ID is assigned to the device manufacturer by the USB-IF and is stored in the idVendor field of the device descriptor. It’s product ID is assigned by the manufacturer and is stored in the idProduct field of the device descriptor. It’s serial number is an optional property that is defined if the iSerialNumber field of the device descriptor is not equal to 0 and is the string descriptor referred to by that index.

The Get Configuration is a request to the current device configuration value, described in in section 9.4.2 of [USB31].

The Set Descriptor is a request to get the descriptor with specified Descriptor Type and Descriptor Index, described in in section 9.4.8 of [USB31].

The Get Descriptor is a request to get the descriptor with specified Descriptor Type and Descriptor Index, described in in section 9.4.3 of [USB31].

Note: As descriptors of the device stay the same for the most of the time (with occasional occurrences of Set Descriptor which might modify the descriptors). In order to save the redundant Get Descriptor traffic to the device, implementations could have a read-through & write-through cache layer to store the descriptors of the device.

A control transfer is a special class of USB traffic most commonly used for configuring a device. It consists of three stages: setup, data and status. In the setup stage a setup packet is transmitted to the device containing request parameters including the transfer direction and size of the data to follow. In the data stage that data is either sent to or received from the device. In the status stage successful handling of the request is acknowledged or a failure is signaled.

10. Appendix: A Brief Introduction to USB

This section is non-normative.

USB is a network but it’s very different from traditional TCP/IP networks. It is really more like an RPC system. All traffic is directed by the host, that is, your computer. Though some devices like smartphones can act as both a USB host and USB client they can only take on one role at a time.

10.1. Descriptors

USB devices identify themselves to the host by providing a set of binary structures known as descriptors. The first one read by the host is the device descriptor which contains basic information such as the vendor and product IDs assigned by the USB-IF and the manufacturer. The host may then read the device’s configuration descriptor which is a description of the device’s capabilities including the interfaces and endpoints it exposes. A class can be declared at the device level or for individual interfaces. A device with multiple interfaces providing different functions is known as a composite device.

10.2. Transfers

Whether data is traveling from host to device or the other way around the transfer is always initiated by the host. OUT transfers carry data from host to device and may wait until the device acknowledges the data has been received. IN transfers carry data from device to host and may have to wait until the device has some data to send. Transfers are executed against one of a device’s endpoints and there are different kinds depending on what type of traffic is being sent.

• Bulk transfers are good for sending lots of data with whatever bandwidth is available. This is what is used to read and write data to USB mass storage devices.

• Interrupt transfers offer guaranteed latency (by reserving bandwidth so that they can’t be blocked by a large bulk transfers) but with limited packet sizes. These are used for signaling and for small packets like mouse movements and button presses.

• Isochronous transfers also reserve bandwidth but they don’t guarantee delivery. They’re used for streaming data like audio and video.

• Every device also has a special default endpoint. While regular endpoints only carry data in one direction or the other control transfers have a small header called the SETUP packet that is always sent to the device and contains request parameters in addition to a larger data payload that can be either IN or OUT.