Hacker News

You have to balance the this ease of use with increasing potential attack and fingerprinting surface. Correct approach is something in the middle - a separate off-by-default setting or recommended official extension.

...in your opinion. the firefox team disagrees.

The whole dance has been made significantly easier by the adoption of UF2 flashing by large parts of the custom keyboard hobby: the device temporarily pretends to be a USB storage device, so you can now download the file and drag&drop it to your device.

Still not quite WebUSB-easy, but a massive improvement over needing dedicated programming software!

is anyone making backups of these webapps? my keyboard uses one for everything, I've been meaning to learn how to host a local copy for when the website inevitably gets shut down

Ugh, I hate this trend. I'm using ZMK on a wireless split Corne and I have to clone the ZMK config repo, edit the config, push to GitHub, use some GH Action to compile the firmware, download it, unpack it, and then flash it. WTF happened? This is a terrible workflow, and I was not able to get this done locally after spending an entire day on it. Why can't this shit just compile on my machine? How about I edit a text file...and then compile it without all the bullshit, like installing Docker, about three or four language-specific package managers which install things not vetted by my distro's maintainers and probably run some bash scripts fetched with curl? And honestly I'm not really comfortable running firmware compiled by the Microsoft, the company known for their stellar software quality and security. Really though, I'm surprised, this was my first time being exposed to this kind of insanity. House of fucking cards.

I'm not even criticizing ZMK, btw, this is just an unbelievably obnoxious workflow. Please, nobody do this. The anger is short-circuiting my brain.

That's the exact scenario I first found it useful as well, earlier this month. It's especially nice as someone used to there not being Linux options for stuff like this.

It just can't run on any device with a security policy in place.

How is it any different with downloadable firmware?

You can even do it from another Graphene phone!

One that’s been using Attestation, for bonus points.

> not so much as a default-enabled feature.

The browser opens a popup asking you if you want to grant access to a specific device for a specific website, it's not like random websites can just run adb commands on your phone

Chrome has had WebUSB since 2017. I really appreciate it for one-off configurators and those types of tools.

Well it's a stand-alone program too, not just an extension. I kinda wish extensions could act as full programs too but computers need better sandboxing.

That was always the case. Lots of “flasher” applications have had web dependencies where they’d download the latest firmware to a temp directory before flashing.

Aren't most retrocomputing USB devices running open source firmware? Adding a descriptor "WebUSB supported" is a few commits and a firmware update away.

This right here is the reason I like it and web bluetooth too, with them 'just working' regardless of platform I'm using. Miss me with some unsigned questionable app that only runs on windows as admin.

Is there something specific in that process that required WebUSB vs just normal USB? Sounds like phone makers could have done this since forever if they wanted to, what makes WebUSB particularly useful for this?

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

> 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

Web browsers, with their many CVEs, are the pinnacle of security.

It doesn't matter whether we like or dislike things that don't exist. The world where app makers don't ship this way doesn't exist.

Conversely, a web app platform that includes all the primitives that are needed to build a decent web app (as opposed to bring your own everything/building castles from grains of sand model) would be nice. It doesn't necessarily have to be a browser, though.

There are plenty of crippled web browsers out there. Heck, on iOS, it's the default.

nyxt? helium? midori?

There are hundreds of browsers these days, you shouldn't have a hard time finding one that fits your needs.

When the alternative is downloading arbitrary executables I find the browser sandbox to be a reassurance.

Then don't install the extension

You probably don't need any Web hardware API for that, just WebRTC.

On macOS, I think I've installed device drivers exactly once in the last decade, and they were for a weird printer.

The security implications if this goes mainstream is that you are expected to do this for all kinds of hardware.

Right now that isn't the case and I can't remember last the time I had to uninstall untrustworthy native drivers.

A lot to lose, very little to gain?

The nice thing about USB devices is that they don't need native drivers. Hardware that requires native drivers for USB is pretty rare, at least for many common cases (keyboard, mice, controllers, joysticks, printers, dacs, headsets, cameras, ..), and are easy to avoid.

What product categories exist where all entries only work (over USB) with native drivers?

why would you be using untrustworthy hardware to begin with?

Sounds like something that could have a standalone usb-driver-container or special chromium fork for the 0.00001% of users that need it instead of bloating every browser with yet another niche API and the inevitable security holes it will bring.

Doesn't linux have the drivers already?

That sounds like a Windows problem.

you do know microsoft OS 2.0 descriptors are a thing, right? or that you can force the unknown device to use WinUSB

but really most devices you want to interface to via webusb are CDC and DFU so.. problem solved?

You can have userspace drivers for usb devices in Linux

> What are the security implications this raises

It increases attack surface area on the browser. Even if you do need to "accept" a connection for a device, this isn't foolproof. I imagine adding WebUSB is a non-insignificant amount of code, who's to say there isn't a bug/exploit introduced there somewhere, or a bypass for accepting device connections?

This would still be better than downloading random native programs since it's under the browser's sandbox, but not everyone would _ever_ need to do something that requires WebUSB/USB, so this is just adding attack surface area for a feature only a small percentage of people would ever use.

The solution is to use a smaller separate _trusted_ native program instead of bloating the web with everything just for convenience. But I understand that most are proprietary.

I say all this, but a part of me does think it's pretty cool I can distribute a web-app to people and communicate via WebUSB without having the user go through the process of downloading a native app. I felt the same way when I made a page on my website using WebBluetooth to connect to my fitness watch and make a graph of my heart rate solely with HTML and Javascript (and no Electron).

I'm just not too happy about the implications. Or maybe I'm just a cynic, and this is all fine.

None. People will follow any instruction presented to them when they think it will get them something they want. Mozilla’s stance here is infuriating.

> What are the security implications this raises that downloading native programs (needed for example to flash my smartphone) doesn't raise?

1. Permission popups fatigue

2. Usually users select the apps they install, most sites are ephemeral. And yes, even with apps, especially on Android, people click through permission dialogs without looking because they are often too broad and confusing. With expected results such as exfiltrating user data.

> The spec is still in draft because Apple refuses to let it move forward

This is untrue. Web standards need two independent implementations. Google can’t convince any other rendering engine besides their own to implement it.

It doesn't take a single no from Apple to veto it; it takes a single yes from anybody outside of Blink to move it forward. Nobody is doing that.

Here is what Mozilla have to say about WebUSB:

> Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they're connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.

— https://mozilla.github.io/standards-positions/#webusb

Until Google can convince anybody outside of Blink to implement it, it is not a standard it’s a Blink-only API.

Are you calling WebUSB a basic feature? Because I'm willing to discuss whether we should have it, but that seems like an exaggeration.

How do you make sure that technically illiterate people don't just click away the requestDevice() popup? IMHO a browser offering device level USB access is a security nightmare and there is no way this can ever be made safe and convenient at the same time.

ok, let me expand on why I don't like it...

It's making a niche rarely done use case safer at the cost of making the common case (browsing the web) less safe.

And yes, I am fully aware that I can not press the button that give random sites access... But the issue is it increases the attack surface and is yet another thing that I could get tricked by on a bad day.

The OS should really be able to run code like a firmware flash utility in a sandbox that only has access to one USB device... But instead of improving the OS we keep adding features to the browser which increases the attack surface.

I have a very long list of things I am unhappy about the OS allowing just any app to do, especially app installers/uninstallers should not be a thing.

Flashing was already solved by UF2, where the device-to-flash temporarily pretends to be a USB storage device. Giving raw USB access to to random websites for that is massively overkill.

I could understand it if you were trying to do realtime configuration of or interaction with some device like a printer or a Stream Deck, but something as trivial as firmware flashing?

They're converging towards the middle, which is good, but it's not going to be the same thing. Apps use web tech for convenience and native APIs for things you can't do in web. You're expected to trust apps and extensions more than websites.

If history is a lesson (of going from lower level to higher level programming languages), the exact opposite will happen: there'll just be so much stuff out there that any eventual gain in efficiency will be dwarfed in the grand scheme of things.

Please, lord, let this be sarcasm.

I think they see privacy as one of their primary valueadds, and are concerned about the privacy implications with exposing a (PAN) network to the internet that probably wasn't designed to be exposed to such an adversarial environment.

They should just add a "Security Console", with black background and green text, and a simple shell interface for enabling/disabling flags that gate whether these requests are automatically denied or create a permissions popup. Anything dangerous starts disable by default.

Short of crippling capabilities to save dumb users, the best we can do is make the process scary enough that Grandma won't do it without calling her grandson first.