I'm a big fan of the goal of making web apps as featureful and as powerful as native apps. Eventually, when we get wasm interface types, I'd like to see these apis available directly in wasm or at least, through a wasi module.
I'm still not entirely sold on websites having access to APIs like this. It's bad enough they get to run arbitrary code already, why widen the attack surface?
If they all had a user-settable option for everything, and it was all default-deny, I might be okay with it. I can see the use case, but there is no fuckin' way Doubleclick should ever get to talk to my hardware, ever in a million years.
I'm a fan of the concept of a Web-distributed, powerful cross-platform, interpreted, sandboxed app with no App Store, etc. I'm not sure the existing, backwards-compatible, slightly kludged HTML5 / CSS / JS infrastructure is necessarily the way to go, though. I'd love to see a ground-up language/framework specifically written with the aim of developing and deploying cross-platform "web"-apps with powerful authentication, offline caching support etc.
A Java Web Start application using JavaFX for UI is actually a really nice environment for application development.
Sadly every runtime (including native executables) that isn't the web browser is treated as a security risk, while web "pages" running arbitrary code with any level of local hardware access are seen as safe, so I think we're stuck with the web stack for the long haul.
Note that security-sensitive HID devices (such as FIDO HID devices used for stronger authentication) are also blocked in Chrome. See the blocklist file.
Why not a whitelist? And, while I'm definitely not one to side with the Google/Chrome crowd on allowing sites more access to anything, one could argue that allowing an authentication device to communicate with a webapp is useful...
Of course, the biggest concern is not the mere existing of this feature, but how much users will be able to control it --- which, given the seemingly authoritarian stance that companies like Google have ("we know what's best for everyone"), I'm not too hopeful for.
This doesn’t install hid drivers. This lets you open a connection to a USB device from the browser so that you can talk to it. It’s great because we will finally be able to build web apps that talk natively to USBHID devices like barcode readers and signature tablets. I’m sure chrome is going to have some “authorize this site to connect to USB devices” prompt for security.
The device in the hero image is an OP-1, a portable synthesizer made by Teenage Engineering[1]. It's a MIDI-capable device, so I'd imagine you'd want to interface with it over WebMIDI rather than WebHID?
I wonder how much trampling there is in the USB ID space.
I can see at least three collision sources:
1. A lot of hobbyist HID projects exist, which invites use of the firmware default IDs, even if the devices differ quite a bit from the original model.
2. Bargain-basement manufacturers probably don't register for unique IDs for every single product.
3. The legitimate case of multiple equivalent devices on a single machine. I could see using, say, multiple programmable keyboards but wanting to address each one individually.
15 comments
[ 94.8 ms ] story [ 405 ms ] threadSadly every runtime (including native executables) that isn't the web browser is treated as a security risk, while web "pages" running arbitrary code with any level of local hardware access are seen as safe, so I think we're stuck with the web stack for the long haul.
Why not a whitelist? And, while I'm definitely not one to side with the Google/Chrome crowd on allowing sites more access to anything, one could argue that allowing an authentication device to communicate with a webapp is useful...
Of course, the biggest concern is not the mere existing of this feature, but how much users will be able to control it --- which, given the seemingly authoritarian stance that companies like Google have ("we know what's best for everyone"), I'm not too hopeful for.
WebHID seems like a bad idea.
[1] https://teenage.engineering/products/op-1
I can see at least three collision sources: 1. A lot of hobbyist HID projects exist, which invites use of the firmware default IDs, even if the devices differ quite a bit from the original model. 2. Bargain-basement manufacturers probably don't register for unique IDs for every single product. 3. The legitimate case of multiple equivalent devices on a single machine. I could see using, say, multiple programmable keyboards but wanting to address each one individually.