WebUSB API

[nondebug]

(Re-)request for position on an emerging web specification

• WebKittens who can provide input: [email protected]

Information about the spec

• Spec Title: WebUSB API
• Spec URL: https://wicg.github.io/webusb/
• GitHub repository: https://github.com/WICG/webusb

Design reviews and vendor positions

• TAG Design Review: WebUSB w3ctag/design-reviews#108
• Mozilla standards-positions issue: RFP: WebUSB API mozilla/standards-positions#100

Anything else we need to know

WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting:

https://webkit.org/tracking-prevention/

I'm re-requesting WebKit's position on this emerging web specification because of changes we are making to the Chromium implementation related to deprecation of extension background pages in manifest V3. We plan to expose WebUSB to extension service workers as a migration path for extensions that currently access the API from the extension background page.

Chrome Platform Status: https://chromestatus.com/feature/5200265459269632
Explainer: https://github.com/nondebug/webusb/blob/service-worker-explainer/extension-service-worker-explainer.md

Even though Apple is not considering implementing this API, we are still interested in any feedback WebKit can provide on WebUSB and our proposal to integrate with Service Workers.

[marcoscaceres]

Thanks @nondebug! We will take a look and get back to you as soon as we can.

[othermaciej]

It takes some indirection to tell from the Mozilla standards position issue, but Mozilla has judged this API "harmful", primarily for security reasons.

[othermaciej]

We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label. This spec also depends on a specific hardware technology, and enables dependency on specific attached hardware accessories, which risks the device independence of the web; thus concerns: device-independence.

[reillyeon]

Two questions for the WebKit team on whether there are changes that could be made to this API that would affect your position:

1. The work that @nondebug is currently doing refers specifically to the use of WebUSB in browser extensions, not the "drive by" web. Given that developing an extension typically involves submitting it for review by a browser vendor I am curious if WebKit would consider this to mitigate some of the security and privacy concerns?

2. The device independence concern is interesting because in my mind the purpose of this API is to enable innovative new hardware, which implies that by design applications will be built for particular devices. Eventually such devices could become common but everything is cutting-edge at some point. Disregarding the specific technologies for the moment, what is WebKit's position on providing communication between a site and a local peripheral?

[othermaciej]

Maybe we need separate issues for WebUSB for the web vs WebUSB for extensions. It is indeed possible we might endorse this standards proposal in extensions even if not on websites. I took this issue to be about WebUSB in general, and it’s fair that we should get our position on the record on that.

[nondebug]

Thanks, I've filed a separate issue for the extension behavior.