Contact emails
Summary
The following set of USB interface classes, which should not be claimed using the WebUSB API, will be explicitly blocked by Blink: Audio, Video, HID, Mass Storage, Smart Card, Wireless Controller (Bluetooth and Wireless USB). These interface classes are already mostly blocked by an operating system’s built-in class drivers. This change establishes consistency across platforms.
Motivation
The WebUSB API is designed to provide a mechanism for device manufacturers and developers to build applications supporting novel hardware on the web instead of through native apps. As explained in the original Intent to Ship for WebUSB, most USB devices fall into one of a number of standardized device classes for which there are already high-level APIs provided by the Web Platform. For each of these interface classes the high-level API is the supported path and WebUSB is the unsupported path.
Risks
Interoperability and Compatibility
Developers may have implemented workarounds at an operating system level to allow devices of these classes to be claimed by web content using WebUSB. For example, on Windows, a specially crafted INF file can override the system default driver for a particular device with the WinUSB driver. Or, on Linux, udev rules can be configured so that the Linux kernel does not bind a driver to the device. After this change such workarounds will not be possible.
Web developers who have deployed any of the workarounds above will likely be negative on this change however the overall benefit to developers of continuing to provide this API for the scenarios in which it is fully supported outweighs this loss of functionality.
Ergonomics
Not applicable.
Activation
Not applicable.
Debuggability
To avoid developer confusion, a specific SecurityError message will be used when the claimInterface() method fails due to this filtering and a message will be logged to the console.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
All platforms other than Android WebView, which currently does not support WebUSB.
Is this feature fully tested by web-platform-tests?
This feature is currently tested by LayoutTests while it is decided to what extent the list of blocked interface classes should be part of the specification or Chrome-specific policy. Moving these tests into web-platform-tests is a trivial change once this question is resolved.
Link to entry on the feature dashboard
This is a small change that fits under the existing entry in the feature dashboard for WebUSB.
https://www.chromestatus.com/feature/5651917954875392
Requesting approval to ship?
Yes.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMZoYWMqMPsqqEHYqXtRjSY-ngKBpJyxFrupSvhBvVTkjg%40mail.gmail.com.
On Tue, Mar 20, 2018 at 9:01 PM Reilly Grant <rei...@chromium.org> wrote:
Contact emails
Summary
The following set of USB interface classes, which should not be claimed using the WebUSB API, will be explicitly blocked by Blink: Audio, Video, HID, Mass Storage, Smart Card, Wireless Controller (Bluetooth and Wireless USB). These interface classes are already mostly blocked by an operating system’s built-in class drivers. This change establishes consistency across platforms.
Motivation
The WebUSB API is designed to provide a mechanism for device manufacturers and developers to build applications supporting novel hardware on the web instead of through native apps. As explained in the original Intent to Ship for WebUSB, most USB devices fall into one of a number of standardized device classes for which there are already high-level APIs provided by the Web Platform. For each of these interface classes the high-level API is the supported path and WebUSB is the unsupported path.
Risks
Interoperability and Compatibility
Developers may have implemented workarounds at an operating system level to allow devices of these classes to be claimed by web content using WebUSB. For example, on Windows, a specially crafted INF file can override the system default driver for a particular device with the WinUSB driver. Or, on Linux, udev rules can be configured so that the Linux kernel does not bind a driver to the device. After this change such workarounds will not be possible.
Web developers who have deployed any of the workarounds above will likely be negative on this change however the overall benefit to developers of continuing to provide this API for the scenarios in which it is fully supported outweighs this loss of functionality.
IIUC, these workarounds require *users* to change their OS (either willingly or through social engineering). Is that correct?
Actually, I do think this a too strict.In my case I use an Arduino, which reports itself as a HID, since I want it to enter some Keys. Wich keys to enter is defined using a WebApp. As you can see I won't be able to make any settings, unless I find a way to switch of the HID functionality at runtime.
My suggestion is to block devices that ONLY implement the named classes. In other words: As soon as a device has a class that is not in the list, I should be able to claim it.
Not sure if you're still looking for feedback, but I've been experimenting with a video editing USB device which is now blocked. Use cases are numerous, but right now I'm working on cloud software that would greatly benefit from this integration. Would it be unreasonable to appeal specific vendor ids or loosen for non-keyboard HIDs?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb0afa13-75c8-47d8-b9fd-76172ccf1f7b%40chromium.org.
The device is a X-keys XK-12 Jog & Shuttle (http://xkeys.com/xkeys/xk12JSH.php). Although this company has many hacker-friendly input devices that could be whitelisted. The vendor id I use is 0x05F3.Here is the C driver: https://github.com/piengineering/xkeys/blob/master/piehid/hid-libusb.cMy use case is for pairing with Media Source Extensions to provide a video editor-like experience in a web application.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3e25eb63-f1dc-42ce-87d5-203397e25fca%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAzSBsOfnVJW0p2uA6QwXRQtdNYHvKJ%2BB%3Db9v0Ee6nWrSqyCg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMaTRhR3EK%2BbpMRZ7V6TAc7rQo08sNzsrMEbtk0cmhk7Rw%40mail.gmail.com.
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in HelsinkiThis e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Motivation
The WebUSB API is designed to provide a mechanism for device manufacturers and developers to build applications supporting novel hardware on the web instead of through native apps. As explained in the original Intent to Ship for WebUSB, most USB devices fall into one of a number of standardized device classes for which there are already high-level APIs provided by the Web Platform. For each of these interface classes the high-level API is the supported path and WebUSB is the unsupported path.
Hi,I was wondering, what way is there today to create a web-app (non-native android application) where I'd be able to plug-in a USB camera into an android device and be able to use it as an external camera of sorts. MediaDevices.getUserMedia() does not seem to work on a mobile android device + chrome. It does work on chrome on a pc. My camera is detected and I can select it as camera in a browser, but not on mobile. USB is blocked as device is a video device.
> External cameras should be available through getUserMedia() on Android.
Unfortunately, `getUserMedia()` doesn't work on Android. It's broken and crashes on Android 10+. See https://crbug.com/487935 for more info.