Web USB and Web Bluetooth are amazing. I've used the former for the excellent Web MiniDisc [1], and the latter to flash custom firmware [2] on cheap Xiaomi Bluetooth LE thermometer/hygrometer devices that Home Assistant can pick up.
Truly opening new possibilities, since I wouldn't have been comfortable running some sketchy script or local binary.
[1] https://web.minidisc.wiki/ [2] https://github.com/pvvx/ATC_MiThermometer
> Web USB and Web Bluetooth are amazing.
Comments like this scare me. Things look amazing when people with benevolent intentions are making interesting things, but as soon as someone with malevolent intentions does something that becomes the reason we can't have nice things people will start asking if this is something we should have actually done.
I just have no faith in humanity, and do not understand why we think this is a good idea to give a browser this much access to local system resources.
> Comments like this scare me.
Sorry to hear that. I thought this was a safe space for hackers to express enthusiasm about pushing their own hardware and software further (and in this case even in a comparatively safe way).
> I just have no faith in humanity, and do not understand why we think this is a good idea to give a browser this much access to local system resources.
The browser already has all that access, it's just further granting it to web apps, and on a page-by-page, device-by-device, explicitly user opt-in basis at that.
And as I've mentioned, the alternative here is to install a potentially untrusted native application that gets the same access and so much more.
If that's what the Github page tells users to do, many of them will just do it without thinking twice. Is that better?
> I thought this was a safe space for hackers to express enthusiasm about pushing their own hardware and software further (and in this case even in a comparatively safe way).
Nothing is preventing said experimentation nor discussion of it. I am merely offering my more conservative views of the situation as a contrast to the echo chamber gungho nature of the experimentation. Just because we can doesn't mean we should is often left out of the conversation. At some point, the net negative that comes from the use of something "cool" is never contemplated by those creating the something "cool" simply because they would never fathom using the "cool" for "uncool" purposes. Sadly, someone else will and weaponize it in an uncontrollable manner. If the creators can't think of how it can happen, it is vital that those not so involved in the creation speak up when there are potential issues.
What if we implement them but hide them deep in the settings or as experimental feature inside the hidden developer menu, behind multiple warning messages and password prompts? Only the very determined developers and advanced users would be able to unlock them. Then it's safe enough?
Users will unfortunately click on absolutely anything that a trusted (deservedly or otherwise) source tells them to, and you won’t be able to reliable convince them otherwise with UX alone. This includes all “developers only”, “click 5 times” etc. UX interventions.
You have to decide whether the feature warrants the remaining risk after all mitigations, or at least exceeds other, simpler attack vectors.
I think in this case it does, but it’s not an easy decision and I can understand most opposing positions as well.