Merge branch 'main' into unrestricted-usb-spec

.gitignore

@@ -0,0 +1 @@
+index.html

index.bs

@@ -631,6 +631,7 @@ run the following steps <a>in parallel</a>:
      |enumerationResult|.
   2. Let |devices| be a new empty {{Array}}.
   3. For each |device| in |enumerationResult|:
+     1. If |device| is [=blocklisted=], [=iteration/continue=].
      1. If this is the first call to this method, <a>check permissions for
         |device|</a> with |storage|.
      2. Search for an element |allowedDevice| in
@@ -676,6 +677,7 @@ steps <a>in parallel</a>:
   4. Set <code>|status|.{{PermissionStatus/state}}</code> to <code>"ask"</code>.
   5. <a>Enumerate all devices attached to the system</a>. Let this result be
      |enumerationResult|.
+  1. Remove devices from |enumerationResult| if they are [=blocklisted=].
   6. Remove devices from |enumerationResult| if they do not <a>match a device
      filter</a> in <code>|options|.{{USBPermissionDescriptor/filters}}</code>.
   7. Remove devices from |enumerationResult| if they <a>match a device filter</a>
@@ -2307,6 +2309,68 @@ slots</a> described in the following table:
         1. Return <code>wMaxPacketSize</code> of |endpointDescriptor|.
 </dl>
 
+# The USB Blocklist # {#blocklist}
+
+<xmp class="idl">
+  // USBBlocklistEntry is never exposed.
+  dictionary USBBlocklistEntry {
+    required unsigned short idVendor;
+    required unsigned short idProduct;
+    required unsigned short bcdDevice;
+  };
+</xmp>
+
+This specification relies on a <a href="https://raw.githubusercontent.com/WICG/webusb/main/blocklist.txt">blocklist.txt</a>
+file in this repository to restrict the set of devices a website can access.
+
+The result of <dfn>parsing the blocklist</dfn> 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.
+  1. Let |lines| be the result of [=strictly splitting=] |contents| starting
+     from the beginning of |contents| on code point <code>'\n'</code>.
+  1. Let |blocklist| be an empty [=list=].
+  1. [=list/For each=] |line| of |lines|:
+      1. Set |line| to the result of [=collecting a sequence of code points=]
+         not equal to <code>'#'</code> from |line| starting from the beginning
+         of |line|.
+      1. Set |line| to the result of [=stripping leading and trailing ASCII
+         whitespace=] from |line|.
+      1. Let |components| be the result of [=strictly splitting=] |line|
+         starting from the beginning of |line| on code point <code>':'</code>.
+      1. If the [=list/size=] of |components| is not 2 or 3,
+         [=iteration/continue=].
+      1. Let |idVendor| be the result of interpreting |components|[0] as a
+         hexadecimal number.
+      1. Let |idProduct| be the result of interpreting |components|[1] as a
+         hexadecimal number.
+      1. Let |bcdDevice| be <code>0xFFFF</code>.
+      1. If the [=list/size=] of |components| is 3, set |bcdDevice| to the
+         result of interpreting |components|[2] as a hexadecimal number.
+      1. [=list/Append=] a new {{USBBlocklistEntry}} with |idVendor|,
+         |idProduct|, and |bcdDevice| to |blocklist|.
+  1. Return |blocklist|.
+
+The <dfn>USB blocklist</dfn> is the result of [=parsing the blocklist=] at
+<a href="https://raw.githubusercontent.com/WICG/webusb/main/blocklist.txt">https://raw.githubusercontent.com/WICG/webusb/main/blocklist.txt</a>.
+The UA should re-fetch the blocklist periodically, but it’s unspecified how
+often.
+
+A {{USBDevice}} |device| is <dfn>blocklisted</dfn> if the following steps return
+"blocked":
+
+  1. [=list/For each=] |entry| of the [=USB blocklist=]:
+      1. If |device|.{{USBDevice/vendorId}} is not equal to
+         |entry|.{{USBBlocklistEntry/idVendor}}, [=iteration/continue=].
+      1. If |device|.{{USBDevice/productId}} is not equal to
+         |entry|.{{USBBlocklistEntry/idProduct}}, [=iteration/continue=].
+      1. Let |bcdDevice| be |device|.{{USBDevice/deviceVersionMajor}} << 8 +
+         |device|.{{USBDevice/deviceVersionMinor}} << 4 +
+         |device|.{{USBDevice/deviceVersionSubminor}}.
+      1. If |bcdDevice| is less than or equal to
+         |entry|.{{USBBlocklistEntry/bcdDevice}}, return "blocked".
+  1. Return "not blocked".
+
 # Integrations # {#integrations}
 
 <h3 id="permissions-policy" oldids="feature-policy">Permissions Policy</h3>
@@ -2580,4 +2644,5 @@ spec:infra; type:dfn; for:list; text:for each
 spec:infra; type:dfn; for:list; text:append
 spec:infra; type:dfn; for:list; text:empty
 spec:infra; type:dfn; for:list; text:size
+spec:url; type:interface; text:URL
 </pre>

unrestricted-usb-explainer.md

@@ -0,0 +1,89 @@
+# Explainer for Unrestricted WebUSB
+
+A proposal to enable trusted web applications to bypass security restrictions
+in the WebUSB API.
+
+<!-- TOC -->
+<!-- /TOC -->
+
+## Introduction
+The original intent of the WebUSB API was to support writing companion
+applications for devices not otherwise supported by the browser or operating
+system. Many USB devices use standard drivers included with the operating system
+and are accessed by applications and websites through higher-level interfaces.
+The interface classes for which sites should be using a higher-level interface
+are placed on the [protected interface class list](https://wicg.github.io/webusb/#has-a-protected-interface-class)
+and cannot be claimed by a site using WebUSB. Similarly, the [device blocklist](https://github.com/WICG/webusb/blob/main/blocklist.txt)
+lists a number of security devices which are not accessible to sites using
+WebUSB.
+
+These security restrictions make WebUSB unsuitable for the USB redirection
+features common in Virtual Desktop Infrastructure (VDI) and remote desktop
+applications, where local peripherals need to be controlled by drivers and
+applications running on a remote system. While high-level redirection is
+sometimes possible these systems typically require low-level USB access in
+order to provide the best compatibility.
+
+## Proposed specification changes
+The WebUSB API already requires an application to request permission from the
+user for each device it wants to access. Access to the WebUSB feature is also
+controlled by Permissions Policy using the feature `"usb"`.
+
+This proposal introduces a new Permissions Policy feature `"usb-unrestricted"`.
+An application with the `"usb-unrestricted"` feature is allowed to access
+protected USB interfaces and blocklisted USB devices.
+
+The `"usb-unrestricted"` feature exposes device capabilities deemed too
+dangerous to be accessed by an untrusted application. Untrusted applications
+will not be able to request `"usb-unrestricted"`. Under this proposal,
+`"usb-unrestricted"` can only be used with [Isolated Web Apps](https://github.com/WICG/isolated-web-apps/blob/main/README.md)
+by including the feature in the `"permissions_policy"` manifest field.
+
+```
+"permissions_policy": {
+   "usb": [ "self" ],
+   "usb-unrestricted": [ "self" ]
+}
+```
+
+## Security considerations
+USB device access can be abused to attack the device or the host, as described
+in the [Security and Privacy Considerations](https://wicg.github.io/webusb/#security-and-privacy)
+section of the WebUSB spec. The threat model is unchanged, except that a
+malicious application with `"usb-unrestricted"` can access more devices than
+would normally be accessible through WebUSB. This could include input devices
+like keyboards and second factor authentication keys, recording devices like
+cameras and microphones, mass storage devices containing the user's private
+data, and other vulnerable devices.
+
+The authors of the WebUSB specification believe it is not possible to expose
+unrestricted USB access to arbitrary web pages in a way that protects the user
+and also enables USB redirection. The Isolated Web Apps proposal provides an
+alternate path for applications that require powerful capabilities considered
+too dangerous for the web.
+
+Isolated Web Apps include the [maximal set of permissions they could request](https://github.com/WICG/isolated-web-apps/blob/main/Permissions.md)
+as a field in the application manifest. This enables administrators to audit
+an application's permission usage and verify that it is not abusing powerful
+capabilities.
+
+## Privacy considerations
+Unrestricted USB access can be used to access private information that is
+normally managed by the operating system or browser. For example, the operating
+system uses file permissions to ensure that sensitive data cannot be accessed by
+unprivileged applications. Unrestricted low-level access to USB mass storage
+devices would enable script to bypass any permissions model and access private
+data.
+
+Device identifiers like product names and serial numbers are permanent
+identifiers that can be used to fingerprint the user. To mitigate fingerprinting
+risk, WebUSB by default exposes no information about devices. A site can read
+the identifiers for a device only after the user has granted permission for the
+site to access the device.
+
+Exposing additional interface classes is unlikely to significantly increase the
+fingerprinting surface since the identifiers exposed by these classes are not
+any more useful for fingerprinting than identifiers from devices with
+unprotected USB interface classes. Additionally, these identifiers will only be
+accessible from inside trusted applications and cannot be used to track the user
+on untrusted sites.