
Connecting to uncommon HID devices - feross
https://web.dev/hid/
======
userbinator
_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.

~~~
Dylan16807
Authentication devices have to go through the authentication device API, which
has logic to keep them from being abused.

------
nynx
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.

~~~
nippoo
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.

~~~
ianlevesque
Sounds like Java applets to me.

~~~
lmm
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.

------
hakfoo
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.

------
andrethegiant
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?

[1]
[https://teenage.engineering/products/op-1](https://teenage.engineering/products/op-1)

------
fmakunbound
This is just a Chrome specific thing, right?

------
pitterpatter
I really dislike how web.dev somewhat implies _Chrome is the web_. Maybe true
at this point, but still sad.

------
snarfy
I recall one of the CD 'rootkits' that went around years ago installed itself
in the kernel as a HID device.

WebHID seems like a bad idea.

~~~
LammyL
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.

~~~
snarfy
Yes, but talking to this specific HID device could allow you to compromise the
system.

