What are some interesting uses of WebUSB you have come across?
The stadia controller bluetooth firmware unlocker was the first time I experienced WebUSB
https://stadia.google.com/controller/index_en_US.html
Today I discovered the VIA project can configure my QMK keyboards
Both of these implementations worked perfectly on my framework Chromebook. What are some other cool examples folks have seen?
100 comments
[ 9.7 ms ] story [ 191 ms ] threadhttps://grapheneos.org/install/web
as well. I don't use Android anymore, but it's seriously cool that you can reflash the OS from a webpage.
Eg. https://config.openppg.com
On the USB device you can implement the WebUSB descriptor to link to your own website. This will give a notification on your desktop to open your website.
More info here: https://web.dev/build-for-webusb/
(Also you can write your own fw)
https://activation.nreal.ai/en/nreal-air-upgrade-plus.html
https://usefulangle.com/web-updates/post/80/firefox-decines-...
I assume this is because of security concerns.
To be fair I'm still exploring it, once you choose a USB device when prompted, is that access for the session or longer?
The idea is that your browser can mediate and scope access to specific devices. There are some edge cases where Web USB is equally as dangerous as the status quo, but in the common case it is far better and never worse.
The situation today is you buy a random USB gadget (e.g. a fitness tracker), but you can't use it without also installing the accompanying software/drivers. That effectively gives the manufacturer complete control of your computer. All you really wanted was for them to sync your step count, but you have no option but to give them complete remote access to your computer.
With Web USB you can allow vendor.com to access device 1234:5678 only, and revoke that access whenever you like.
Sure, maybe you could be tricked into clicking through all the confirmations and granting https://fakevendor.com access to a device. That could be bad - but no worse (and probably a lot better) than being tricked into downloading and running fakedriver.exe.
(disclaimer: I work for Google, have nothing to do with Chrome)
It's crucially important that Googlers are divorced of the belief a permission popup on the top of the screen is adequate indication of intent/informed consent. People approve these all the time without understanding what it's for.
Installing software is, at minimum, a very distinct action which users are aware of doing. Generally, they install a limited number of applications for specific purposes, whereas they may visit literally thousands of websites a month. Pretending these two things can be interchangeable is silly.
I am not entirely opposed to being able to use a browser as the UI for an activity like this, but it should require a higher bar to activate it for a specific server to talk to a specific device. Even web extension installs remain far too easy to not be maliciously abused widely. (Chrome extensions remain the primary malware I see in the wild.)
EDIT: The HN gods have me rate limited so hopefully you'll see my response here to the below comment:
Installing software is a complex process. It entails navigating to the correct site, locating a download, fishing it out of the downloads bar (many seniors cannot find this, by the way, it absolutely baffles them), opening it, usually acknowledging that you know it's an executable program, and then navigating the install wizard.
A software engineer would reasonably believe simplifying this is a good thing, but as noted, people regularly accept malware into their browser and do not even consciously realize they did it because it involves a single click.
People absolutely get misled into installing bad software, but they always know they actually did it, it's impossible to follow that chain without having some idea you're doing something.
Accepting malware isn't the answer, understanding people is. There is no technical solution for security, because it's a human problem.
Malware is a huge ongoing problem, which suggests this distinction doesn't really exist.
I think we have to accept that there is no way to perfectly eliminate social engineering without also locking down legitimate access to devices. There will be some percentage of users who will click through all the warnings and confirmation prompts, just like there is some percentage of users that will run malware. That's bad, but you're letting the perfect be the enemy of the good.
Your argument could also apply to ssh, a small number of users could be socially engineered into sharing their id_rsa. This happens, we often find them checked into github, for example. Does this mean we should go back to telnet? No, for the vast majority of cases ssh is a huge imperfect improvement.
Likewise, in the vast majority of cases, Web USB is a huge imperfect improvement over installing drivers.
This is a problem I have talked about many times before regarding Google's security outlook. On Project Zero there's a ton of interesting and surely exciting work into novel ways to compromise systems. ...That work has basically no bearing on improving security for the billions of users who will never be targeted in such a niche technical way.
Real world compromise tends to just be social engineering people into doing what Google explicitly permits websites to do. You could remove malicious activity from a billion users right now by simply... deleting the Notifications API from Chrome, which is principally used to spam ads. Because people mash that allow button all the time, every time.
I'd best guess I see ten times the malware in Chrome (either hijacker extensions delivered by the Chrome Web Store, push notifications from random adult websites, or both) than actual installed malicious software on a given Windows machine.
And this is fixable! Google could fix this with WebUSB and make a net positive all around! Likely by redesigning permission granting in the browser to require deeper user intent. But it would require a fundamental change in how Google understands and perceives security (and it'd likely reduce engagement stats for some features, which various teams would fight), and I've been beating this drum for several years and I don't really expect it to change.
(In fact, one specific change I could recommend: I think APIs like WebUSB, as well as the Notifications API and similar, should probably be completely blocked unless you install a PWA. It's not as much process as a Windows software install, but it's a clear gate to allowing a site more ability, and installing and removing apps is a far easier concept to explain to users than navigating the site privacy settings.)
We're not talking about any vulnerability here, this is social engineering. There is no amount of confirmation that can be required or warnings added that a confidence trickster cannot walk you through dismissing. The only solution is to limit what you're allowed to do with your own computer.
That's a really high price to pay.
WebUSB is new, non-standard, of course, and last time I tried it required feature flagging (it's saving grace... at the time). Compromises through extensions are probably more likely for a while, but WebUSB will probably be more exciting for persistence, considering you could flash an entire hardware device with malicious code, that the user has already demonstrated comfort connecting back to their PC.
It sure opened the door to a lot of scams, and was far from a perfect solution. Yet it does seem to have had a net positive effect. Maybe that can be true of other technologies sometimes :)
Let's leave it there, I don't think there's anything else to add.
> disclaimer: I work for Google, have nothing to do with Chrome
…depends on how you’re squinting.
You have to compare it to the options we have available today, not an implausibly perfect implementation that doesn't exist.
Let's imagine there is some bug that means if I grant access to a device, then more access than intended is actually granted. That sounds bad, but let's compare that to the non-Web USB model, where you have no option but granting unlimited unrestricted access to everything... now it doesn't sound so bad :)
Isn't "if you can find an 0day exploitable bug you can get access to everything" better than "You don't need a bug, because you already have access to everything"?
> …depends on how you’re squinting.
Umm, I know what I work on?
> Umm, I know what I work on?
As do I, and it would probably be more accurate to write "I work for Google, but not on Chrome".
Great, then you don't need to install anything or use Web USB, it's a no-op!
Still, until we can get Microsoft to ship every driver for every device, we still need a solution that works today.
> In that case I'm now using a browser where random websites can either trick me into giving them access to my USB devices with a click,
You can already be tricked into granting complete access to your machine with a few clicks, that's malware. It's a huge ongoing problem that can only be solved by limiting the ability to run third party code. That's a really high price to pay.
Sure, you could be socially engineered into granting an attacker access to a USB device. The only solution is to have no way for you to grant access to USB devices. There is no amount of confirmation or warning you couldn't be tricked into dismissing by a social engineer.
You will also need to uninstall Remote Desktop and OpenSSH, because you could also be socially engineered into configuring them to allow access. It's a common scam to trick people into downloading TeamViewer, so we will also need to remove your Administrator access and setup AppLocker with a strict policy.
> or forcefully access them via an exploit on a surface that is generally amenable to such things
That's not how it works. When a vulnerability is described as "arbitrary code execution", that means the code can do anything, not just access functionality that exists in the browser. If you were to use a browser without WebUSB support, an arbitrary code execution exploit would still be able to interact with USB devices.
The only added complexity here is after you've granted access to a device, otherwise the attack surface is entirely tractable.
You've posited effectively that if we cannot stop people from compromising their computer we should not bother to try. Either let them be owned with a trivial popup and a single press, or remove their agency entirely.
However, a better approach to security would be to take responsibility for designs that allow easy compromise, and build systems designed to drastically reduce the likelihood a user compromises their machines.
We can't stop people from finding a shady installer for a driver on a file sharing site hosted in Russia and running it, but we can make 99% of people less likely to do it with good design.
Sure, it's not a magic a wand that solves all problems, or makes malware disappear. I wish it did, but the fact that it doesn't is not a good reason to reject it.
It's deployed to billions of people globally, can you show me any evidence at all that there is any Web USB social engineering happening?
Immediately after WebUSB shipped in Chrome: "security researchers Markus Vervier and Michele Orrù detailed a method that exploits a new and obscure feature of Google's Chrome browser to potentially bypass the account protections of any victim using the Yubikey Neo".
The fact that fishing (and fingerprinting etc.) isn't reported widely doesn't mean it doesn't happen. After all you trust Chrome to properly implement everything and take care of things. And yet here's an example of a different hardware standard, WebMIDI: https://twitter.com/denschub/status/1582730985778556931 (note the comment: "Chrome still allows web developers to enumerate attached MIDI devices without user consent or even a notification")
In my opinion, the Chrome team overreacted and blocked all WebUSB access to any U2F/HID device.
Now if you want to update the firmware or configure your key you need to download an .exe and run it instead, which seems unfortunate to me.
If the phisher had said "Your U2F firmware is out of date, please download and run this update to continue", would that have been a vulnerability? That could also bypass 2FA (or anything else, for that matter).
That's still better than "just download and run this exe as Administrator".
I reject this way of thinking. Letting bad guys dictate how you live your life and how you use your computer just doesn't scale that well.
Sometimes they implement a seemingly innocuous API like WebMIDI, and boom, fingerprinting: https://twitter.com/denschub/status/1582730985778556931?s=20...
https://github.com/asivery/webminidisc
https://sle118.github.io/squeezelite-esp32-installer/
https://www.esphome.io/guides/getting_started_hassio.html
[1] https://github.com/Aircoookie/WLED
https://gist.github.com/alexanderson1993/5e280410dd10639555b...
For instance configure a thumb drive to be storage for a WebApp and the landing page is the WebApp itself. Is this this easily doable (as a file on the drive with WebUSB info) or would it require diving into the thumbdrive firmware itself.
I just wish that VIA was a bit more robust, particularly around macros... I want to do something that does separate key down and key up events with pauses between. Unfortunately, VIA doesn't do that. And worse, my keyboard (Keychron K3 Pro) doesn't yet have a public firmware build for QMK, so I can't do it directly in there either...
(I'm trying to write a macro for blanking the screen in macOS. Normally this is ctrl-shift-eject with eject held for a brief moment, but a macro of that rarely works from VIA. It needs a little delay at the end. If I add a no-op key to the end it then works, but also leaves ctrl and shift stuck down until I manually press each of them, which is no good.)
</digress>
My only gripe is that they moved to web-only from “native” apps instead of offering both, but if that’s what needed to happen to bump up the development velocity, so be it.
Re: the delays, I think I recently saw something about delays being possible in macros now, or perhaps soon — it might have been in QMK nightly, I can’t remember.
But I otherwise agree, it really does make things easy. I just wish it did a little bit more...
1: https://github.com/yume-chan/ya-webadb
It's amazing for students to be able to quickly get a program they've written in their browser onto a device in their hands that can respond to and interact with the real world.
Also great because with MicroPython and the Python Editor you get a standalone Python environment including REPL that's completely isolated from the PC - schools love it because no matter what the students do they're not going to break the host PCs.
(The firmware that implements web USB on the micro:bit's USB interface chip is open source, DAPLink https://github.com/ARMmbed/DAPLink)
But with WebUSB a page _can_ communicate directly to a yubikey and pretend it's being asked to authenticate on a different origin. It's been fixed now but it was an interesting bypass:
- https://www.yubico.com/support/issue-rating-system/security-...
- https://www.wired.com/story/chrome-yubikey-phishing-webusb/
You have no cash, no wallet, no cards, no phone, no yubikey, nothing.
There's a public library next door where you can use an internet terminal to log into your Google Voice and G-mail and send an e-mail for help or call your family without needing cash on hand. Those websites enforce 2FA, so this is the solution to that.
(I realize this breaks the premise of 2FA, but it will get you back safely, which is probably more important on your Maslow hierarchy than some infosec policy.)
What is the advantage of yubikey over TOTP in that scenario though?
Pretty wild first experience doing it for me - I'm used to the hassle of sideloading a bootloader and then flashing.