search

WebKit / standards-positions

WebKit's positions on emerging web specifications
https://webkit.org/standards-positions/
242 stars 19 forks source link

WebUSB API #68

Open nondebug opened 2 years ago

nondebug commented 2 years ago

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

Information about the spec

Design reviews and vendor positions

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 commented 2 years ago

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

othermaciej commented 1 year ago

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

othermaciej commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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