← Back to context

Comment by lxgr

1 day ago

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.

  • There isn't much to fear here. Web Bluetooth has been around nearly ten years now and nothing monumental has sprung forth from it. It is wonderfully convenient to have at your fingertips, especially in the ChromeOS world, but it's not gonna turn everyone's devices into Flipper Zero targets.

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

      12 replies →

    • Sure, but some people are concerned about any website being one confirmation prompt away from being able to have full access to hardware in the user's physical environment, and being able to permanently change the behavior of that hardware.

      A hacker may think such things are convenient for them, but an end user does not know the ramification of a random website (WebUSB IIRC still does not have origin restrictions) getting hardware access - nor can we categorize the risk in order to protect them.

      4 replies →

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

      2 replies →

  • “ 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”

    As opposed to dodgy windows-only installable software from some weird site to flash devices instead? I’ll take my chances with webusb, thanks.

  • You can press a simple button on a webpage and it will install malware on your iPhone. Plenty of exploits have been out there for a long time.

    Should we disallow clicking on anything on a webpage too?

    WebUSB is no more risky than any other tech. You have to explicitly opt-in to use WebUSB on any site requesting access to it. And I'm sorry if someone's grandfather trusts a malicious website and gets hacked, but that isn't a reason to prevent the rest of us from using tech that enables functionality on non-malicious websites that serves a useful purpose.