WebUSB | WebUSB enabled LOL shield | Runtime Evironment library

I believe this is a duplicate of that issue and automatically detaching drivers on Android (tracked by Chromium issue 1099521) will resolve the problem.

Web NFC is supported on Android only as of February 2021. See https://web.dev/nfc/

The WebUSB error suggests you're requesting an interface that implements a protected class (among those below):

There are a couple of layers you'll need to understand in order to accomplish your goal. The first is the USB interface implemented by the device.

In the example code you've posted there are two calls which send commands to the device. The first is a controlTransferOut() which sends the standard USB CDC-ACM SET_CONTROL_LINE_STATE request (0x22) to the device to enable the DTR signal (0x01). If your device implements the USB CDC-ACM protocol then this is the write thing to do as it signals to the device that the host software is ready to receive data. If your device doesn't implement this protocol then the command will be ignored or fail. You're already claiming the first interface, to understand USB protocol that interface implements you should check device.configuration.interfaces[0].alternates[0].interfaceClass and device.configuration.interfaces[1].alternates[0].interfaceClass. A USB CDC-ACM device will have one interface with class 2 and one with class 10. Class 2 is for the control interface while class 10 is the data interface. If your device doesn't have these two interfaces then it probably isn't implementing the USB CDC-ACM protocol and you'll have to figure out what protocol it uses first.

The second call you make is a controlTransferIn() which sends the standard USB GET_DESCRIPTOR request (0x06) to read a string descriptor from the device. Passing 0x0302 asks it to read the string descriptor (type 3) at index 2. This will work for any USB device (assuming the index is right) and so doesn't tell you whether you've figured out what protocol the interface supports.

Assuming this is a USB CDC-ACM interface then you'll want to look at device.configuration.interfaces[1].alternates[0].endpoints and figure out the endpoint numbers for the IN and OUT endpoints. These are what you'll pass to transferIn() and transferOut() to send and receive data from the device.

Once you have all that figured out you'll need to figure out how to get the device to start sending NMEA messages. If you are lucky then in its default mode it will automatically send them and you can just start calling transferIn() to receive them. Otherwise you will have to figure out what command to send to the device to put it in a the right mode. If you have and documentation for the device or example code written in other languages that supports this device then that will be very helpful for figuring this out.

This behavior shouldn't happen (especially the freezing and crashing part) and is likely a Chromium or Android bug. Please open an issue on crbug.com and include any crash IDs from chrome://crashes in the report. Reply here with the bug link so I'm sure to see it.

1. Does permissions api support "usb" feature? If yes, what I do wrong in upper code?

No. While the Permissions API integration defined in the specification is implemented in Chromium-based browsers it is not exposed through the Permissions API's query() method. This is tracked by issue 638721 but has not been a priority given the available alternatives.

1. If permissions api not yet support "usb" feature, where/how allowed devices are stored in browser? Can I programmatically get access to this storage?

Permissions are stored in the browser's user preferences file and internal data structures which are not directly accessible to Javascript. The only way these permissions are currently exposed are through the settings UI (chrome://settings/content/usbDevices) and the navigator.usb.getDevices() method, which only returns allowed devices if they are currently connected.

1. Can website request user to allow permissions to group of devices (in my case by vid+pid) which not only connected right now, but also can be connected in future? In other words, I want to ask user "Please, let me work with usb devices (with this vid+pid) which you connect in a future, because I don't want to bore you with permission question every time you connect new device of particular type".

No. It is important to the security design of the API that the user make the decision based on the devices currently connected rather than a hypothetical future device.

For enterprise managed devices the WebUsbAllowDevicesForUrls policy allows an administrator to make this type of decision on behalf of their users.

The webadb.js library provides an implementation of the ADB protocol in Javascript using WebUSB to communicate with a local device. This assumes that the device is local to the computer running the web browser.

If you want to control the device from the server you will need to provide a way for the server to command the browser to forward commands to the device. This could be done, for example, using a Web Socket.

If you want to use the browser to control a device connected to the server however a different approach is needed. In that case you would use a library like adbkit to connect to the device directly from Node.

This isn't a flaw in WebUSB but with the script you are running. The serial.js script included in the Arduino examples repository is designed to work with Arduino devices where setting the baud rate in unnecessary because the port is virtual. In order to set the baud rate on a USB to serial adapter you need to send the SET_LINE_CODING control transfer. This should go before the SET_CONTROL_LINE_STATE command in your existing code. There is documentation for the structure of the control transfer here:

https://github.com/MarkDing/lufa-efm32#311-set-line-coding

Because USB–and even more so WebUSB–seems to be more fragile than the http connections I'm used, parallel to playing with the Javascript interface, I also worked at pulling in the data with PyUSB. The goal is to write data from the device to a CSV file so either could work.

In this related post I outline some additional steps in the process including:

• rebooting the machine
• with the device connected
• a good USB cable
• checking chrome://device-log at DEBUG level
• using a demo of the Serial App
• checking status with kexstat, "unclaiming" with kextunload
• looking at kernel log with dmesg

I would love to accept a more robust "answer" than this, but I am finally seeing some data:

WebUSB is designed to provide low-level access to USB devices, at the level of individual USB transfers. If the device has an existing driver then that should be taking care of the transfers and presenting a higher-level interface to applications on your system. Trying to wrap that in something which presented the low-level interface again would be counterproductive.

Without more information about the device in question and its driver I can't give more precise advice.

One option, which would be a lot of work but could be more broadly applicable would be writing a wrapper around the existing driver that would allow it to use WebUSB to connect to the device. There has been work, for example, it port user-space drivers using libusb to the web by providing a port of libusb that uses WebUSB internally. This works much more easily for open-source drivers because you can recompile them to use the wrapper. If this is a closed-source native Windows driver, for example, running that inside of an emulator on the web would be an enormous undertaking.