upvote
I see this slightly differently. Before, if I wanted to be able to do something like flash firmware onto some device I would have to download some random C++ application and install and run it on my local machine. As well as having access to all of my USB devices, it also had access to everything else on my system's user context. I didn't have a way of running that code and only giving it access to a single USB device and nothing else. Now, I can avoid installing anything at all. I visit the project page and opt-in to some flashing flow that's running in a sandboxed env. When the app requests it, the browser asks me for permission and I get to choose exactly which USB device I want to give it access too. That's picking exactly the minimum "outside" access I want to give it, nothing more. It doesnt get to read/write other USB devices I didnt choose. I doesnt get to read/write to my filesystem. It doesnt get to call system APIs. It doesnt get to set itself to start at startup. It doesnt get to install an auto-updater. For me, this is a better security posture than installing random win32 apps.
reply
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.

reply
If you're worried about that, you can just disable WebUSB in the chrome settings. Any website will be denied access to that API from now on. And what's even better: you can selectively enable WebUSB for some websites.

That's what I do and that's what I suggest for any security-conscious user to do. Just explore Chromium settings, there are dozens of various APIs that could be disabled. Do you need Web MIDI? I don't. Disable.

Won't work as a default setting for average user for sure, but if you consider yourself an advanced user, do that.

reply
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?

reply
It's pretty common to pick a few config parameters, click, and flash a firmware that does the things you want.

Yes, you could make the configuration into a separate uf2 object that overwrites other bytes, but that's yucky.

The access is explicitly per device. Even for plain flashing, it's safer and simpler than to download and shuffle random files.

reply
trivial for you maybe but many people don't know how and where to find the right firmware for their specific device, and can be in environments where the UF2 volume isn't as obvious (e.g. using a phone)
reply
Are you more comfortable with installing native apps to control your hardware? Or you are more comfortable with opening a webpage to control your hardware?

With WebUSB implemented in major browser, you can be sure that they took extraordinary attention to all security implications.

With some random application from tiny developer, can you be sure about that?

I know for sure, that I prefer a webpage isolated in the browser for anything that could be done in a browser. I'm very hesitant to install anything locally.

reply
Whether we like it or not, the distinction between an app and a web page has already eroded, and is, and only will be, eroding more.

Even for local apps it's starting to become common to ship the app in an interpreted language where the interpreter is a browser instead of say python & qt.

reply
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.
reply
That's fortunately easily fixed: Don't grant them access!

But please don't tell other people what they should and shouldn't do on their own hardware.

The world has enough corporate walled gardens. I even enjoy using some of them sometimes, but the world would be a strictly worse place if these were the only remaining way to use computers.

reply
Then don't select the device and don't press the 'allow' button when prompted.
reply
It's already got access to CPU and RAM...how else do you think it works?
reply