5 ms·

Reading the justification for WebHID I get the feeling I’m missing something: > There is a long tail of human interface devices (HIDs) that are too new, too ol

by Aaargh20318 6y ago

Reading the justification for WebHID I get the feeling I’m missing something: > There is a long tail of human interface devices (HIDs) that are too new, too old, or too uncommon to be accessible by systems' device drivers. The WebHID API solves this by providing a way to implement device-specific logic in JavaScript. > (...) > The inability to access uncommon or unusual HID devices is particularly painful, for example, when it comes to gamepad support. Gamepad inputs and outputs are not well standardized and web browsers often require custom logic for specific devices. This is unsustainable and results in poor support for the long tail of older and uncommon devices. So instead of only having to implement support for these devices once (in the browser), they now expect every website that would need support for these kind of devices to write their own code to handle all these ‘long tail’ input devices ? How does that not make the problem infinitely worse ? Instead of convincing one party to implement and support the code to handle your obscure HID, now you beee to convince potentially millions of websites. All running different implementations with their own unique bugs and issues. This sounds less like an effort from the Chrome team to add support for these devices and more like a way to make it someone else’s problem.

foota 6y ago
It's not like every device will or could be supported reasonably by a browser. This allows support to be done by those who care about it.
- Forge36 6y ago
  Distributing print drivers via the internet? Allowing the ultimate hardware hacking via the largest PC sandbox environment? Should have interesting security implementations for hardware fingerprinting.
Drakim 6y ago
More power to the developers. In the past you had to cross your fingers that the browser vendor would have implemented the gamepad the user wanted to use, and it not, you'd be out of luck. The issue of "every site needing to reimplement every gamepad" can be fixed by developers making libraries with those implementations.
- kreeben 6y ago
  >> More power to the developers Are you suggesting developers will gain power by buying in to these APIs? If you are, then let me remind you of a slippery slope known as "lock in". Never, is when a developer is empowered by lock in.
  - deleted 6y ago
    [deleted]
- trissylegs 6y ago
  I suppose someonte could create a HID service. That lets Games download WASM drivers for any device on demand, and new devices could be added without any change to the application. Kinda like how webfonts mean a site no longer needs to rely on fonts being installed on the browser, and Google fonts means CMS providers don't need to provide every webfont. (If the platform allows Google Font's or similar).
taf2 6y ago
It’s actually infinitely more scalable because now the device manufacturers or any developer can create a library to support any device. Before we relied on a single browser vendor or vendors to write the drivers... while google has an impressive engineering team as do all the browser vendors .. it’s not really reasonable or even as fun to have to only rely on them... imagine an IOT project adding support for HID device to control a robot or console style game... lot of neat possibilities
- Aaargh20318 6y ago
  > It’s actually infinitely more scalable because now the device manufacturers or any developer can create a library to support any device. Sure, but that means you as a device manufacturer have to convince all these websites to include your library and support your device. Why not have e.g. generic gamepad support in Chrome and let developers write a driver for their devices as an extension ? Now all you get is horrible fragmentation, your device may work on website A but not on website B, and maybe kinda work but very buggy on website C. It’s a recipe for a shitty user experience. In practice you’ll see that only a handful of popular devices will be universally supported.
  - jefftk 6y ago
    > Why not have e.g. generic gamepad support in Chrome All the browsers have generic gamepad support at this point: https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API Unfortunately, it is a bit lowest common denominator. WebHID is good for long tail devices, or handling more unusual features of specific devices: https://web.dev/hid-examples/ https://web.dev/hid-examples/
    - Aaargh20318 6y ago
      > WebHID is good for long tail devices, or handling more unusual features of specific device And that’s exactly why it will never be widely used. I’m not saying that there isn’t a use-case for it, I’m saying that the article overstates the usefulness of this API.
masswerk 6y ago
What isn't obvious to me: how is this safeguarded? Is there any provision to stop a malicious driver from generating fake input, which is then tainted as user generated input all the same?
- wtallis 6y ago
  > Is there any provision to stop a malicious driver from generating fake input, I have the opposite concern: is it guaranteed that accessibility software will be able to spoof the kinds of inputs a site expects? And will my browser be able to generate dummy input data of the format a site demands, for the occasions that I don't want the site to have live access to that particular sensor/input?
  - masswerk 6y ago
    On the one hand, it should be great for accessibility, testing (or even, handling cookie confirmation dialogs), but, on the other hand, it shouldn't be too difficult to, say, discern a certain button for enabling media sharing and handle any associated dialogs.

foota 6y ago

It's not like every device will or could be supported reasonably by a browser. This allows support to be done by those who care about it.

Forge36 6y ago
Distributing print drivers via the internet? Allowing the ultimate hardware hacking via the largest PC sandbox environment? Should have interesting security implementations for hardware fingerprinting.

Drakim 6y ago

More power to the developers. In the past you had to cross your fingers that the browser vendor would have implemented the gamepad the user wanted to use, and it not, you'd be out of luck. The issue of "every site needing to reimplement every gamepad" can be fixed by developers making libraries with those implementations.

kreeben 6y ago
>> More power to the developers Are you suggesting developers will gain power by buying in to these APIs? If you are, then let me remind you of a slippery slope known as "lock in". Never, is when a developer is empowered by lock in.
- deleted 6y ago
  [deleted]
trissylegs 6y ago
I suppose someonte could create a HID service. That lets Games download WASM drivers for any device on demand, and new devices could be added without any change to the application. Kinda like how webfonts mean a site no longer needs to rely on fonts being installed on the browser, and Google fonts means CMS providers don't need to provide every webfont. (If the platform allows Google Font's or similar).

taf2 6y ago

It’s actually infinitely more scalable because now the device manufacturers or any developer can create a library to support any device. Before we relied on a single browser vendor or vendors to write the drivers... while google has an impressive engineering team as do all the browser vendors .. it’s not really reasonable or even as fun to have to only rely on them... imagine an IOT project adding support for HID device to control a robot or console style game... lot of neat possibilities

Aaargh20318 6y ago
> It’s actually infinitely more scalable because now the device manufacturers or any developer can create a library to support any device. Sure, but that means you as a device manufacturer have to convince all these websites to include your library and support your device. Why not have e.g. generic gamepad support in Chrome and let developers write a driver for their devices as an extension ? Now all you get is horrible fragmentation, your device may work on website A but not on website B, and maybe kinda work but very buggy on website C. It’s a recipe for a shitty user experience. In practice you’ll see that only a handful of popular devices will be universally supported.
- jefftk 6y ago
  > Why not have e.g. generic gamepad support in Chrome All the browsers have generic gamepad support at this point: https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API Unfortunately, it is a bit lowest common denominator. WebHID is good for long tail devices, or handling more unusual features of specific devices: https://web.dev/hid-examples/ https://web.dev/hid-examples/
  - Aaargh20318 6y ago
    > WebHID is good for long tail devices, or handling more unusual features of specific device And that’s exactly why it will never be widely used. I’m not saying that there isn’t a use-case for it, I’m saying that the article overstates the usefulness of this API.

masswerk 6y ago

What isn't obvious to me: how is this safeguarded? Is there any provision to stop a malicious driver from generating fake input, which is then tainted as user generated input all the same?

wtallis 6y ago
> Is there any provision to stop a malicious driver from generating fake input, I have the opposite concern: is it guaranteed that accessibility software will be able to spoof the kinds of inputs a site expects? And will my browser be able to generate dummy input data of the format a site demands, for the occasions that I don't want the site to have live access to that particular sensor/input?
- masswerk 6y ago
  On the one hand, it should be great for accessibility, testing (or even, handling cookie confirmation dialogs), but, on the other hand, it shouldn't be too difficult to, say, discern a certain button for enabling media sharing and handle any associated dialogs.