Comment by sva_

Native android apps can talk to regular USB devices, if granted the necessary permissions. But it's exposed through a Java api (and Kotlin I suppose, these days), which is fine, but it means you need to write your client logic twice. If you target the web, you can do it once.

(Yes, you could try to bulid some common interface, libusb-style, but I think you'll have a bad time with minor behavioural differences, especially around permissions. libusb itself does ostensibly support Android but there are several caveats: https://github.com/libusb/libusb/wiki/Android#does-libusb-su... )

WebUSB is particularly useful for this, because it allows you to just open a website. You don't need to install an app.

It also convenient for developer, as distributing apps nowadays is a lot of hoops to jump over. Website is just a website.

Also website is cross-platform by definition, as long as API is supported across platforms and WebUSB API is supported on all platforms except iOS.

Cross-platform compatibility comes to mind. WebUSB is available on macOS, Windows, and Android; a native Android app would pose a bootstrapping problem for a probably not insubstantial fraction of all potential users.

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?

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?

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