Hacker News Reader

Comment by jeroenhd | Hacker News Reader

I can count the times I've needed WebUSB or WebSerial on one hand, and I own microcontrollers. I don't think the fingerprinting risks are worth it for the dozens of end users that don't need to download an electron app to interact with physical hardware.

Implementing the feature and then locking it behind a dev toggle is madness. That's wasting hundreds of hours of dev time that could've gone into something useful to expose a feature nobody will be able to find anyway.

These Chrome-only APIs can stay with Chrome for all I care as a developer. You need one Chromium browser standing by for when websites are actually broken in Firefox anyway, just use that when doing web USB stuff. It's a neat tech demo, but not something that a browser should be doing.

The fact that nobody has made a Firefox addon to add WebUSB capabilities probably shows that this is not worth the dev time for the people that do use the feature.

View on HN

Is is really handy if you have a programmable keyboard that use a web configurator/firmware builder. E.g. ZSA's Oryx. Downloading the firmware and then flashing with another program gets old pretty quickly.

That said, I don't really like the browser having USB access, etc. I agree that the potential privacy/security issues are not worth the comfort it provides.

(Yes, I know you can script your way around it by monitoring a download directory, etc.)

It's gotten a lot easier than it used to be. The Glove80 is configured by downloading a firmware file and dropping it into a mounted folder. That's not very onerous at all.

That sounds terrible to me. Can you also load your old file back into the app, say, if you want to check what the existing key mappings are? Still, I don't see the point of jumping through those hoops when WebUSB isn't something that automatically happens without the user explicitly granting access to a specific device in a dialog. People are acting like a Facebook ad can just enumerate all your USB devices and turn on your microphone or something.

> Is is really handy if you have a programmable keyboard that use a web configurator/firmware builder. E.g. ZSA's Oryx. Downloading the firmware and then flashing with another program gets old pretty quickly.

I have five of those keyboards, and I haven't flashed them in years. "Downloading the firmware and then flashing with another program gets old" yes, but you don't deal with it every day? or even every month?

Flashing every day isn’t too uncommon if you’re often changing the key map, macros, and other configuration. I probably flashed my QMK keyboard an average of 10 times per day for the first week, and then that tapered off to once or twice a day for a while.

I sure hope you're aware that you're not the typical browser user.

Could you explain why are you flashing your keyboard so often? I have QMK keyboard, and I never felt like I’m missing anything by using it as is out of box. It also has a hardware switch for Mac/PC layouts, which is the only feature I could imagine having to flash it for, if that wasn’t available

Changing the layout of key map layers for convenience, and macros, back when I assembled my first QMK keyboard. Haven’t touched it in years now, though.

> Flashing every day isn’t too uncommon if you’re often changing the key map, macros, and other configuration

That sounds like a failure in design of the keyboard and/or your own personal use case instead of the designed-for use case.

I doubt you have this same sentiment about continuous integration in the context of work. Same concept. Eventually you get every thing dialed in and you keep it there.

Is LVFS not available for these devices? Sounds like it would be a better fit. https://fwupd.org/

The problem is that these firmware images are user-specific. Think of ergonomic keyboards[0], with a lot of dual-use keys, key combinations, macros, and layouts tailored to the user's intended use case. The configuration is baked into the firmware itself, so you can't just serve a single firmware image to everyone via LVFS.

[0]: https://www.zsa.io/voyager , for example

Hmm, that's a poor design. Firmware should be separate from its configuration.

This problem has been mostly fixed by newer keyboard adopting UF2: the bootloader presents itself as a USB flash drive, so uploading new firmware to your keyboard is literally a drag-and-drop.

The only drawback is that it is a little bit of a hassle if you're the type of person who changes out their macros every single day. But then again, if you need it that frequently installing the configurator tool locally isn't a huge deal I guess.

> if you need it that frequently installing the configurator tool locally isn't a huge deal I guess.

This sucks because the manufacturer has to forever keep supporting multiple native apps (given that mech keyboard users are pretty technical, not just Win/Mac but also Linux are necessary). Mac OS in particular is an insane moving target, and they tend to completely break app compatibility with every single major release.

What ends up happening is they'll ship JUST a program for Windows and shrug at everybody else.

Isn't it less of a hassle, because you can just save multiple configurations and just upload the configuration you want to use now?

In general, I don't want my browser to have direct usb access, but ZSA Oryx is the one place I'm annoyed by Firefox not supporting it. Honestly, I'd prefer having a native desktop app to configure my keyboard. But for my ZSA keyboard, I haven't found something as good as the web app for linux.

> I can count the times I've needed WebUSB or WebSerial on one hand

There are many things that would be possible with WebUSB that current browsers make impossible. My personal example is label printers: I would love for my SaaS app (PartsBox, https://partsbox.com/) to be able to print labels, but there is no way to access a printer from a browser other than through the "Print…" dialog, which is no good if you need to send ZPL2 commands to a Zebra label printer.

WebUSB is not necessarily the best imaginable solution to that problem but it would help.

I don't want to tell my users to use Chrome. But Firefox doesn't make my life easy (see also https://bugzilla.mozilla.org/show_bug.cgi?id=896666 — a bug opened 12 years ago, about Firefox closing websockets when the user clicks a download link).

Isn’t that what printer drivers are for?

Why install and run some arbitrary blob that has full access to your computer, when you can open a web page and grant access to a single device?

Yes, and they run with kernel level permissions.

Yes, and how would you talk to those from a web browser?

Again, the "Print" dialog is not the right way for labels: there is no way of guessing of what it will do to your formatting, or whether it will choose to print A4-sized stuff on labels.

So every website that prints labels should solve that separately?

There is an age-old problem here: how to take content on the screen and produce a printed artifact. It’s not easy, and everyone hates printer drivers, and kernel permissions, etc.

But if you want any portability of content at all, you need something like a print dialog and something like a printer driver. All the WebUSB stuff is just embedding those problems into the application.

What are the fingerprinting risks? Can websites gather any data without user consent?

I used WebUSB to flash GrapheneOS onto my Pixel, and to flash WLED on an ESP32 and it felt like magic. I'm erring on the side of this being a net positive.

> Can websites gather any data without user consent?

No, you need to explicitly grant access to every hardware device a website wants to touch. The FUD in this topic is a little out of control.

"Hello GrandMa1950, please plug in your security key and select the device called /dev/ttyUSB0 in the pop-up, so we can authenticate your log in. Thank you!"

I'm fairly sure that would work. The FUD is likely well warranted.

Even a lot of reasonably tech-savvy people might not know the difference between the WebUSB consent popup and the security key popup.

That was my very first concern when I thought about WebUSB too, but Chromium has a block list of Vendor IDs which includes various security keys.

https://chromium.googlesource.com/chromium/src/+/967d11212c9...

Sigh. That's no different than "Please install this App" or even "Please read me this code". Yes, user-mediated authorization is an extremely difficult nut to crack. There will always be holes. There will always be unsophisticated users. But if you agree (and you do, right?) that people want to use external USB devices on their own devices, then you have already accepted that risk.

Freaking out because of the specific technology used to deploy the software is mostly just whining. This being HN, at least 60% of the resistance to web apps having extended capabilities is because of the company building the browser.

My experience with WebSerial/WebUSB/whatever I used (I don't know) is:

- go to espresense.com

- hook up an esp32 via usb

- click connect, click flash

- done

- repeat 10 times for all the base stations I needed

It reduces the friction of flashing a dev board to ~0. I absolutely loved it. I'm only annoyed that I had to open Chrome to do it (my daily driver is Firefox).

Yeah. People don't remember how painful it was to download a separate flasher and driver for every single board you tried to flash.

I fire up Brave for WebUSB for flashing ESP32 devices. It's Chrome, but less Googly.

I believe Chromium might be safer to use than Brave. https://old.reddit.com/r/browsers/comments/1j1pq7b/list_of_b...

You are misrepresenting your own link. Not to mention this is a biased list.

Chromium does not include any of the many built in privacy features, add-block features, etc..., that Brave does by default.

Don't get me wrong, Brave's crypto junk is garbage, but atleast you could understand the rational for it. They seem to actually want to make a privacy focused, general purpose, browser fork, and they need funding from it from somewhere.

The only bullet here that might have to do with "safety" is:

> In 2021, Brave's TOR window was found leaking DNS queries, and a patch was only widely deployed after articles called them out. (h/t schklom for pointing this out!)

Its pretty well known that the official TOR browser is what you should probably use if you need TOR.

"The need funding from it somewhere" is the concerning part. Don't let desperate people run your browser. They already got caught injecting their own referral codes into links then just said "oh sorry."

I'm not here to claim that Brave is without issues. The whole crypto stuff is stupid. However, they have seemed to responsibly moved on from their previous failures, and that's okay with me. None of their previous failures intentionally attempted to affect user privacy or sell user data. That's what we are talking about here.

Brave is objectively better for user privacy than base Chromium. That is without question. If you disagree, please provide evidence to those claims.

Plus webusb is a 0 day waiting to happen. Browsers should not become os, they are exposed to the entire web.

Browsers have been OSes for the past decade.

An OS designed by no one and implemented piecemeal through a thousand disconnected RFCs.

And targeted by tens of millions of developers for billions of users.

Isn't webusb almost a decade old at this point? Downloading sketchy flashing software is also a good way to get malware. I trust Chrome more than I do 5 separate toolchains and eclipse clones lol.

Say what else you will about browsers, but they do offer a sandboxed execution environment across all major OSes, only limited by browser capabilities.

There's an argument to be made for limiting some of these permissions to "installed" PWAs, but these beat random Electron apps running with full user permissions in terms of security.

If random electron apps is not connecting to the entire internet, loading completely random code from any website in the world, not they don't.

Before USB4, USB came with DMA. If your sandbox has ever an exploit, that's close to instant rooting capabilities exposed to the entire web.

USBC an hold a ton of power. One sandbox exploit, and the entire web can fry your machine.

This is too dangerous of a capability to be exposed to a public network with tons of malicious actors and bots.

> If random electron apps is not connecting to the entire internet, loading completely random code from any website in the world, not they don't.

Why not? Nothing in terms of sandboxing prevents them from doing so, unlike webapps.

> Before USB4, USB came with DMA.

DMA is mainly a threat to the host, not the device, isn't it?

> USBC an hold a ton of power. One sandbox exploit, and the entire web can fry your machine.

How so? There isn't a "fry this device" USB protocol command. Obviously you could drain a printer's ink etc., but that's just another facet of "don't give random websites/PWAs access to sensitive hardware" that the browser UX indeed has to get right.

>don't need to download an electron app to interact with physical hardware.

I don't need to download an Electron app to interact with physical hardware, full stop, WebUSB or not.

Is that where we're at now? That writing a small utility to configure a widget over serial in platform native tooling is beyond us?

In a cross-platform way, kinda yeah. Especially on the Mac side where OS updates always break everything.

Yes, it's beyond many, and people are clearly both willing to write and grateful for easier alternatives. Why celebrate gatekeeping?

And even then, just because I could write a small utility doesn't mean I will, 99% of the time. I think being able to easily benefit from others work is generally great.

The problem isn't a widget in platform native tooling, the problem is there's only going to be one, and that platform is Windows 7 and nothing else (including newer modern versions of Windows).

The fingerprinting risks, to a layman, seem to be a red herring?

Have the user consent occur before the point of enumeration.

Or lock it behind the user already having installed the pwa and require confirmation (i.e. a browser site gets a flat denied message, a installed PWA gets a permission prompt).

Sort of depends on Firefox supporting installing PWAs though..

For webserial this feels like it would make sense... WebUSB does feel like an overreach and too much.

Consent is combined with device selection, at least in Chrome.

That leaks at most one bit unless the user selects a device (i.e. whether Web USB is supported or not, as a delayed error due to the user clicking "deny" would be distinguishable from an immediate one), and usually much less since that bit is very correlated with "is Chrome/Chromium-like".

- Firefox addon to add WebUSB capabilities

Note this is beyond the capabilities of web extensions, you'd also need the user to install a cooperating native program.

At which point people are just going to make the native program an electron UI and bypass the browser entirely.

why bother with electron madness when you have 20 minute job for pyqt.

Because pyside and PyQT suck in their own way. I mean sure if you only know python, or need python for other stuff, they are fine I guess.

I've had a rather big project (well, a proof of concept turned into a real project, the usual haha) built with pyside6 and looking back, I'd much rather have used electron/ts/JS. But we needed python for other stuff so I guess it made sense at the time.

Fingerprinting risks? Is there some device enumeration capability that I don't know about? I thought you had to explicitly grant access to the specific supported device in a browser popup window.

Same – but I'm almost certain I would have given up if it weren't for Web USB, rather than install some dubious local unsandboxed software or running some Python script pulling in tons of dependencies.

The same goes for Web Bluetooth.

You know fingerprinting is impossible to avoid, right? Adding WebUSB to the mix does not make users more fingerprint-able, because we've long, long been saturated at users being 100% fingerprint-able just because we can correlate their rough location from their IP address to the time of day they access certain resources.

This is something that bothers me about Firefox fans talking about privacy and security in the browser. There really never was any. You fundamentally cannot be private on the Internet that we currently have, at least when stood up against motivated actors. But on the web, at least you're not blasting your identity to absolutely everyone. In direct contrast to every major native OS that makes it pretty easy to get not only the user's name, but their preferred email address. Or every major mobile OS that just hands app developers a tracking ID for every user. No need to fingerprint! The OS gives it to you! Oh, they fingerwag at you, "don't correlate these IDs month-to-month when we reset them!" Yeah, I get it. <wink wink>.

So, when a browser that has been losing users year-over-year for the last 16 years and is now in "also ran" status blocks functionality for the browser, the one place where user identity is at least made hard, telling people they think it's better for developers to make native apps for the functionality, it's really hard to take them seriously on their word that they are privacy-conscious.

How do you get from "it's possible to correlate somebody's application usage times and IP geolocation" to "fingerprinting is impossible to avoid"?

IP tracking is somewhat avoidable using things like Tor and iCloud Private Relay (not so much most VPNs, though), and even if it isn't, I'd still much rather be in an anonymity set the size of a densely populated ZIP code than one of size one.

> every major mobile OS that just hands app developers a tracking ID for every user.

Which ID does iOS hand to developers? I was under the impression this hasn't been a thing anymore for several OS versions now.

Reply on news.ycombinator.com