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.
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?
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.
If native platforms removed USB or Bluetooth, the "control over my own hardware" crowd would flip a table. I just wish they also understood the benefits of the web compared to native. The Chrome/Project Fugu team's dream of making the web platform as powerful as native platforms is the correct one from a user freedom standpoint, or at bare minimum a "user choice" standpoint.
Yes, bad actors exist, but why concede every single nice thing to them?
Nobody is vetting websites for you. There is no guarantee the same company operates a website today that did yesterday. There is no obvious distribution or regulatory authority instituting penalties for illegal actions (and often is no legal presence in a country when illegal actions take place).
That means for the web, every consent prompt has a large, sometimes even unbounded amount of harm behind it if the user picks incorrectly, and browsers have limited capacity to help them pick correctly outside of reactive block lists once substantial harm has been done and recognized.
This is why, for example, the major browsers have all moved to restricting web extensions behind their own review processes/stores, and put restrictions that make unaudited web extensions difficult to install outside of development workflows. The risk is just too great.
Chrome pushed many of these API early in the Chromebook product cycle, because their idea was that you would only build apps using web technologies. I somewhat doubt they would have pushed for WebUSB themselves if Chromebook started in its current state, where it primarily runs android apps and is about to transition to be android-based.
Yes, and as a result, the web is much more sandboxed than native app stores (which are mostly based on the illusion that vetting apps can somehow achieve better security than minimizing what resources apps can access in the first place and making access more fine grained).
This is exactly why I'd rather run e.g. shady USB aftermarket firmware flashing apps in my browser (where I know they can at most compromise the device I'm flashing) than as a native app (where USB access is the default and requires zero permissions to be approved).
> This is why, for example, the major browsers have all moved to restricting web extensions behind their own review processes/stores, and put restrictions that make unaudited web extensions difficult to install outside of development workflows. The risk is just too great.
Web extensions very often have access to your complete browsing data, including all cookies. That's orders of magnitude more risky than access to an explicitly selected USB device, in my view.
> I somewhat doubt they would have pushed for WebUSB themselves if Chromebook started in its current state, where it primarily runs android apps and is about to transition to be android-based.
Android has an USB API as well, and if Google only wanted "apps" to have USB access, nothing was stopping them from making Web USB "Chrome App Store" only.
Please add “mobile and/or proprietary” before “native apps”. Linux and BSD on PC are still very much free. The web as a platform is just a NIH effort.
I can definitely imagine a ton of things going wrong with Web USB, and I think the spec authors did a pretty good job at bolting everything down that can be, while still shipping something actually capable at providing USB access.
And that's my point: Sure, fewer capabilities are always safer than more capabilities. But some capabilities are nice and arguably worth the risk, especially if the obvious alternative (blindly installing native applications) isn't much safer.
Except it isn't "uncontrollable". You have to explicitly allow every single website to use WebUSB. Without that explicit allowance, the website can't access anything.
Plenty of things can be weaponized, even household utensils. Should we ban all forks?
The sky is not falling, and WebUSB is not going to cause it to fall.
You could always write a native app. It's always been possible that way.
have you used the thing in the wild?
Much like the Location API, it’s explicitly opt-in, and isolated.
How is it going to be weaponized?
That’s what to talk about here. I’d love to take part.
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.
I've heard about rogue keyboard firmware, but that requires having a programmable/updatable firmware keyboard in the first place. And that closes the loop of my argument: People that want to update the firmware in their keyboard will do so, whether it's in the browser or by installing a potentially shady and not at all sandboxed third party application.
At least in the browser, permissions are time limited and scoped to explicitly granted devices.
> WebUSB IIRC still does not have origin restrictions
How would you even enforce these on the open web?
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.
As opposed to dodgy windows-only installable software from some weird site to flash devices instead? I’ll take my chances with webusb, thanks.
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.