Firefox does not support talking to arbitrary USB devices (whereas Chrome has WebUSB to do that). However, Firefox does support talking to U2F security keys over USB.
This project programmed a microcontroller to pretend to be a U2F security key. The goal was to talk to the microcontroller over USB through Firefox.
Yes, this isn't for accessing arbitrary devices. It can be used to build custom devices that can be used by webpages without any consent prompts though.
No, because the device they are accessing needs to be specifically built for this use case. So you would need to give the user a malicious device then use a malicious webpage. The attack scenario isn't impossible, but is far less then those that are possible with WebUSB.
While not impossible, I just can't think of a good reason why you'd need them to access a malicious webpage when you've already gotten them to install a malicious device.
If you have a keyboard with QMK/Via firmware, customising it with WebUSB is a nightmare.
You essentially have to make one of your /dev/hidraw devices completely world readable (inviting all sorts of keylogging shenanigans) before the browser can interact with the firmware.
Its creepy beyond creepy in terms of usage, and offline customization tools are all Electron based so there's not much advantage.
One reasonable workaround is to construct your desired keyboard layout with a template json file on the website, download the resulting json and then flash the firmware to your keyboard via sudo-level flashing tool.
> download the resulting json and then flash the firmware to your keyboard via sudo-level flashing tool
Several microcontrollers come pre-shipped with MicroPython and an emulated flash drive where you can drop Python code to alter the running main()
I imagine you could easily do the same with keyboards, except the FS throws an error when you're writing invalid JSON and the emulated FS has emulated security properties so only admin users can write to it. No need to sudo, just authorise the permission prompt when you download/copy the new config to the virtual flash drive.
You could add a little hardware button or toggle switch to the board to enable/disable flash drive emulation if you really wanted to be secure. Write your config, unmount, flip toggle switch.
There should be - there's three LEDs (capslock, numlock and I forget the third one) on standard keyboards which can all be set from the OS side... and at least caps lock (I think!) can be set from Javascript, so it's essentially an 1 bit wide communications bus, three bits if it's an ordinary OS tool.
I love scroll lock still existing on keyboards. Some operating systems still use it to control text scroll for some reason (useful when you don't have `screen` installed maybe?), but I mostly use it for toggles in video games. It shows the toggle state on a physical interface, like one of those fancy programmable macro keyboards, but on commodity hardware!
This is a little confused. The idea behind the permissions model is that the browser suite is responsible for mediating access to the hardware. Obviously, yes, you need to give it access to the hardware in the first place for it to do that. If you don't trust the browser as a manager of a hardware abstraction layer, that's fine. But that's the model that Via expects. I don't see how it's any more "creepy" than letting your browser read your camera or microphone or storage.
I can go to https://usevia.app on a locked down employer-managed chromebook and hit my QMK keyboard with no trouble whatsoever. And needless to say I can't touch the /dev nodes at all on this box.
Sorry, you're right. I guess it allows you to just change settings. Still, its unclear what those settings constitute, and how easily a keylogger could be embedded there.
> and offline customization tools are all Electron based so there's not much advantage.
Afaik it's only any Via support per se that the keyboard firmware has allowing for such on the fly customization, rather than QMK. With QMK it's all manual flashing (I was somewhat surprised that it was easier than I was expecting to customize the layout/layers/lights with code though, largely thanks to the supportive community).
If you're looking for a QMK alternative to Via, I recommend you try using QMK Configurator and QMK Toolbox. The combination is not as ergonomic as Via, but at least you get a graphical keymap editor that compiles firmware and is far less bloated. The experience has been good with my Keeb.io boards.
I own Keychron devices with QMK firmware, and Brave (Chromium) is really explicitly communicating whenever the keyboard is being configured. I have also installed GrapheneOS using it, & honestly I cannot imagine getting tricked into launching a keylogger that way. I already trust Keychron and GrapheneOS to some extent so the point is moot, I think.
what are you talking about?
I have to approve the website before it can access my devices via WebUSB.
What's the actual issue / path for keylogging etc. there, care to explain instead of fearmongering?
The browser itself shouldn't have access to raw devices, as that means giving all programs running under your user the ability to flash your keyboard firmware.
The point of flatpak, wayland, etc is to prevent software from having access to everything. Making all USB devices readable and writable again circumvents the entire sandboxing concept of modern systems.
Windows and macOS allow access to USB devices for user programs. Linux by default does not allow access to USB devices, you need to chmod corresponding pseudo-file in /dev (or write udev rule to make it happen automatically). So when one uses WebUSB (or any other usb software) without root, it won't work immediately.
Modern Linux systems are more complex than that. E.g. if I plug in a USB drive and one of its partitions has permissions
brw-rw---- 1 root disk 8, 2 Mar 14 11:51 /dev/sda2
I can still mount it even though I am not root or in the disk group. Why? Because many Linux desktops/apps can use polkit to get elevated access if a set of policy rules allow them to do so. E.g. there is typically a policy for udisks that allows clients in active sessions to mount filesystems.
Similarly, I can use fwupd to update the firmware of my machine without ever becoming root, but as a user I certainly don't have the device permissions to do it. So how? The system has a policy rule that says that every active, local user that is in the wheel group can run an update. The fwupd daemon that runs as root will then execute the update for the user.
Being in the wheel group is not enough to write to the relevant device nodes. At any rate, my point was that device permissions and UID/GIDs alone do not determine whether a user or application can write to the device. Higher privileges can be mediated through polkit.
It has nothing to do with sites. You are missing the point. To access USB device with Linux, any software, including browser, should have permission to access certain files in /dev.
You visit a page. It asks for device access. You get a dialog box choosing the device that matches the filter the site wants. You can either choose a device or decline. Site does not see anything other than what you approve.
You're the one missing the forest for the trees. The security risk is not caused by websites, but by the fact that the browser can access your USB devices in the first place.
By giving the browser access to your USB devices, the browser could act as a keylogger even when you're using other applications.
Further, as there's no proper way to sandbox this, you wouldn't just be giving the browser keylogging capabilities, but any native app running under your user.
You could have an elevated service that has separate configuration for which devices the user wants to grant access to, and it could even work as a proxy to disallow "bad" usage patterns. The interface to USB devices doesn't need to be directly with the kernel.
It's true though that it's difficult to ensure only a certain process has access to it, though the default value set to ptrace_scope by e.g. Ubuntu is a step towards helping that.. But in principle the service can know which executable is issuing the request.
All in all this seems quite a big effort for perhaps not that great benefit. In the meanwhile I'll be using Chromium for WebSerial and WebUSB needs.
Yeah I have this udev rule, it fails to trigger properly and I think it might be because of what it thinks the user group and the web browser group is. I haven't fully debugged it, but I can tell you that this does not work for me
> For any rule adding the uaccess tag to be effective, the name of the file it is defined in has to lexically precede /usr/lib/udev/rules.d/73-seat-late.rules.
If your application is running as a different user, or in a Flatpak or snap, you may need some additional or alternative configuration.
This comment section is a fascinating mix of people who use WebUSB talking about how great it is and people who don’t use WebUSB being confused about why anyone would want it.
In my experience it’s been great. Most of the WebUSB utilities I use are also available as self-installed apps, but I use them so infrequently that it’s much easier to use the web version than to go through the process of installing an update and using the app. It’s also one less app I have to install.
I would have expected this to be popular with the people who are tired of having an app for every different thing.
Yeah, except that someday the site that provide that useful app may be gone once and for all, while the app would remain just fine until you uninstall it. So it's a double-edged sword.
Yeah but if I need to talk to a local device, I trust browser's security far more than a random vendor's native app. I recently bought a keyboard that allows remapping keys; the vendor has both a native app and a web app to do it: I trusted the web app far more.
Maybe I'll believe you when desktop operating systems have a mature and easy-to-use sandbox for local apps. Any random local app by default having access to ~/.ssh/id_rsa no attack required is a much bigger threat for me to worry about than thinking a web app might attack my browser to steal data belonging to a different origin.
That's irrelevant. Both local apps and web apps are subject to supply chain attacks. The difference is that a local app that has had a supply chain attack carried out can read my documents, my private keys, my photos, etc; a web app that has similarly malicious code cannot do any of that. The browser protects me because it has a sandbox.
I also do not understand why you refer to "trusted web app" whereas in my comment above I have stated that I need a sandbox to run the code; I clearly don't trust it enough. The whole point is that the browser allows me to run untrusted code safely. And supply chain attack is one of the main reasons why I don't trust it enough.
> Web apps have a magnitude more dependencies than desktop apps
Irrelevant. As a user I do not care how many dependencies an app has. I care about my own data security and browsers have an excellent sandbox.
> Because you referred to apps stealing code from a different origin
I referred to apps stealing data from a different origin. Think my open web mail tab containing my email. That's an attack that browsers can prevent.
> I talk about the app you use to access the usb device per web usb.
That's what is supposed to happen. I explicitly want this vendor app to talk to vendor hardware.
> Previously it was about a malicious app attacking per browser exploit.
A malicious web app needs a browser exploit to access my data which costs millions of dollars on the black market. A local app does not need any exploit to access my data.
> the app is allowed to access the data but because of the supply chain attacks your data gets stolen
The app is never allowed to access my data. It doesn't matter whether supply chain attacks are involved or not.
That's what I currently do but it's not easy to do at all. For one, there's no simple and built-in way to copy my desktop user settings to the new user. For two, when you switch to a new user, you can't simultaneously do things as the original user in the same desktop session.
If a web browser has a sufficient bug to allow access to webusb without permission in an exploitable way, it's probably also exploitable enough that even without webusb you'd have hardware access via RCE.
I've used WebUSB to flash an Android device before. Yes, it's useful and easy, but it's also ripe for vulnerabilities. Web bloat needs to stop growing. The browser should not be a kitchen sink for anything anybody in tech wants. Installing a native application is not that hard.
A bit OT, but most of this thread seems to be generally about WebUSB, not the OP (although it is a pretty cool hack!)
On one hand, I really want WebUSB, but at the same time, I REALLY don't want the average person to have WebUSB.
Practice has shown that consent popups do not work and people will manage to give consent to anything without even realizing it ("I never clicked on anything", they say, while I swipe away 50 spam push notifications and remove push permissions from about a dozen "news" sites).
Honestly, I kind of like the Internet Explorer version of permissions, where you needed to mark certain sites as "trusted" to enable certain features. The process is hard to discover, takes a decent amount of time, is a bit confusing, done in a system-styled modal popup with reasonably scary and large warning icons.
If people had to go through this process to mark a site as "trusted" in order to use WebUSB, WebBluetooth, and the other dangerous APIs, far fewer would do it by accident. The UX would still be better than installing a native app and you get sandoxing as a bonus, so I think the tradeoff would be worth it.
Chrome Web Notifications are also a complete dumpster-fire. In my experience the average older folk has no idea what web notifications are. They accidentally enable notifications from shady websites over time, and then blindly believe the web-spam notifications being pushed to their phone informing them *HELLO YOUR PHONE HAS VIRUS DOWNLOAD "CLEANER APP" TO FIX BEFORE PHONE DIE* is legit.
> On one hand, I really want WebUSB, but at the same time, I REALLY don't want the average person to have WebUSB.
This is the endless struggle of all time. It's like some people have some sort of super-messing-things-up power. If you don't make something LITERALLY impossible to achieve, they will find a way to do it by accident. Always. They will go out of their way to find things to do by complete accident, and they will never have any idea what they're doing! They'll follow guides to change settings they don't understand, trigger functionality they don't understand, grant access they don't understand, no matter how complex you try to make the process, no matter how many warnings you add, and no matter how hard you try to guard against exactly this kind of idiocy.
And this sucks. Because there are people out there who do know what they're doing, who do things on purpose, and who would appreciate to have power that it just so happens that an Idiot should never be given. It is practically not possible to expose that power without being flooded by Idiots who did something Stupid with it.
I agree. One of the biggest things people don't understand is that most users simply don't understand what they're doing, and Google does not understand how to design software safe for them. Annoying processes seem pointless but often they have a very clear point: Making sure intent is solid.
Apple recently implemented some web APIs in a strategy that shows they actually understand designing for people: The APIs only work if you "install" the website. It makes it possible to access useful PWA features... but it doesn't allow any arbitrary website to do so, there's an extra process normal humans understand to enable it.
An installed PWA is also persistently visible: It's on the homescreen. So it's a visible reminder of that permission grant and a clear sign of something a user wants to have some sense of access to them.
> Google does not understand how to design software safe for them
The only way to design software safe for Idiots is to design software where it is not possible to make a mistake, not possible to have an accident, and not possible to compromise anything even on purpose.
Unfortunately, non-Idiots don't tend to appreciate that kind of babyfied experience, so we tend to end up with some compromise where the things that Idiots will inevitably mess up should ideally be the least consequential possible things that can also provide some sort of value to non-Idiots.
As a result some of the more advanced experiences that are entirely inappropriate to grant Idiots are simply not available, because if they were, then Idiots would find a way to cause really bad accidents.
> On one hand, I really want WebUSB, but at the same time, I REALLY don't want the average person to have WebUSB.
I really do want the general public to have access.
Many people need to interface with devices and we are sadly in a situation where Apps served by closed App Store are the only option.
If I want to distribute a way to allow the wider public to access a device that no longer has official support, WebUSB is by far the easiest way.
In an alternative world where Chrome did not support it, the average person would need to be able to install and run [python or other scripting language].
If the developer was really keen then they might offer a desktop app or go through the long and expensive process of submitting it to an App Store.
I think WebUSB can have a secure UI and I also can’t think what devices the average user has plugged in that could be compromised. I am pretty sure you can’t use WebUSB to take control of a keyboard or mouse (HID), storage, wifi, audio, smart card of U2F devices.
But it’s super useful for proprietary label printers, random toys/gadgets and programming/flashing microcontrollers.
Modal prompts where applications (and websites!) request permissions are an absolutely terrible UX. Sure, they're very easy to use and convenient, but they're easy to use to accidentally grant very wide access to untrustworthy third parties.
Granting permission to pages should be, as you say, an explicit user-initiated flow via a permissions panel. The same should be so for sandboxed desktop applications. Does an application want to continuously record your screen? Then it should be granted this permission explicitly via a permissions control panel. It shouldn't be able to show a modal dialogue where people just click "yes". Many times, with good reason: they simply don't understand the technicalities of what they're being asked.
USB Serial is such a great thing, finally ending those annoying Electron apps that are only used for one thing. There’s a list of tools that now use the browser to set up devices, and it’s fantastic.
ESPHome(+ hundreds projects that use it as a base), Betaflight, ELRS, Flipper just to name a few.
I understand that WebKit lacks support since it’s developed by Apple, and I would also be cautious if it granted any access to peripherals.
But Firefox? Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time, so I simply stopped using it (one of the reasons). Reason they state for not adding support it is that user consent is not enough to access the device, which is just nonsense, they could have made it enabled under the developer flag or similar. Blink proved that it can be made secure.
I have a filling they are stubborn for no reason and are not seeing use cases that would make their browser usable.
> Reason they state for not adding support it is that user consent is not enough to access the device, which is just nonsense,
There was a kinda major security issue [1] where malicious websites used WebUSB to access FIDO/U2F keys.
This was bad because U2F credentials are supposed to be impossible to phish, as the browser's U2F API puts the domain name in the request to the token - but by using WebUSB, a site could request a token for any domain name.
And as both U2F and WebUSB popped up quite similar looking user consent boxes, it's pretty much impossible to avoid some users getting confused.
Google's solution, believe it or not, was to blocklist a load of devices for WebUSB [2] - so now anyone making U2F devices has to get Google to add every new product they release to the blocklist.
Everyone loves the fact the browser is a secure sandbox, letting users run untrusted code. I don't get why people want to poke so many holes in the sandbox.
> Everyone loves the fact the browser is a secure sandbox, letting users run untrusted code. I don't get why people want to poke so many holes in the sandbox.
My thoughts precisely. I want browsers to be welding holes shut, not opening new ones.
I’d think differently if user consent were required to load any scripts past a certain complexity threshold (e.g. if they’re heavier than that of an early-mid 00s website, hold off on execution until the user approves), but with how easily users can be taken to sites they never asked to go to every added bit of deep system integration a browser gains is a massive liability. The web is too built up around the idea of implied consent to be doing anything too fancy.
It does. Mozilla doesn't trust users to not be manipulated by malicious websites into doing so against their own interests. At GP link 2, Mozilla writes their rationale for concluding that WebUSB is bad:
> 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.
Personally, I'd be happy enough with an implementation of WebUSB that only worked with websites accessed over localhost or on the local network. I want to write data over USB to ESP32s and Teensys 3D printers and so on through an integrated local webserver.
3. You click 'allow' because you do want the website to access your Yubikey. Then you press the button on the Yubikey when the light starts flashing, because that's what you do.
yeah, this sounds to me like apparently some people think once again computer owners can't be trusted to grant a permission to anything because some clueless people can be tricked into shooting themselves in the foot.
IMHO I don't buy that this is worth nerfing everything. Without using the exact analogy from the above metaphor, what if we banned cooking appliances, because a bad actor might call people and trick them into turning the stove up to "High" and placing a roll of paper towels on the flame?
I use the WebUSB to manage my keyboard's configuration, and that popup is hard to misconstrue. Also what is even the overlap between users of USB security keys (the main attractive USB target I saw cited) and people who click mindlessly without reading anything?
This isn't just clueless people clicking mindlessly without reading anything. The user wants to log in with their U2F key. They get a box asking if the website can access their U2F key.
Even if they read and understand every word in the box, consult their security training (which tells them "when you log in with a U2F key a box will pop up asking you to select a device, that's normal") the only indication they're doing anything wrong is that the device selection box looks a bit different to normal.
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.
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.)
> 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 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.
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.
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.
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.
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.
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).
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.
"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.
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).
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.
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.
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.
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.
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".
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.
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.
> I have a filling they are stubborn for no reason and are not seeing use cases that would make their browser usable.
This is untrue. Privacy and security issues have been raised. Web Serial is not a web standard and cannot become one until Mozilla or Apple sees these issues resolved. Google cannot make this into a web standard unilaterally; standards need consensus.
I don't exactly understand the privacy and security implications here.
A website can prompt for precise location at any point. A website can prompt me to provide a certificate with my cryptographically proven identity at any point. A website can PROMPT for XYZ at any point.
Why should WebUSB be treated any different. If I give access to a device, I give access to a device. If I don't, they can't touch or identify it.
Because explaining exactly what can happen when you grant WebUSB access is not as clear as with a geolocation prompt. You can't get meaningful consent from users - not all prompts are equal.
The whole objective of WebUSB is to not generalize it. Meaning in theory someone could, if you explicitly allow access to a device, reflash your ESP32 with a HID mouse device that automatically uploads a sensitive file to the attacker.
But if the user was going to do this anyways (flash some unvetted binary to their device), the web still provides MORE security than having the user download flasher.exe + badbinary.elf
> But if the user was going to do this anyways (flash some unvetted binary to their device), the web still provides MORE security than having the user download flasher.exe + badbinary.elf
I've very very often heard people complain (even some in this very thread!) that you can't get people to (or people outright refuse to) download programs and run them if they're not delivered by Steam or similar. I've also very often heard people complain that ordinary users of web browsers will click anything and everything standing between them and what they want to do without either reading it or bothering to think about what they're doing it.
Given these two points, I'd argue that giving direct access to USB devices to any random website is (from a security standpoint) disastrous for the average user. A user who clicks the "Yes, give access to this USB device to 'website.com'" prompt is almost never going to intend to -say- flash the firmware on that device... and would almost never have any idea if it was or was not possible to do so.
If you even know what an ESP32 is, you can get a browser extension to use WebUSB. Very few users need this feature built-in, let alone enabled by default.
Maybe hasn't been done, but I agree with some of the other comments around here that if this were truly important, someone would've done it. Or at least if a browser is going to support it, it should only be enabled via some hidden dev setting.
> if this were truly important, someone would've done it
That's basically a variant of the efficient market hypothesis for open source software. I highly doubt it's accurate, for various reasons.
Things that people retrospectively consider absolutely essential and a no-brainer to prioritize get shipped years after the initial release of some software all the time.
In this case, it's probably because the alternatives are good enough, even if it's just that Firefox users open Chrome in specific instances where they want to connect to special hardware.
Tell me what "getting access to a device" exactly means? Is it reading some data, all data, changing some state, etc?
Compare that with an api that asks "Are you ok to disclose your location to example.com?" or "Do you allow example.com to send you notifications?". This is night and day.
> Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time, so I simply stopped using it (one of the reasons).
How many devices are you setting up per day?
I just can't imagine jettisoning Firefox for browsing the web because of webusb.
There are more than twice as many Linux desktop users than there are firefox users in total. People have left firefox for many reasons. The incompetence, user hostility, lack of principles, and technical lag are rampant and pervasive.
Even seemingly trivial missing features can push people to another browser if they're otherwise largely indifferent already.
I don't think it's unreasonable to assume that to some people, the inconvenience of juggling two browsers alone outweighs the benefits of using Firefox for most browsing.
Neither can I, but you know what I can imagine? Walking away from Firefox because it yet again shows it has no interest in being a strong browser for the only folks that actually use it, namely power users who care about privacy, security, and controlling their own browser experience while enabling them to make the coolest shit with the latest, cutting edge Web APIs.
"Leaving Firefox" because of WebUSB would be silly, but "finally leaving Firefox" because they refuse to add yet another thing that intersects with your interests? Absolutely. At some point you just have to go "this is an abusive relationship holding me back".
Precisely this. I've not even used WebUSB, but while reading this post, I was reminded of similar pain points with Firefox. I found myself thinking of what browser I could switch to while reading comments before finding this thread. I'm a long-time die-hard Firefox user as well.
I've been waiting years and years for service worker module support, and I am sure there are plenty of other things that are important and not being done so that's just one example
> power users who care about privacy, security, and controlling their own browser experience while enabling them to make the coolest shit with the latest, cutting edge Web APIs
I agree with this part entirely.
Except I don't consider WebUSB to be a "Web API", despite the name. And if it has any effect on privacy and security, it's a negative one.
My physical hardware becoming suddenly unprogrammable because the company hosting the flashing site went out of business isn’t okay. It should be a software that I can download and is not dependent on any external servers.
If the device depends on their servers to work in the first place, I love not having to download and trust the software though!
I want code running in a browser to stay in its sandbox, a large motivation for web apps in the first place is that they stay safely sandboxed and ephemeral. I think browsers accessing hardware is a terrible mistake, they make a terrible “OS” and trying to use the web as the default platform for all apps has set our industry back decades.
I like the sandboxing properties of my browser, and wish I could run as many of my local applications and utilities in it or in something comparable.
Part of that is being able to access hardware, and missing that functionality will expose data on my computer to malicious or compromised applications or scripts.
Hardware access obviously has to be on a very strict opt-in basis. For all the things Apple is regularly trailing behind other browsers or outright botching, I think letting only "installed PWAs" send push notifications and persist state more than 7 days between visits is directionally the right thing to do, and hardware access would be much less critical limited that way.
> I understand that WebKit lacks support since it’s developed by Apple
> But Firefox? Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time
A lot of accusations to simply say "I want Chrome-developed Chrome-only APIs to be called standard and implemented by everyone without any objections".
I'd read it more as "I don't particularly care about what ends up as the standard or who ends up writing it, I just wish that it's nearly as capable as the non-standard implementation that exists and is useful."
Mozilla's objection is to having the capability at all, on the basis of "USB devices are too easy to hack" and "users are too dumb to give informed consent, regardless of what we tell them". And GP's objection to Mozilla's objection ultimately comes down to having the capability or not.
Mozilla's objection, among others, isn't "users are too dumb to give informed consent, regardless of what we tell them".
It's "we have dozens of APIs that require user consent and it's nearly impossible to contain this barrage, or to make sure that users fully understand the implications of consent for the more complex APIs and integrations"
Why do people in these discussions pretend that it is only WebUSB that needs a permission and consent?
There’s also the possibility of social engineering that compounds with lack of technical understanding to produce some nasty results.
It’s been proven that many users will click “Allow” for just about any dialog when instructed to if a sufficiently juicy carrot is promised as a reward. With WebUSB this could easily result in hapless users’ phones and whatnot getting malware/spyware installed on them… elderly and kids seem particularly vulnerable.
Okay, fine, there are a few other proposals regarding information about or control over the local device that Mozilla disapproves of on similar grounds. But it still comes down to "We don't think users can ever understand the security risks involved with this kind of access", which I've abbreviated as "users are too dumb". You can argue that "they're not dumb, they're just human/inattentive/fatigued by warnings/whatever", but it still comes down to having the knowledge or not. (After all, if it were just "We don't want a single click to give immediate access", they could just make the prompt/warning harder to mindlessly click through.)
Of course, the alternative to the user getting a browser prompt to communicate with their USB device is for the user to download a program to communicate with their USB device. So if they're set on doing whatever they are attempting to do, then it's not like they can ever avoid the risk of threats they don't understand, since desktop sandboxing is still mostly nonexistent.
Stop projecting your own view of users on what Mozilla is saying.
> Of course, the alternative to the user getting a browser prompt to communicate with their USB device
It's amazing you write this literally after I wrote "Why do people in these discussions pretend that it is only WebUSB that needs a permission and consent?"
It's actually exasperating to see almost the same people go "oh yes, permission dialogs in Android are overly broad, and people just click yes without reading, yes cookie consent popups are annoying, people just click yes" and then turn around and say "how dare Firefox assume people are stupid to read and understand the consent popup for WebUSB (and WebHID, and WebSerial, and WebMIDI, and NFC, and Network Information, and Bluetooth, and Location, and FileSystem Access, and Camera, and generic sensors in general, and...)"
I’ve heard both opinions at the same time because they’re both true.
A technical audience will actually read prompts and understand what they’re consenting to. I, for one, actually read cookie prompts and will say no to as much as I can.
Most people don’t, and the number of people who don’t is growing, because we keep adding prompts.
It was basically built so password manager extensions could communicate with password manager apps to do things like yubikey support etc. before browsers started handling webauthn
Yes, I have done this for (a fraction of) WebBluetooth. Albeit the extension API does not make it easy, and i don't know if you can implement the entire Web* API surface, but at least it is good enough for proofs of concept.
Extension + a native program for the extension to talk to. The native program has to manage accessing the usb device and providing an interface to the browser extension.
But more generally you can just run webserver on 127.0.0.1 and interact with it from extension (although I didn't test this particular use-case, it works fine from website, but extension might have its own nuances).
The latter poses some security problems, though, which the native messaging API avoids (e.g. random websites being able to connect to the native application and pretending to be your extension).
> There’s a list of tools that now use the browser to set up devices, and it’s fantastic.
Honestly, I hate this trend. What happens when the company goes out of business and the web app you need to configure your hardware is taken down? A dedicated desktop app that doesn't have online dependencies is the only way to go.
I shouldn't need internet access to change the function layer on my keyboard.
As a Linux user I love WebMIDI, because it means I don't have to open a Windows VM anymore to run firmware updates / utility tools for audio gear manufacturers that embrace it (e.g. Novation).
WebUSB should enable the same for more types of devices, but of course there should be appropriate permission mechanisms.
That is/was a Chrome problem, Firefox only allows WebMIDI after granting permission. Unfortunately its implementation is also incomplete/buggy so I still often end up using Chrome for those use cases anyway.
Webmidi is godsent for Akai LPD8 controllers. It came with software that's used to reprogramming midi banks. Software never got updates and doesnt work anymore in any modern mac. Thank $deity for webmidi and some reverse engineering, i can reprogram it to a degree that its at least functional and dont need to throw it away.
The benefit to folks who flash devices frequently is obvious. However, joe user, the other 3 billion or so users couldn't care less. Poking holes in the sandbox for those folks is negligent at best.
Perhaps the solution is a separate tool, maybe just a separate browser, specifically for this use case?
Flash Browser, heck it could even come with additional tools to help do this. Preconfigured white or black lists, bookmarks to the most common flashing tools, reference material. Make it an even better experience than bolting webusb on to the browser raw.
While I can understand the drama and criticism surrounding the "standard", using it to flash GrapehenOS on Pixel phones has been one of the most pleasant, easy and fast OS installations experiences i ever had on any device. Literally plug, click and play.
> encrypts the private key with the "master" key, and returns the encrypted private key as the key handle
wow. I guess that does work.
I feel like giving an adversary infinite opportunity to try and decrypt the private key in their possession will backfire eventually, but what do I know?
It's exactly as risky as any other possible stateless authenticator implementation, if you think about it.
For example, another way of doing it is to derive the private key from the key handle via deterministic key derivation – which the attacker can brute-force just as well as the encrypted per-site key stored in the key handle.
The key insight is that a stateless authenticator is by definition globally (i.e. across secrets and sites) deterministic, and given an input-output pair, you'll be able to brute-force its internal secret. The solution is to make that internal state large enough for that to be computationally infeasible.
WebUSB is not a web standard. It’s a Blink-only API cooked up by Google and rejected by both Mozilla and Apple on privacy and security grounds. It cannot become a web standard without two independent implementations, and Google have failed to convince anybody outside of Google to implement it. Nevertheless, it pops up on various websites as things Firefox and Safari are “failing” to support.
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
> WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.
> 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.
You are not losing functionality if it was never implemented in the first place.
WebUSB and WebSerial are not standards, so your rage is misdirected. Keep using your security cheese of a browser if you need that feature. Otherwise others (like myself) are okay with having fewer security risks in their browsers.
I don't know the general political disagreements, but I personally don't want WebUSB and think it's a garbage idea.
The browser can already access the USB devices it needs through normal OS interfaces (the keyboard and mouse being the obvious examples). I don't see why any website should need special direct access. The only use-cases seem to be giving access to web programmers who can't be bothered to write a standalone application (not a group I trust) or to provide additional ways to track users (something I don't want).
I don't even trust Google and Mozilla enough to give them access, much less any random stranger who's setup a website.
Not everything needs to be accessible from the web. I don't know where the line is, but for me USB access is across the line.
> I don't see why any website should need special direct access.
And this also holds back things like better security from USB security keys.
You have to access the key in exactly the way that is implemented ... even if that implementation sucks or has bugs or has security failures.
Everybody hates Electron .. but then want to hamstring the browsers. Well, people still want do do the thing they want even if you don't let them. They will find a way around .. and currently that way around is Electron.
I believe USB security keys are covered under a different API.
But even then, you can use this argument against it. When this type of USB access is allowed, it gives phishing attacks even more power. Now, you’ll click prompts for authentication and little did you know that malicious actors and read/write the entire USB drive!
The politics of exposing users to security issues VS giving the web more capabilities.
A fight which is usually won by people who just want features now. Security flaws tend to look hypothetical until people actually exploit them in the wild.
If history teaches us anything, it's the fact that we will come full circle, the browser will become the os at some point. People with money want it to happen and they have resources to make us think that we want it too. Might as well enjoy the ride
Fingerprinting, basically, and whether browsers should gain any more capabilities at this point which just deepens the dependency on Chrome further and further.
While fingerprinting is a concern with many web extensions, the bigger problem here is the security risks inherent in exposing on the open internet a bunch of USB devices that were not designed with adversarial inputs in mind...
As I user who cares deeply about privacy and has almost everything enabled -- "strict" anti tracking protection on the browser, uBlock origin, DNS level filtering etc -- I discovered that any the fingerprint for my Firefox is pretty much unique on the entire Internet.
One thing that astonished me was that the number of hardware cores of my CPU is easily accessible from JavaScript. I have an AMD machine with 8 cores and 16 threads. Somehow it is on the high end of machines that access the Internet, and only a small fraction of users have a 8 core CPU. Combined with just a few other parameters, especially IP address, it is easy to uniquely identify this computer.
Just one additional channel of information from WebUSB barely matters at all.
About fingerprinting - was the WebUSB made poorly? I believe the device information can be strictly restricted and given only on user consent. E.g. by default browser sees only plugged-in status of certain device categories.
I don't think, I wrote enough code with those APIs.
You call `navigator.usb.requestDevice({filters})`. It returns a promise and browser displays a window with device list according to the given filter. User chooses device or presses "cancel". The promise resolves with single device or rejects with error. You can't fingerprint anything without user interaction. Also there's block list which does not allow to connect to keyboard, mouse, so typical user does not even have any USB devices to choose from.
should a browser have api-s allowing websites to access directly the file system and usb devices which might be insecure and help in fingerprinting or it should not. a.k.a chrome against all the ants.
It already does though. It's the type=upload box we've had for decades. Think of it as how smartphones let you give access to only a specific file or see a subset of files. The "UI" is just using a system control. You can also drag and drop files into the browser too. This is all available to javascript.
It doesn't. Websites don't have access to your file system.
> It's the type=upload box we've had for decades.
It isn't. That isn't giving the access to your file system to a website. That is simply providing a file to a website. The website doesn't even get the real path to the file but a C:\fakepath\filename.
> You can also drag and drop files into the browser too. This is all available to javascript.
Again, that is not giving access to your filesystem to a website. That is giving a file to a website.
I do agree partially but I don't see a difference in practice
Using your definition every app on Android and Apple doesn't have access to your filesystem either.
Just like you have to select which image from your camera roll that Facebook is allowed to see / access. It gets that one image, and only that image, on purpose. It doesn't get to have a free for all through your files.
In this case, Safari also doesn't implement the API, and that's far from an ant. Plenty of cases where something is effectively everywhere but in Firefox, but this time Apple also decided against it.
Maybe I'm just in the minority, I just don't see what purpose this serves.
Besides my mouse, I just don't have anything that uses USB. My phone generally isn't connected, I've not needed a USB drive in years and I struggle to think of a situation where I have a product that uses USB that I need to use my laptop for but also don't want the software controlling it installed on that laptop.
This is a good point that tends to get drowned out by the severe privacy and security concerns. WebUSB provides zero value to the overwhelming majority of end users, and minimal value to the handful of us who have ever used it at all.
That's not true at all, flashing ESP32 devices has been made WAAAAAY easier with WebUSB than before. Many keyboards have stopped requiring installing third-party software/drivers to customize them after WebUSB became a thing. The benefits are huge.
While that shows a good use case for a minority, it doesn't refute at all “zero benefit to the overwhelming majority of end users”. Most end users don't have configurable keyboards, and even less program microcontrollers.
This is why it is contentious: On the one hand you have a great QoL benefits for a minority of users who are more than willing to accept the potential fingerprinting risk and consider other dangers to be overblown hypotheticals, or are technical enough to mitigate those issues. On the other you have the vast majority who have no need of the feature at all, and are probably unaware of any risk and will be until it becomes apparent in a can't-be-undone manner. Google sides with the former, Firefox and Apple err the other way. At what point a small potential risk for everybody is worth QoL benefits for a relative few, is the main point of contention (the second largest probably being a mix of “is the risk really a risk anyway?” or “but you'll be fingerprinted to buggery & back anyway so what difference does this bit-or-few of data really make?”).
A side issue is the concern about the browser becoming a bloated almost-but-not-quite full OS, and a huge mess that needs much effort to maintain to keep its growing attack surface defended.
Besides making flashing esp32 devices easy there is also another niche use-case for webusb and that is Web MiniDisc; keeping those recorders alive long past manufacturing EOL.
To a relatively small group of enthusiasts, sure. I'd love to see numbers on the percentage of browser-users who own keyboards which require regular firmware updates..,
Who cares about what the plebs do? By that logic extension support should be removed from browsers outright, since extensions are just used by a small group of enthusiasts.
This is effectively part of Google's official argument for making ad blocking more difficult (the unofficial argument being that they actively don't care if ad blocking is more difficult, for obvious reasons).
The use cases for extensions cover a much larger segment of browser users than programmable keyboards and microcontrollers though: there is a lot more mass appeal for things like languagetool/grammarly, ad-blockers and other page tidiers, tools that are useful for devs¹, and so forth.
--------
[1] I'd put money on even the vast majority of front-end devs not touching microcontrollers or having programmable keyboards.
I fail to see what is gained to flash ESP32 from the browser vs from a small software gui you can run on your computer (and offline as well).
Saving the 1 minute setup time needed to install the software ? The rest is basically the same procedure.
When developers create Electon apps, HN complains about it. When developers then use web serial to avoid having to install Electron apps, HN complains about it.
And before anyone says “just write a native app”, let me know how many small businesses you run where you can afford to employ developers to create and manage multiple apps across platforms?
Maybe you struggle to imagine uses for USB because you "just don't have anything that uses USB". You could just as easily argue that USB itself shouldn't exist using that logic. And you'd be just as wrong.
A while back I was setting up some LD2410 radar sensors. Of course the shitty Chinese level of support is a shady exe that only runs on Windows.
Then I found this: https://github.com/albertnis/ld2410-configurator which did the job by just doing the whole process in a browser. I was really amazed that this was even a thing at the time, and it's certainly a great way to do multiplatform serial interfaces.
I have so much shitty desktop software that could easily be a web app. The steelseries software that manages my usb headset, the crappy Garmin app that connects to my watch, my Corsair keyboard software, that awful Logitech management software, etc.
This entire thread is a symptom of the lack of interest and stagnation of desktop software APIs. Does the Logitech mouse software need to consume 1GB of RAM so I can map a button? Of course not, but Logitech chose that approach because I dunno, trying to write a simple Cocoa app for Mac was too hard, made their brains hurt, so the complex job of “sending predefined configuration parameters in hex over Bluetooth” turns into “ship a small web browser because web devs are cheap as chips and wRiTe OnCE RuN eVeRyWhErE”
GP is lamenting the apps ship an entire self-contained, often outdated, browser one must run and update separately for each app because they are desktop apps. Web apps just run as a page in your browser like any other site. Not everyone who has an issue with a former has an issue with the latter.
Web apps don't have to only be sourced from a live hosted website, though that is a particularly convenient way to grab them (or just temporarily use them without installing as a PWA instead). https://github.com/pwa-builder/PWABuilder
Up until ~5 years ago, hacking U2F to make it pass (smuggle?) arbitrary data was exactly how hardware wallet like those from Ledger and Trezor were communicating with websites and web extensions (like Metamask), for the lack of a better alternative.
This is how hardware secured "web3" came to be.
This is the reason I don't use firefox and opt for Edge instead. Mozilla's ridiculous stance on WebUSB, WebSerial and other web-forward tech is bizarre. It shuts out a huge hobbyist community and diminishes web as a platform.
Couldnt we add some "usb descriptor flag" which says whether WebUSB should be allowed or not? Then firefox/chrome would not need to maintain a blocklist.
Wow, U2F already encapsulates its protocol messages in USB HID messages for compatibility, as far as I understand – so now we can encapsulate arbitrary protocols in U2F messages?
Quick summary.
Firefox does not support talking to arbitrary USB devices (whereas Chrome has WebUSB to do that). However, Firefox does support talking to U2F security keys over USB.
This project programmed a microcontroller to pretend to be a U2F security key. The goal was to talk to the microcontroller over USB through Firefox.
They use the Javascript Credentials APIs (https://developer.mozilla.org/en-US/docs/Web/API/Credential_...) and some cleverness to send data to and receive responses from the microcontroller.
Yes, this isn't for accessing arbitrary devices. It can be used to build custom devices that can be used by webpages without any consent prompts though.
But possibly this MCU's firmware can be expanded to serve a WebUSB lookalike of sorts?
so if I understood it right, Firefox is vulnerable to the problem they wanted to avoid but without giving us WebUSB?
No, because the device they are accessing needs to be specifically built for this use case. So you would need to give the user a malicious device then use a malicious webpage. The attack scenario isn't impossible, but is far less then those that are possible with WebUSB.
While not impossible, I just can't think of a good reason why you'd need them to access a malicious webpage when you've already gotten them to install a malicious device.
No, USB is vulnerable to malicious devices.
If you have a keyboard with QMK/Via firmware, customising it with WebUSB is a nightmare.
You essentially have to make one of your /dev/hidraw devices completely world readable (inviting all sorts of keylogging shenanigans) before the browser can interact with the firmware.
Its creepy beyond creepy in terms of usage, and offline customization tools are all Electron based so there's not much advantage.
One reasonable workaround is to construct your desired keyboard layout with a template json file on the website, download the resulting json and then flash the firmware to your keyboard via sudo-level flashing tool.
Still, I wish there was a less creepy way.
> download the resulting json and then flash the firmware to your keyboard via sudo-level flashing tool
Several microcontrollers come pre-shipped with MicroPython and an emulated flash drive where you can drop Python code to alter the running main()
I imagine you could easily do the same with keyboards, except the FS throws an error when you're writing invalid JSON and the emulated FS has emulated security properties so only admin users can write to it. No need to sudo, just authorise the permission prompt when you download/copy the new config to the virtual flash drive.
You could add a little hardware button or toggle switch to the board to enable/disable flash drive emulation if you really wanted to be secure. Write your config, unmount, flip toggle switch.
> Still, I wish there was a less creepy way.
There should be - there's three LEDs (capslock, numlock and I forget the third one) on standard keyboards which can all be set from the OS side... and at least caps lock (I think!) can be set from Javascript, so it's essentially an 1 bit wide communications bus, three bits if it's an ordinary OS tool.
I think the third is scroll lock [1].
That one feels quite legacy to me, every time I active it it's by accident and I don't understand why stuff is behaving weirdly.
[1]: https://en.wikipedia.org/wiki/Scroll_Lock
I love scroll lock still existing on keyboards. Some operating systems still use it to control text scroll for some reason (useful when you don't have `screen` installed maybe?), but I mostly use it for toggles in video games. It shows the toggle state on a physical interface, like one of those fancy programmable macro keyboards, but on commodity hardware!
I believe there are still a number of applications where Scroll Lock is useful, most notably Microsoft Excel.
how so?
With ScrLk off, the arrow keys move the cursor (active cell). With it on, the arrow keys scroll the window contents instead.
(I believe this is actually the original purpose of ScrLk, but most applications these days don’t use it.)
That functionality would actually be useful in all sorts of games, but that's probably a lost cause at this point. We've settled on other paradigms.
You can't manipulate capslock state from JS.
I can’t just set any key to output the unicode character I want. I know there are some Linux only hacks, but it would be nice to do in a standard way.
This is a little confused. The idea behind the permissions model is that the browser suite is responsible for mediating access to the hardware. Obviously, yes, you need to give it access to the hardware in the first place for it to do that. If you don't trust the browser as a manager of a hardware abstraction layer, that's fine. But that's the model that Via expects. I don't see how it's any more "creepy" than letting your browser read your camera or microphone or storage.
I can go to https://usevia.app on a locked down employer-managed chromebook and hit my QMK keyboard with no trouble whatsoever. And needless to say I can't touch the /dev nodes at all on this box.
Because the browser interacts with my camera/mic through specific media APIs that don't allow it to flash the firmware.
Uh... you can't "flash firmware" via USB HID. WebUSB in fact does not allow raw access to arbitrary devices, it works with specific defined protocols.
Sorry, you're right. I guess it allows you to just change settings. Still, its unclear what those settings constitute, and how easily a keylogger could be embedded there.
QMK is open source keyboard firmware. Obviously yes, you can install a keylogger. You can't download one via a web app.
> and offline customization tools are all Electron based so there's not much advantage.
Afaik it's only any Via support per se that the keyboard firmware has allowing for such on the fly customization, rather than QMK. With QMK it's all manual flashing (I was somewhat surprised that it was easier than I was expecting to customize the layout/layers/lights with code though, largely thanks to the supportive community).
If you're looking for a QMK alternative to Via, I recommend you try using QMK Configurator and QMK Toolbox. The combination is not as ergonomic as Via, but at least you get a graphical keymap editor that compiles firmware and is far less bloated. The experience has been good with my Keeb.io boards.
Yep, this is my current workflow -- not the easiest, but the one I trust the most
I own Keychron devices with QMK firmware, and Brave (Chromium) is really explicitly communicating whenever the keyboard is being configured. I have also installed GrapheneOS using it, & honestly I cannot imagine getting tricked into launching a keylogger that way. I already trust Keychron and GrapheneOS to some extent so the point is moot, I think.
what are you talking about? I have to approve the website before it can access my devices via WebUSB. What's the actual issue / path for keylogging etc. there, care to explain instead of fearmongering?
The browser itself shouldn't have access to raw devices, as that means giving all programs running under your user the ability to flash your keyboard firmware.
The point of flatpak, wayland, etc is to prevent software from having access to everything. Making all USB devices readable and writable again circumvents the entire sandboxing concept of modern systems.
Windows and macOS allow access to USB devices for user programs. Linux by default does not allow access to USB devices, you need to chmod corresponding pseudo-file in /dev (or write udev rule to make it happen automatically). So when one uses WebUSB (or any other usb software) without root, it won't work immediately.
Modern Linux systems are more complex than that. E.g. if I plug in a USB drive and one of its partitions has permissions
I can still mount it even though I am not root or in the disk group. Why? Because many Linux desktops/apps can use polkit to get elevated access if a set of policy rules allow them to do so. E.g. there is typically a policy for udisks that allows clients in active sessions to mount filesystems.Similarly, I can use fwupd to update the firmware of my machine without ever becoming root, but as a user I certainly don't have the device permissions to do it. So how? The system has a policy rule that says that every active, local user that is in the wheel group can run an update. The fwupd daemon that runs as root will then execute the update for the user.
What group does the browser run in. Surely it's the same group as the user, and has the same wheel privileges, no?
Being in the wheel group is not enough to write to the relevant device nodes. At any rate, my point was that device permissions and UID/GIDs alone do not determine whether a user or application can write to the device. Higher privileges can be mediated through polkit.
Missing the point entirely. You must still enable USB support from the site before it can see or interact with anything.
It has nothing to do with sites. You are missing the point. To access USB device with Linux, any software, including browser, should have permission to access certain files in /dev.
You visit a page. It asks for device access. You get a dialog box choosing the device that matches the filter the site wants. You can either choose a device or decline. Site does not see anything other than what you approve.
What is difficult about understanding that?
You're the one missing the forest for the trees. The security risk is not caused by websites, but by the fact that the browser can access your USB devices in the first place.
By giving the browser access to your USB devices, the browser could act as a keylogger even when you're using other applications.
Further, as there's no proper way to sandbox this, you wouldn't just be giving the browser keylogging capabilities, but any native app running under your user.
> The security risk is not caused by websites, but by the fact that the browser can access your USB devices in the first place.
Then you'd better uninstall your browser, because this is already the case right now.
The fact that Chrome makes use of that capability and Firefox does not constitute a privilege/security boundary.
On security focused distros, it obviously works in neither browser right now, because it's a fucking stupid idea.
You could have an elevated service that has separate configuration for which devices the user wants to grant access to, and it could even work as a proxy to disallow "bad" usage patterns. The interface to USB devices doesn't need to be directly with the kernel.
It's true though that it's difficult to ensure only a certain process has access to it, though the default value set to ptrace_scope by e.g. Ubuntu is a step towards helping that.. But in principle the service can know which executable is issuing the request.
All in all this seems quite a big effort for perhaps not that great benefit. In the meanwhile I'll be using Chromium for WebSerial and WebUSB needs.
Except the browser can't even see the device if it's even a vaguely secure operating system.
taking this from vial website
``` export USER_GID=`id -g`; sudo --preserve-env=USER_GID sh -c 'echo "KERNEL==\"hidraw\", SUBSYSTEM==\"hidraw\", ATTRS{serial}==\"vial:f64c2b3c*\", MODE=\"0660\", GROUP=\"$USER_GID\", TAG+=\"uaccess\", TAG+=\"udev-acl\"" > /etc/udev/rules.d/99-vial.rules && udevadm control --reload && udevadm trigger' ```
so that means the device can be read and written by the user and group, but not by others.
Yeah I have this udev rule, it fails to trigger properly and I think it might be because of what it thinks the user group and the web browser group is. I haven't fully debugged it, but I can tell you that this does not work for me
If you're on reasonably updated distribution, setting the GROUP in the udev rule might be causing issues. The [uaccess way][0] is to just set the TAG.
The Arch Wiki also has this note:> For any rule adding the uaccess tag to be effective, the name of the file it is defined in has to lexically precede /usr/lib/udev/rules.d/73-seat-late.rules.
If your application is running as a different user, or in a Flatpak or snap, you may need some additional or alternative configuration.
[0]: https://wiki.archlinux.org/title/Udev#Allowing_regular_users...
Oh thanks for this
i'm just guessing here but maybe only chrome is asking that. if the malware is another program, no confirmation is required?
This comment section is a fascinating mix of people who use WebUSB talking about how great it is and people who don’t use WebUSB being confused about why anyone would want it.
In my experience it’s been great. Most of the WebUSB utilities I use are also available as self-installed apps, but I use them so infrequently that it’s much easier to use the web version than to go through the process of installing an update and using the app. It’s also one less app I have to install.
I would have expected this to be popular with the people who are tired of having an app for every different thing.
Yeah, except that someday the site that provide that useful app may be gone once and for all, while the app would remain just fine until you uninstall it. So it's a double-edged sword.
The app they make would probably be Internet enabled with electron so… prolly also won’t work
> may be gone once and for all
...and the domain taken over by a scammer who puts up a fake app that does unspeakable things to your USB device.
> does unspeakable things to your USB device
Taken out of context (and meaning), this sounds kinda naughty! :D
Everything is a double-edged sword - even a single-edged sword.
I‘m more concerned about security by giving a webbrowser too much access to local resources.
Convenience and security don’t fit together
Yeah but if I need to talk to a local device, I trust browser's security far more than a random vendor's native app. I recently bought a keyboard that allows remapping keys; the vendor has both a native app and a web app to do it: I trusted the web app far more.
So you don’t trust the vendor. Maybe using their hardware isn’t a good idea in the first place.
I think browsers are the bigger target and they provide the much bigger attack vector given that the purpose is being connected to the internet.
Using an internet tool to access local resources is using the wrong tool for the job.
Maybe I'll believe you when desktop operating systems have a mature and easy-to-use sandbox for local apps. Any random local app by default having access to ~/.ssh/id_rsa no attack required is a much bigger threat for me to worry about than thinking a web app might attack my browser to steal data belonging to a different origin.
MacOS already has this for at least 5 years: https://support.apple.com/guide/security/controlling-app-acc...
What good is a sandbox if you're just going to punch holes through it.
What about supply chain attacks?
Do you know if your trusted web app fell for one?
That's irrelevant. Both local apps and web apps are subject to supply chain attacks. The difference is that a local app that has had a supply chain attack carried out can read my documents, my private keys, my photos, etc; a web app that has similarly malicious code cannot do any of that. The browser protects me because it has a sandbox.
I also do not understand why you refer to "trusted web app" whereas in my comment above I have stated that I need a sandbox to run the code; I clearly don't trust it enough. The whole point is that the browser allows me to run untrusted code safely. And supply chain attack is one of the main reasons why I don't trust it enough.
Web apps have a magnitude more dependencies than desktop apps. A lot bigger attack vector.
>I also do not understand why you refer to "trusted web app" whereas in my comment above I have stated that I need a sandbox to run the code
Because you referred to apps stealing code from a different origin. I talk about the app you use to access the usb device per web usb.
Previously it was about a malicious app attacking per browser exploit.
This tine the app is allowed to access the data but because of the supply chain attacks your data gets stolen.
> Web apps have a magnitude more dependencies than desktop apps
Irrelevant. As a user I do not care how many dependencies an app has. I care about my own data security and browsers have an excellent sandbox.
> Because you referred to apps stealing code from a different origin
I referred to apps stealing data from a different origin. Think my open web mail tab containing my email. That's an attack that browsers can prevent.
> I talk about the app you use to access the usb device per web usb.
That's what is supposed to happen. I explicitly want this vendor app to talk to vendor hardware.
> Previously it was about a malicious app attacking per browser exploit.
A malicious web app needs a browser exploit to access my data which costs millions of dollars on the black market. A local app does not need any exploit to access my data.
> the app is allowed to access the data but because of the supply chain attacks your data gets stolen
The app is never allowed to access my data. It doesn't matter whether supply chain attacks are involved or not.
Run it as another user or put it in a less privileged cgroup. Problem solved.
That's what I currently do but it's not easy to do at all. For one, there's no simple and built-in way to copy my desktop user settings to the new user. For two, when you switch to a new user, you can't simultaneously do things as the original user in the same desktop session.
"Using an internet tool to access local resources is using the wrong tool for the job."
Browser technology stopped being internet tech only quite a while ago.
It might not have been the best idea, but that's where we are. So my first choice would nowdays also be webusb if possible.
> Browser technology stopped being internet tech only quite a while ago.
That was already a bad idea.
> It might not have been the best idea, but that's where we are.
You aren’t forced to use it for local resources.
No I am not forced to use it, but since the web is my usual tech stack, I likely will just use that, if I ever have to connect to a USB device.
If you write code ok, but what about third party apps.
Supply chain attacks are quite common.
Agreed. Therefore I use niether webUSB or vendor apps but rather use hardware that works with openocd and open source tooling.
Almost as if we've got some kind of notification that asks you if you want to give a browser access to a certain device huh?
Because browser never have bugs.
If a web browser has a sufficient bug to allow access to webusb without permission in an exploitable way, it's probably also exploitable enough that even without webusb you'd have hardware access via RCE.
I've used WebUSB to flash an Android device before. Yes, it's useful and easy, but it's also ripe for vulnerabilities. Web bloat needs to stop growing. The browser should not be a kitchen sink for anything anybody in tech wants. Installing a native application is not that hard.
Example: Purchasing shipping labels, and using a scale to weigh the physical items. (Technically that's HID not USB, but similar idea.)
A bit OT, but most of this thread seems to be generally about WebUSB, not the OP (although it is a pretty cool hack!)
On one hand, I really want WebUSB, but at the same time, I REALLY don't want the average person to have WebUSB.
Practice has shown that consent popups do not work and people will manage to give consent to anything without even realizing it ("I never clicked on anything", they say, while I swipe away 50 spam push notifications and remove push permissions from about a dozen "news" sites).
Honestly, I kind of like the Internet Explorer version of permissions, where you needed to mark certain sites as "trusted" to enable certain features. The process is hard to discover, takes a decent amount of time, is a bit confusing, done in a system-styled modal popup with reasonably scary and large warning icons.
If people had to go through this process to mark a site as "trusted" in order to use WebUSB, WebBluetooth, and the other dangerous APIs, far fewer would do it by accident. The UX would still be better than installing a native app and you get sandoxing as a bonus, so I think the tradeoff would be worth it.
Chrome Web Notifications are also a complete dumpster-fire. In my experience the average older folk has no idea what web notifications are. They accidentally enable notifications from shady websites over time, and then blindly believe the web-spam notifications being pushed to their phone informing them *HELLO YOUR PHONE HAS VIRUS DOWNLOAD "CLEANER APP" TO FIX BEFORE PHONE DIE* is legit.
> On one hand, I really want WebUSB, but at the same time, I REALLY don't want the average person to have WebUSB.
This is the endless struggle of all time. It's like some people have some sort of super-messing-things-up power. If you don't make something LITERALLY impossible to achieve, they will find a way to do it by accident. Always. They will go out of their way to find things to do by complete accident, and they will never have any idea what they're doing! They'll follow guides to change settings they don't understand, trigger functionality they don't understand, grant access they don't understand, no matter how complex you try to make the process, no matter how many warnings you add, and no matter how hard you try to guard against exactly this kind of idiocy.
And this sucks. Because there are people out there who do know what they're doing, who do things on purpose, and who would appreciate to have power that it just so happens that an Idiot should never be given. It is practically not possible to expose that power without being flooded by Idiots who did something Stupid with it.
I agree. One of the biggest things people don't understand is that most users simply don't understand what they're doing, and Google does not understand how to design software safe for them. Annoying processes seem pointless but often they have a very clear point: Making sure intent is solid.
Apple recently implemented some web APIs in a strategy that shows they actually understand designing for people: The APIs only work if you "install" the website. It makes it possible to access useful PWA features... but it doesn't allow any arbitrary website to do so, there's an extra process normal humans understand to enable it.
An installed PWA is also persistently visible: It's on the homescreen. So it's a visible reminder of that permission grant and a clear sign of something a user wants to have some sense of access to them.
> Google does not understand how to design software safe for them
The only way to design software safe for Idiots is to design software where it is not possible to make a mistake, not possible to have an accident, and not possible to compromise anything even on purpose.
Unfortunately, non-Idiots don't tend to appreciate that kind of babyfied experience, so we tend to end up with some compromise where the things that Idiots will inevitably mess up should ideally be the least consequential possible things that can also provide some sort of value to non-Idiots.
As a result some of the more advanced experiences that are entirely inappropriate to grant Idiots are simply not available, because if they were, then Idiots would find a way to cause really bad accidents.
> On one hand, I really want WebUSB, but at the same time, I REALLY don't want the average person to have WebUSB.
I really do want the general public to have access.
Many people need to interface with devices and we are sadly in a situation where Apps served by closed App Store are the only option.
If I want to distribute a way to allow the wider public to access a device that no longer has official support, WebUSB is by far the easiest way.
In an alternative world where Chrome did not support it, the average person would need to be able to install and run [python or other scripting language].
If the developer was really keen then they might offer a desktop app or go through the long and expensive process of submitting it to an App Store.
I think WebUSB can have a secure UI and I also can’t think what devices the average user has plugged in that could be compromised. I am pretty sure you can’t use WebUSB to take control of a keyboard or mouse (HID), storage, wifi, audio, smart card of U2F devices.
But it’s super useful for proprietary label printers, random toys/gadgets and programming/flashing microcontrollers.
Modal prompts where applications (and websites!) request permissions are an absolutely terrible UX. Sure, they're very easy to use and convenient, but they're easy to use to accidentally grant very wide access to untrustworthy third parties.
Granting permission to pages should be, as you say, an explicit user-initiated flow via a permissions panel. The same should be so for sandboxed desktop applications. Does an application want to continuously record your screen? Then it should be granted this permission explicitly via a permissions control panel. It shouldn't be able to show a modal dialogue where people just click "yes". Many times, with good reason: they simply don't understand the technicalities of what they're being asked.
USB Serial is such a great thing, finally ending those annoying Electron apps that are only used for one thing. There’s a list of tools that now use the browser to set up devices, and it’s fantastic.
ESPHome(+ hundreds projects that use it as a base), Betaflight, ELRS, Flipper just to name a few.
I understand that WebKit lacks support since it’s developed by Apple, and I would also be cautious if it granted any access to peripherals.
But Firefox? Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time, so I simply stopped using it (one of the reasons). Reason they state for not adding support it is that user consent is not enough to access the device, which is just nonsense, they could have made it enabled under the developer flag or similar. Blink proved that it can be made secure.
I have a filling they are stubborn for no reason and are not seeing use cases that would make their browser usable.
https://developer.mozilla.org/en-US/docs/Web/API/Serial
https://mozilla.github.io/standards-positions/
> Reason they state for not adding support it is that user consent is not enough to access the device, which is just nonsense,
There was a kinda major security issue [1] where malicious websites used WebUSB to access FIDO/U2F keys.
This was bad because U2F credentials are supposed to be impossible to phish, as the browser's U2F API puts the domain name in the request to the token - but by using WebUSB, a site could request a token for any domain name.
And as both U2F and WebUSB popped up quite similar looking user consent boxes, it's pretty much impossible to avoid some users getting confused.
Google's solution, believe it or not, was to blocklist a load of devices for WebUSB [2] - so now anyone making U2F devices has to get Google to add every new product they release to the blocklist.
Everyone loves the fact the browser is a secure sandbox, letting users run untrusted code. I don't get why people want to poke so many holes in the sandbox.
[1] https://www.yubico.com/support/security-advisories/ysa-2018-... [2] https://github.com/WICG/webusb/blob/main/blocklist.txt
> Everyone loves the fact the browser is a secure sandbox, letting users run untrusted code. I don't get why people want to poke so many holes in the sandbox.
My thoughts precisely. I want browsers to be welding holes shut, not opening new ones.
I’d think differently if user consent were required to load any scripts past a certain complexity threshold (e.g. if they’re heavier than that of an early-mid 00s website, hold off on execution until the user approves), but with how easily users can be taken to sites they never asked to go to every added bit of deep system integration a browser gains is a massive liability. The web is too built up around the idea of implied consent to be doing anything too fancy.
If you weld my front door shut, I'm going to be upset with you.
"But welding your front door shut doesn't bother me at all."
Yeah, that's the problem right there.
What's the front door, WebUSB or something else like TLS 1.2?
I thought WebUSB required you to explicitly select a USB device from a list to allow the web page to connect to it?
It does. Mozilla doesn't trust users to not be manipulated by malicious websites into doing so against their own interests. At GP link 2, Mozilla writes their rationale for concluding that WebUSB is bad:
> 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.
Personally, I'd be happy enough with an implementation of WebUSB that only worked with websites accessed over localhost or on the local network. I want to write data over USB to ESP32s and Teensys 3D printers and so on through an integrated local webserver.
localhost-only access is a reasonable compromise
Right. The attack is:
1. You intend to log into an (evil) website using your Yubikey U2F token.
2. A popup appears that looks like this: https://developer.chrome.com/docs/capabilities/usb#get_acces... saying the website wants to connect to your Yubikey.
3. You click 'allow' because you do want the website to access your Yubikey. Then you press the button on the Yubikey when the light starts flashing, because that's what you do.
4. Your unphishable credential just got phished.
Ah that dialog is very ambiguous. I hope they changed it...
yeah, this sounds to me like apparently some people think once again computer owners can't be trusted to grant a permission to anything because some clueless people can be tricked into shooting themselves in the foot.
IMHO I don't buy that this is worth nerfing everything. Without using the exact analogy from the above metaphor, what if we banned cooking appliances, because a bad actor might call people and trick them into turning the stove up to "High" and placing a roll of paper towels on the flame?
I use the WebUSB to manage my keyboard's configuration, and that popup is hard to misconstrue. Also what is even the overlap between users of USB security keys (the main attractive USB target I saw cited) and people who click mindlessly without reading anything?
Take a look at this browser popup box, asking the user to select which device to use for webauthn: https://filestore.community.support.microsoft.com/api/images...
Now take a look at this browser popup box, inviting the user to grant access for webusb: https://developer.chrome.com/docs/capabilities/usb#get_acces...
This isn't just clueless people clicking mindlessly without reading anything. The user wants to log in with their U2F key. They get a box asking if the website can access their U2F key.
Even if they read and understand every word in the box, consult their security training (which tells them "when you log in with a U2F key a box will pop up asking you to select a device, that's normal") the only indication they're doing anything wrong is that the device selection box looks a bit different to normal.
> I don't get why people want to poke so many holes in the sandbox.
Because what's a sandbox to you is an universal API layer to some.
Imagine if those devices used proper USB descriptors/classes instead of generic HID device.
Google should've asked me first, cause just seeing the name WebUSB, I said "wtf why is this even a thing, absolutely no."
Wait until you find out about WebBluetooth
At least I'm a little relieved that Firefox and Safari don't support that either.
Wait until you find out about WebWifi
I'm just waiting for someone to compile Chromium to WASM, giving us WebWeb.
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.
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.)
> 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.
> 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.
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.
[dead]
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.
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?
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.
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 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.
Yes, and they run with kernel level permissions.
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.
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...
Even a lot of reasonably tech-savvy people might not know the difference between the WebUSB consent popup and the security key popup.
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.
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.
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.
>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.
> I have a filling they are stubborn for no reason and are not seeing use cases that would make their browser usable.
This is untrue. Privacy and security issues have been raised. Web Serial is not a web standard and cannot become one until Mozilla or Apple sees these issues resolved. Google cannot make this into a web standard unilaterally; standards need consensus.
Here is the Mozilla discussion: https://github.com/mozilla/standards-positions/issues/336
And here is the WebKit discussion: https://github.com/WebKit/standards-positions/issues/199
I don't exactly understand the privacy and security implications here.
A website can prompt for precise location at any point. A website can prompt me to provide a certificate with my cryptographically proven identity at any point. A website can PROMPT for XYZ at any point.
Why should WebUSB be treated any different. If I give access to a device, I give access to a device. If I don't, they can't touch or identify it.
Because explaining exactly what can happen when you grant WebUSB access is not as clear as with a geolocation prompt. You can't get meaningful consent from users - not all prompts are equal.
But this is obviously not a solvable problem.
The whole objective of WebUSB is to not generalize it. Meaning in theory someone could, if you explicitly allow access to a device, reflash your ESP32 with a HID mouse device that automatically uploads a sensitive file to the attacker.
But if the user was going to do this anyways (flash some unvetted binary to their device), the web still provides MORE security than having the user download flasher.exe + badbinary.elf
> But if the user was going to do this anyways (flash some unvetted binary to their device), the web still provides MORE security than having the user download flasher.exe + badbinary.elf
I've very very often heard people complain (even some in this very thread!) that you can't get people to (or people outright refuse to) download programs and run them if they're not delivered by Steam or similar. I've also very often heard people complain that ordinary users of web browsers will click anything and everything standing between them and what they want to do without either reading it or bothering to think about what they're doing it.
Given these two points, I'd argue that giving direct access to USB devices to any random website is (from a security standpoint) disastrous for the average user. A user who clicks the "Yes, give access to this USB device to 'website.com'" prompt is almost never going to intend to -say- flash the firmware on that device... and would almost never have any idea if it was or was not possible to do so.
Relatedly; apparently even Google has locked down WebUSB because it substantially weakened client security: <https://news.ycombinator.com/item?id=43362586>.
If you even know what an ESP32 is, you can get a browser extension to use WebUSB. Very few users need this feature built-in, let alone enabled by default.
Can I really, in Firefox? This seems like something that's impossible to provide via the Web Extension API.
It's supposedly doable: https://news.ycombinator.com/item?id=43361159
Maybe hasn't been done, but I agree with some of the other comments around here that if this were truly important, someone would've done it. Or at least if a browser is going to support it, it should only be enabled via some hidden dev setting.
> if this were truly important, someone would've done it
That's basically a variant of the efficient market hypothesis for open source software. I highly doubt it's accurate, for various reasons.
Things that people retrospectively consider absolutely essential and a no-brainer to prioritize get shipped years after the initial release of some software all the time.
In this case, it's probably because the alternatives are good enough, even if it's just that Firefox users open Chrome in specific instances where they want to connect to special hardware.
What are you basing that on? What makes granting access to a device so much more difficult to explain than any other permission?
Tell me what "getting access to a device" exactly means? Is it reading some data, all data, changing some state, etc?
Compare that with an api that asks "Are you ok to disclose your location to example.com?" or "Do you allow example.com to send you notifications?". This is night and day.
These seem like the same level of “thing” to ask of a user, I have no clue what you think the fundamental distinction is
> Google cannot make this into a web standard unilaterally
At their market share, what's the downside to them of something remaining Chrome proprietary forever?
> Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time, so I simply stopped using it (one of the reasons).
How many devices are you setting up per day?
I just can't imagine jettisoning Firefox for browsing the web because of webusb.
There are more than twice as many Linux desktop users than there are firefox users in total. People have left firefox for many reasons. The incompetence, user hostility, lack of principles, and technical lag are rampant and pervasive.
Even seemingly trivial missing features can push people to another browser if they're otherwise largely indifferent already.
I don't think it's unreasonable to assume that to some people, the inconvenience of juggling two browsers alone outweighs the benefits of using Firefox for most browsing.
Neither can I, but you know what I can imagine? Walking away from Firefox because it yet again shows it has no interest in being a strong browser for the only folks that actually use it, namely power users who care about privacy, security, and controlling their own browser experience while enabling them to make the coolest shit with the latest, cutting edge Web APIs.
"Leaving Firefox" because of WebUSB would be silly, but "finally leaving Firefox" because they refuse to add yet another thing that intersects with your interests? Absolutely. At some point you just have to go "this is an abusive relationship holding me back".
Precisely this. I've not even used WebUSB, but while reading this post, I was reminded of similar pain points with Firefox. I found myself thinking of what browser I could switch to while reading comments before finding this thread. I'm a long-time die-hard Firefox user as well.
I've been waiting years and years for service worker module support, and I am sure there are plenty of other things that are important and not being done so that's just one example
> power users who care about privacy, security, and controlling their own browser experience while enabling them to make the coolest shit with the latest, cutting edge Web APIs
I agree with this part entirely.
Except I don't consider WebUSB to be a "Web API", despite the name. And if it has any effect on privacy and security, it's a negative one.
My physical hardware becoming suddenly unprogrammable because the company hosting the flashing site went out of business isn’t okay. It should be a software that I can download and is not dependent on any external servers.
If the device depends on their servers to work in the first place, I love not having to download and trust the software though!
It's not an either-or thing. Every case of WebUSB flashing I've seen also offers an open source CLI tool you can pull down and use instead.
Perhaps because WebUSB is not well supported? Just a hypothesis, but pushing it as a standard might encourage it to become an either-or thing.
Many of the WebUSB flashing tools work fine offline, so one can just save the web page locally and use it that way.
I want code running in a browser to stay in its sandbox, a large motivation for web apps in the first place is that they stay safely sandboxed and ephemeral. I think browsers accessing hardware is a terrible mistake, they make a terrible “OS” and trying to use the web as the default platform for all apps has set our industry back decades.
I like the sandboxing properties of my browser, and wish I could run as many of my local applications and utilities in it or in something comparable.
Part of that is being able to access hardware, and missing that functionality will expose data on my computer to malicious or compromised applications or scripts.
Hardware access obviously has to be on a very strict opt-in basis. For all the things Apple is regularly trailing behind other browsers or outright botching, I think letting only "installed PWAs" send push notifications and persist state more than 7 days between visits is directionally the right thing to do, and hardware access would be much less critical limited that way.
> I understand that WebKit lacks support since it’s developed by Apple
> But Firefox? Firefox has severely lacked support for hardware "connections" and has been unfriendly for developers for a long time
A lot of accusations to simply say "I want Chrome-developed Chrome-only APIs to be called standard and implemented by everyone without any objections".
I'd read it more as "I don't particularly care about what ends up as the standard or who ends up writing it, I just wish that it's nearly as capable as the non-standard implementation that exists and is useful."
Mozilla's objection is to having the capability at all, on the basis of "USB devices are too easy to hack" and "users are too dumb to give informed consent, regardless of what we tell them". And GP's objection to Mozilla's objection ultimately comes down to having the capability or not.
Mozilla's objection, among others, isn't "users are too dumb to give informed consent, regardless of what we tell them".
It's "we have dozens of APIs that require user consent and it's nearly impossible to contain this barrage, or to make sure that users fully understand the implications of consent for the more complex APIs and integrations"
Why do people in these discussions pretend that it is only WebUSB that needs a permission and consent?
There’s also the possibility of social engineering that compounds with lack of technical understanding to produce some nasty results.
It’s been proven that many users will click “Allow” for just about any dialog when instructed to if a sufficiently juicy carrot is promised as a reward. With WebUSB this could easily result in hapless users’ phones and whatnot getting malware/spyware installed on them… elderly and kids seem particularly vulnerable.
> Why do people in these discussions pretend that it is only WebUSB that needs a permission and consent?
It's not only WebUSB that requires user permission, but it is only USB/serial access where Mozilla has decided that a permission prompt is inadequate.
> but it is only USB/serial access where Mozilla has decided that a permission prompt is inadequate.
No, it's not.
Okay, fine, there are a few other proposals regarding information about or control over the local device that Mozilla disapproves of on similar grounds. But it still comes down to "We don't think users can ever understand the security risks involved with this kind of access", which I've abbreviated as "users are too dumb". You can argue that "they're not dumb, they're just human/inattentive/fatigued by warnings/whatever", but it still comes down to having the knowledge or not. (After all, if it were just "We don't want a single click to give immediate access", they could just make the prompt/warning harder to mindlessly click through.)
Of course, the alternative to the user getting a browser prompt to communicate with their USB device is for the user to download a program to communicate with their USB device. So if they're set on doing whatever they are attempting to do, then it's not like they can ever avoid the risk of threats they don't understand, since desktop sandboxing is still mostly nonexistent.
Stop projecting your own view of users on what Mozilla is saying.
> Of course, the alternative to the user getting a browser prompt to communicate with their USB device
It's amazing you write this literally after I wrote "Why do people in these discussions pretend that it is only WebUSB that needs a permission and consent?"
I have the answer here: https://news.ycombinator.com/item?id=43363010
That sounds the same to me, just a bit nicer articulated.
No, it's not the same.
It's actually exasperating to see almost the same people go "oh yes, permission dialogs in Android are overly broad, and people just click yes without reading, yes cookie consent popups are annoying, people just click yes" and then turn around and say "how dare Firefox assume people are stupid to read and understand the consent popup for WebUSB (and WebHID, and WebSerial, and WebMIDI, and NFC, and Network Information, and Bluetooth, and Location, and FileSystem Access, and Camera, and generic sensors in general, and...)"
Are those people in the room with us and can you point at any that hold both opinions at once?
I’ve heard both opinions at the same time because they’re both true.
A technical audience will actually read prompts and understand what they’re consenting to. I, for one, actually read cookie prompts and will say no to as much as I can.
Most people don’t, and the number of people who don’t is growing, because we keep adding prompts.
Could've learned to use DD in the time it took to make this post.
Web browsers need to remain incapable of... formatting my disks
It should be easy to fix that with browser extension and small native program. Nobody wrote this yet?
Wait, under what circumstances are browser extensions allowed to communicate with anything outside the browser?
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
It was basically built so password manager extensions could communicate with password manager apps to do things like yubikey support etc. before browsers started handling webauthn
Oh wow, this is cool. Yep this would make USB Serial work on Firefox with a simple extension.
Yes, I have done this for (a fraction of) WebBluetooth. Albeit the extension API does not make it easy, and i don't know if you can implement the entire Web* API surface, but at least it is good enough for proofs of concept.
Extension + a native program for the extension to talk to. The native program has to manage accessing the usb device and providing an interface to the browser extension.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
But more generally you can just run webserver on 127.0.0.1 and interact with it from extension (although I didn't test this particular use-case, it works fine from website, but extension might have its own nuances).
The latter poses some security problems, though, which the native messaging API avoids (e.g. random websites being able to connect to the native application and pretending to be your extension).
When random websites connect to your application, you can (and should) inspect Referer header and filter out unwanted ones.
> There’s a list of tools that now use the browser to set up devices, and it’s fantastic.
Honestly, I hate this trend. What happens when the company goes out of business and the web app you need to configure your hardware is taken down? A dedicated desktop app that doesn't have online dependencies is the only way to go.
I shouldn't need internet access to change the function layer on my keyboard.
Maybe it’s a good thing USB ports are not available to browser based code.
As a Linux user I love WebMIDI, because it means I don't have to open a Windows VM anymore to run firmware updates / utility tools for audio gear manufacturers that embrace it (e.g. Novation).
WebUSB should enable the same for more types of devices, but of course there should be appropriate permission mechanisms.
WebMIDI has been used by porn sites to track users:
https://news.ycombinator.com/item?id=23679063
That is/was a Chrome problem, Firefox only allows WebMIDI after granting permission. Unfortunately its implementation is also incomplete/buggy so I still often end up using Chrome for those use cases anyway.
As I understand it, it was because WebMIDI was accepted by Chrome without prompting the user.
To me it seems should be impossible use it for tracking after they added the prompt.
Whenever the committe crams another desktop features into the browser you can be sure it is mainly convenience and surveillance!
Webmidi is godsent for Akai LPD8 controllers. It came with software that's used to reprogramming midi banks. Software never got updates and doesnt work anymore in any modern mac. Thank $deity for webmidi and some reverse engineering, i can reprogram it to a degree that its at least functional and dont need to throw it away.
Why does that require a browser and not software you run natively?
No, it's not.
The benefit to folks who flash devices frequently is obvious. However, joe user, the other 3 billion or so users couldn't care less. Poking holes in the sandbox for those folks is negligent at best.
Perhaps the solution is a separate tool, maybe just a separate browser, specifically for this use case?
Flash Browser, heck it could even come with additional tools to help do this. Preconfigured white or black lists, bookmarks to the most common flashing tools, reference material. Make it an even better experience than bolting webusb on to the browser raw.
While I can understand the drama and criticism surrounding the "standard", using it to flash GrapehenOS on Pixel phones has been one of the most pleasant, easy and fast OS installations experiences i ever had on any device. Literally plug, click and play.
> encrypts the private key with the "master" key, and returns the encrypted private key as the key handle
wow. I guess that does work.
I feel like giving an adversary infinite opportunity to try and decrypt the private key in their possession will backfire eventually, but what do I know?
It's exactly as risky as any other possible stateless authenticator implementation, if you think about it.
For example, another way of doing it is to derive the private key from the key handle via deterministic key derivation – which the attacker can brute-force just as well as the encrypted per-site key stored in the key handle.
The key insight is that a stateless authenticator is by definition globally (i.e. across secrets and sites) deterministic, and given an input-output pair, you'll be able to brute-force its internal secret. The solution is to make that internal state large enough for that to be computationally infeasible.
[NSA with their multiple quantum computers has entered chat] /s
Good thing AES is quantum-safe, so quantum computers are completely irrelevant when it comes to symmetric key wrapping.
> WebUSB and its associated political disagreements
What are the political disagreements?
WebUSB is not a web standard. It’s a Blink-only API cooked up by Google and rejected by both Mozilla and Apple on privacy and security grounds. It cannot become a web standard without two independent implementations, and Google have failed to convince anybody outside of Google to implement it. Nevertheless, it pops up on various websites as things Firefox and Safari are “failing” to support.
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
— https://wicg.github.io/webusb/
> WebKit declined to implement several APIs, including WebUSB, due to concerns over fingerprinting
> We have previously stated privacy concerns, thus the concerns: privacy label. We agree with Mozilla's security concerns raised in their standards position issue, thus the concerns: security label.
— https://github.com/WebKit/standards-positions/issues/68
> 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
[flagged]
Real adults use lynx & curl, so I’m not sure what adults you’re talking about.
You are not losing functionality if it was never implemented in the first place. WebUSB and WebSerial are not standards, so your rage is misdirected. Keep using your security cheese of a browser if you need that feature. Otherwise others (like myself) are okay with having fewer security risks in their browsers.
I don't know the general political disagreements, but I personally don't want WebUSB and think it's a garbage idea.
The browser can already access the USB devices it needs through normal OS interfaces (the keyboard and mouse being the obvious examples). I don't see why any website should need special direct access. The only use-cases seem to be giving access to web programmers who can't be bothered to write a standalone application (not a group I trust) or to provide additional ways to track users (something I don't want).
I don't even trust Google and Mozilla enough to give them access, much less any random stranger who's setup a website.
Not everything needs to be accessible from the web. I don't know where the line is, but for me USB access is across the line.
> I don't see why any website should need special direct access.
And this also holds back things like better security from USB security keys.
You have to access the key in exactly the way that is implemented ... even if that implementation sucks or has bugs or has security failures.
Everybody hates Electron .. but then want to hamstring the browsers. Well, people still want do do the thing they want even if you don't let them. They will find a way around .. and currently that way around is Electron.
I believe USB security keys are covered under a different API.
But even then, you can use this argument against it. When this type of USB access is allowed, it gives phishing attacks even more power. Now, you’ll click prompts for authentication and little did you know that malicious actors and read/write the entire USB drive!
The politics of exposing users to security issues VS giving the web more capabilities.
A fight which is usually won by people who just want features now. Security flaws tend to look hypothetical until people actually exploit them in the wild.
If history teaches us anything, it's the fact that we will come full circle, the browser will become the os at some point. People with money want it to happen and they have resources to make us think that we want it too. Might as well enjoy the ride
Fingerprinting, basically, and whether browsers should gain any more capabilities at this point which just deepens the dependency on Chrome further and further.
While fingerprinting is a concern with many web extensions, the bigger problem here is the security risks inherent in exposing on the open internet a bunch of USB devices that were not designed with adversarial inputs in mind...
I think you're right. Weren't there even remote DMA/CPU-level attacks over OHCI/USB?
I think that ship sailed many years ago.
As I user who cares deeply about privacy and has almost everything enabled -- "strict" anti tracking protection on the browser, uBlock origin, DNS level filtering etc -- I discovered that any the fingerprint for my Firefox is pretty much unique on the entire Internet.
One thing that astonished me was that the number of hardware cores of my CPU is easily accessible from JavaScript. I have an AMD machine with 8 cores and 16 threads. Somehow it is on the high end of machines that access the Internet, and only a small fraction of users have a 8 core CPU. Combined with just a few other parameters, especially IP address, it is easy to uniquely identify this computer.
Just one additional channel of information from WebUSB barely matters at all.
About fingerprinting - was the WebUSB made poorly? I believe the device information can be strictly restricted and given only on user consent. E.g. by default browser sees only plugged-in status of certain device categories.
You don't see anything without user consent.
It works like that or you think it should work like that?
If browser gets zero information, it drastically reduces UX. It even does not know to suggest permission popups without being misleading in the end.
I don't think, I wrote enough code with those APIs.
You call `navigator.usb.requestDevice({filters})`. It returns a promise and browser displays a window with device list according to the given filter. User chooses device or presses "cancel". The promise resolves with single device or rejects with error. You can't fingerprint anything without user interaction. Also there's block list which does not allow to connect to keyboard, mouse, so typical user does not even have any USB devices to choose from.
probably that your browser can access the hardware. which i also do not want.
should a browser have api-s allowing websites to access directly the file system and usb devices which might be insecure and help in fingerprinting or it should not. a.k.a chrome against all the ants.
It already does though. It's the type=upload box we've had for decades. Think of it as how smartphones let you give access to only a specific file or see a subset of files. The "UI" is just using a system control. You can also drag and drop files into the browser too. This is all available to javascript.
> It already does though.
It doesn't. Websites don't have access to your file system.
> It's the type=upload box we've had for decades.
It isn't. That isn't giving the access to your file system to a website. That is simply providing a file to a website. The website doesn't even get the real path to the file but a C:\fakepath\filename.
> You can also drag and drop files into the browser too. This is all available to javascript.
Again, that is not giving access to your filesystem to a website. That is giving a file to a website.
I do agree partially but I don't see a difference in practice Using your definition every app on Android and Apple doesn't have access to your filesystem either.
Just like you have to select which image from your camera roll that Facebook is allowed to see / access. It gets that one image, and only that image, on purpose. It doesn't get to have a free for all through your files.
In this case, Safari also doesn't implement the API, and that's far from an ant. Plenty of cases where something is effectively everywhere but in Firefox, but this time Apple also decided against it.
Safari is an ant standing on the shoulders of a giant apple.
Maybe I'm just in the minority, I just don't see what purpose this serves.
Besides my mouse, I just don't have anything that uses USB. My phone generally isn't connected, I've not needed a USB drive in years and I struggle to think of a situation where I have a product that uses USB that I need to use my laptop for but also don't want the software controlling it installed on that laptop.
This is a good point that tends to get drowned out by the severe privacy and security concerns. WebUSB provides zero value to the overwhelming majority of end users, and minimal value to the handful of us who have ever used it at all.
That's not true at all, flashing ESP32 devices has been made WAAAAAY easier with WebUSB than before. Many keyboards have stopped requiring installing third-party software/drivers to customize them after WebUSB became a thing. The benefits are huge.
While that shows a good use case for a minority, it doesn't refute at all “zero benefit to the overwhelming majority of end users”. Most end users don't have configurable keyboards, and even less program microcontrollers.
This is why it is contentious: On the one hand you have a great QoL benefits for a minority of users who are more than willing to accept the potential fingerprinting risk and consider other dangers to be overblown hypotheticals, or are technical enough to mitigate those issues. On the other you have the vast majority who have no need of the feature at all, and are probably unaware of any risk and will be until it becomes apparent in a can't-be-undone manner. Google sides with the former, Firefox and Apple err the other way. At what point a small potential risk for everybody is worth QoL benefits for a relative few, is the main point of contention (the second largest probably being a mix of “is the risk really a risk anyway?” or “but you'll be fingerprinted to buggery & back anyway so what difference does this bit-or-few of data really make?”).
A side issue is the concern about the browser becoming a bloated almost-but-not-quite full OS, and a huge mess that needs much effort to maintain to keep its growing attack surface defended.
Besides making flashing esp32 devices easy there is also another niche use-case for webusb and that is Web MiniDisc; keeping those recorders alive long past manufacturing EOL.
- https://web.minidisc.wiki/
> The benefits are huge
To a relatively small group of enthusiasts, sure. I'd love to see numbers on the percentage of browser-users who own keyboards which require regular firmware updates..,
Who cares about what the plebs do? By that logic extension support should be removed from browsers outright, since extensions are just used by a small group of enthusiasts.
This is effectively part of Google's official argument for making ad blocking more difficult (the unofficial argument being that they actively don't care if ad blocking is more difficult, for obvious reasons).
The use cases for extensions cover a much larger segment of browser users than programmable keyboards and microcontrollers though: there is a lot more mass appeal for things like languagetool/grammarly, ad-blockers and other page tidiers, tools that are useful for devs¹, and so forth.
--------
[1] I'd put money on even the vast majority of front-end devs not touching microcontrollers or having programmable keyboards.
> Who cares about what the plebs do?
Pretty much everyone involved in the security and usability of the internet.
Enthusiasts will find ways to accomplish what they want to regardless of whether there's an easy browser-based path.
> Who cares about what the plebs do?
Blink, WebKit, and Gecko devs probably.
I fail to see what is gained to flash ESP32 from the browser vs from a small software gui you can run on your computer (and offline as well). Saving the 1 minute setup time needed to install the software ? The rest is basically the same procedure.
When developers create Electon apps, HN complains about it. When developers then use web serial to avoid having to install Electron apps, HN complains about it.
And before anyone says “just write a native app”, let me know how many small businesses you run where you can afford to employ developers to create and manage multiple apps across platforms?
Don't be daft. There are plenty of comments for and against. HN consists of multiple people.
Maybe you struggle to imagine uses for USB because you "just don't have anything that uses USB". You could just as easily argue that USB itself shouldn't exist using that logic. And you'd be just as wrong.
A while back I was setting up some LD2410 radar sensors. Of course the shitty Chinese level of support is a shady exe that only runs on Windows.
Then I found this: https://github.com/albertnis/ld2410-configurator which did the job by just doing the whole process in a browser. I was really amazed that this was even a thing at the time, and it's certainly a great way to do multiplatform serial interfaces.
Google unlocking the Stadia controllers via a website was nice.
Seems like an artificial problem though.
Better than an exe I think
I have so much shitty desktop software that could easily be a web app. The steelseries software that manages my usb headset, the crappy Garmin app that connects to my watch, my Corsair keyboard software, that awful Logitech management software, etc.
Odds are those shitty apps are web apps.
This entire thread is a symptom of the lack of interest and stagnation of desktop software APIs. Does the Logitech mouse software need to consume 1GB of RAM so I can map a button? Of course not, but Logitech chose that approach because I dunno, trying to write a simple Cocoa app for Mac was too hard, made their brains hurt, so the complex job of “sending predefined configuration parameters in hex over Bluetooth” turns into “ship a small web browser because web devs are cheap as chips and wRiTe OnCE RuN eVeRyWhErE”
GP is lamenting the apps ship an entire self-contained, often outdated, browser one must run and update separately for each app because they are desktop apps. Web apps just run as a page in your browser like any other site. Not everyone who has an issue with a former has an issue with the latter.
So, I suppose you would prefer to not use your Logitech mouse on macOS?
If you don't make cross-platform feasible, you will wind up with Windows support only.
Great, they are now websites. What happens if they decide to no longer host them in two years?
Web apps don't have to only be sourced from a live hosted website, though that is a particularly convenient way to grab them (or just temporarily use them without installing as a PWA instead). https://github.com/pwa-builder/PWABuilder
This is nothing new.
Up until ~5 years ago, hacking U2F to make it pass (smuggle?) arbitrary data was exactly how hardware wallet like those from Ledger and Trezor were communicating with websites and web extensions (like Metamask), for the lack of a better alternative. This is how hardware secured "web3" came to be.
This is the reason I don't use firefox and opt for Edge instead. Mozilla's ridiculous stance on WebUSB, WebSerial and other web-forward tech is bizarre. It shuts out a huge hobbyist community and diminishes web as a platform.
Meanwhile, the other half of Hacker News community complains web browsers have too many features and want go back to Web 1.0.
The classic balancing act between minimizing attack surface vs "if it can't be used, it can't be abused."
Or a classic selfish "I don't use it so noone else should have it".
That's just 75% of HN or rather "privacy-focused" tech enthusiasts.
The remaining 25% hide under the disguise of generic security "concern" that usually involves tangential topic.
Case in point:
A: WebUSB has privacy risk, it can fingerprint you.
B: But it already require user consent.
C: ProcesD to pontificate about good user consent UX.
Web Bluetooth and the File System API are among other APIs not supported by Firefox.
Exactly... making Photopea's UX worse.
"I want to make cool things without thinking about how doing so will make users dangerously unsafe"
Go make cool things. But you need to remember that thing you think is cool isn't safe for everyone to play with. Don't shove your trash onto others.
A few years back I wrote a WebSerial/WebUSB app for fun - https://web-serial-app.netlify.app/
It still throws a 'Blue screen of Death' for Firefox
A web browser is a tool to download HTML documents and render them for reading.
Javascript is a language to add animation to those documents.
Couldnt we add some "usb descriptor flag" which says whether WebUSB should be allowed or not? Then firefox/chrome would not need to maintain a blocklist.
Isn't this similar to why most people turn off UPnP on their routers and other similar devices, for security reasons?
Why can't webusb be implemented as an extension using a native messaging host?
Another way (I think) is to emulate a USB headset and play/listen to data encoded in audio
Wow, U2F already encapsulates its protocol messages in USB HID messages for compatibility, as far as I understand – so now we can encapsulate arbitrary protocols in U2F messages?
Beautiful. I hate it. But I also love it.
pretty sweet
[dead]