alt Hacker NewsHonestly, an extension seems like the perfect solution for this. Wanting a website to access your USB stack directly (or Bluetooth, which has a similar standard) is such an extremely niche use case that it’s probably better for it to be available only as an opt-in extension. They can still standardize it, but… let me just not have it by default please.
On iOS, there’s a “Bluetooth browser” app which is basically a simple WebView-based browser, but with the Bluetooth JS spec implemented so that you can use it to configure whatever Bluetooth device you have that wants to use a webapp for configuration. And you know what? That’s fine. It’s perfect, actually. A separate app I can use for the 0.0001% of the time I actually need to interact with some random IoT device’s Bluetooth configuration UI, and my normal web browser doesn’t need the bloat and increased attack surface. It just seems like good engineering to me to do it this way.
More of the enormous bloated JS web API specs should be implemented as browser plugins. Let’s make the default footprint even smaller.
> Wanting a website to access your USB stack directly (or Bluetooth, which has a similar standard) is such an extremely niche use case that it’s probably better for it to be available only as an opt-in extension.
It doesn't give direct access. You go through the browser which restricts what you can use it to touch (eg. can't access USB drives). The user also needs to choose which USB device to allow access to before you can do anything.
> More of the enormous bloated JS web API specs should be implemented as browser plugins.
Then you'll get one of two outcomes: 1. Users install extensions without caring about what they do. I don't see why we should train people to install more extensions when there are already a lot of malicious extensions! 2. Hardware manufacturers decide to not adopt these standards and continue shipping executables for everything, which are not sandboxed at all and don't support all platforms