What are some interesting uses of WebUSB you have come across? | Hacker News Reader

What are some interesting uses of WebUSB you have come across?

101 pointsmoondev96 comments

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

https://www.usevia.app/

Both of these implementations worked perfectly on my framework Chromebook. What are some other cool examples folks have seen?

View on HN

The reason hardware 2fa keys like yubikeys are unphishable is that the browser controls the usb communication with the hardware key and passes the origin of the page to it - the page itself can't spoof an origin.

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/

Hmm this might not quite be WebUSB territory but it would be interesting to put a Yubikey in the cloud so it could be accessed from anywhere.

what is interesting about that, and what purpose would it serve?

If you're far away from home, get mugged, you have nothing left on your person, and you need to get help, what do you do?

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

I've written this comment before bu what you need is a remotely controlled finger for pressing YubiKeys: https://bert.org/2020/10/01/pressing-yubikeys/

This is hilarious. The “final thoughts” section really hit home for me. Thanks for sharing

Isn't that just like storing a PassKey in iCloud Keychain?

This gets us back to TOTP seeds in password managers. IMO that's a good model; physical stuff gets lost, broken, stolen, etc (hence one reason why you should not rely on SMS: It relies on a physical SIM card, and a physical device).

What is the advantage of yubikey over TOTP in that scenario though?

It's used for flashing the BBC micro:bit in both Microsoft MakeCode (https://makecode.microbit.org) and the micro:bit Python Editor (https://python.microbit.org). MakeCode uses it for lots of other devices like MakeCode Arcade too https://arcade.makecode.com )

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)

I was looking into Android phone hacking and was surprised to discover https://webadb.com/. It's a web equivalent of adb (Android Debug Bridge), which can install applications on a device connected over USB, among other things.

Very cool project but knowing how much access adb gives to your phone I wouldn't trust it unless you're self-hosting.

I've deployed an internal version of the upstream project (ya-webadb [1]) before. It can be built as a static site, and the upstream version publishes to GitHub pages, so it's really easy to self-host.

1: https://github.com/yume-chan/ya-webadb

GrapheneOS uses WebUSB to flash Pixel phones:

https://grapheneos.org/install/web

https://flash.android.com/

as well. I don't use Android anymore, but it's seriously cool that you can reflash the OS from a webpage.

Cool and kind of dangerous for nontechnical users tbh

Yep, WebUSB code for the curious: https://github.com/kdrag0n/fastboot.js

This is cool, but both safari and firefox will not implement it:

https://usefulangle.com/web-updates/post/80/firefox-decines-...

I assume this is because of security concerns.

Security or privacy (thumbprinting)?

To be fair I'm still exploring it, once you choose a USB device when prompted, is that access for the session or longer?

I think it might be session, but the issue is that most users simply accept permission popups, often without consciously recognizing they did. I've cleaned out the notifications permissions on browsers for dozens of people; all of them denied allowing various websites to spam them with notifications.

Am I alone in thinking even its Chrome implementation is a massive security risk? The fact that users can grant any webpage COMPLETE control of a USB attached device is astonishing. Live webpages shouldn't be able to access this feature - can't wait for fake jailbreak and backup services to start cropping up.

It's an incredibly bad idea, at work for the one Chromium browser we permit (Edge), we have to use policies to block this and several dozen major security vulnerabilities that exist solely because they make cool Google I/O demos.

Why is it a security vulnerability? I really want WebUSB to succeed, it could be a cross platform way to eliminate random executables from shady websites.

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)

I explain in a neighboring comment: https://news.ycombinator.com/item?id=34563795

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.

Why is installing software a distinct action, but granting device access not?

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.

So the issue is we are talking about different dimensions of improvement. I concede that WebUSB is better sandboxed than executing a driver installer (likely running as admin or root) in terms of the blast radius. However, WebUSB is catastrophically worse than an installer in terms of the ability of the infection to occur in the first place. Both because of the aforementioned difficulty of user process of software installation, as well as the additional checks the OS and/or third party antivirus does, as opposed to Google's fairly limited abuse detection capabilities (just Safe Browsing in WebUSB's case, I imagine?).

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

I think I need to see some data to back up your claim that Web USB makes socially engineering "catastrophically worse". Web USB is deployed today for a billion users, and yet attackers still seem to prefer malware or walking victims through installing TeamViewer, correct?

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.

Ah, but before they got tricked into TeamViewer, they were likely compromised once or twice over by Google: It's likely the link to the scammer's screen came from a Google ad that directed a user to a browser hijacking web extension, all of which has roughly the same level of difficulty as WebUSB. Then after that, a scammer may talk them through the process of downloading a RAT. (Though TeamViewer has not been popular for this in a while because they are responsive to security reports. There are some overseas-based tools which have taken over exclusively in the last few years because the developer doesn't answer their email.)

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.

Do you think you might have argued against the internet when it was being deployed?

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.

It depends on your threat model. “A trusted party ships high-quality drivers” is a good model but bundling it with the browser, where you run all sorts of code from third parties, can be difficult from the perspective of exposed attack surface. I would expect that someone in the position that ‘ocdtrekkie probably blocks installing random third-party drivers on those machines anyways, so now there’s new a way for websites to do funny things to connected devices at best and pwn your computer because the high-quality USB implementation wasn’t that high quality after all. (I’m putting aside the conversation about phishing people into granting those permissions, because that’s a completely different, difficult discussion.) Also,

> disclaimer: I work for Google, have nothing to do with Chrome

…depends on how you’re squinting.

> pwn your computer because the high-quality USB implementation wasn’t that high quality after all.

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?

I think we're talking past each other. If the two alternatives are "I need to use a random native USB driver to talk to this" and "I can use WebUSB" then WebUSB is probably better. But in reality a lot of devices actually already have drivers for that class in the OS, or there's a way to write some sort of restricted driver on that platform doesn't require loading things into the kernel. 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, or forcefully access them via an exploit on a surface that is generally amenable to such things. Put another way, I see WebUSB as being an attempt at writing userspace USB drivers by doing it in Chrome instead of the OS, and considering the entire point of using Chrome is so people can run code on your device it might be better to actually not put this capability here.

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

> But in reality a lot of devices actually already have drivers for that class in the OS

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.

This is a technical view, not a human-centric view. There is absolutely a level of warnings that will generally work. Not always, but I've found a number of people in the process of being socially engineered trip up on the UAC prompt and become more suspicious, to the point of booting a scammer out of their PC... and calling me. Likely because of the full-screen effect design and the short, but relatively scary language of the prompt.

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.

Web USB can realistically improve security for billions of people globally. It will improve security for me and my family, and we're all humans.

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?

https://www.wired.com/story/chrome-yubikey-phishing-webusb/

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")

The attack here was that if you get tricked into giving a phishing site your password and Web USB access to your U2F key and then you press your U2F key, then the attacker can bypass the 2FA. I highly doubt this ever happened in real life, it was just a proof of concept.

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 is a trivial phishing path. In fact, the phishing site could easily justify that process as being required for security! "We need access to your YubiKey to use it to sign you in" seems extremely plausible.

Assuming security is a well implemented "first class citizen" and not an afterthought, yes…

Let's assume it's an absolute trash fire, the latest of all afterthoughts.

That's still better than "just download and run this exe as Administrator".

So because a few bad actors might abuse it, and some users will fall into the traps laid for them, none of us get to use it.

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.

systems that allow such brazen exploitation cease to exist, so who cares about scalability?

Do they cease to exist because of gatekeepers, criminals, or both?

It should be an opt-in feature behind browser flag or only available for enterprise users IMO.

That article is from 2020…

Nothing has changed. Both Safari and Firefox are against most hardware APIs for reasons of security and privacy.

Sometimes they implement a seemingly innocuous API like WebMIDI, and boom, fingerprinting: https://twitter.com/denschub/status/1582730985778556931?s=20...

Web MiniDisc:

https://github.com/asivery/webminidisc

This definitely wins for me, a full easy to use management software to convert and burn or copy music off minidiscs (something that wasn't possible before digitally on most decks), it's very cool. This is the direct link to it running: https://web.minidisc.wiki/

VIA, as you mentioned, is one of the niftiest I've seen.

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>

VIA is an awesome resource for the community and really lowers the bar on entry (our users no longer need to or are expected to compile their own firmware just to tweak keys) as well as just being convenient and nice to have.

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.

It's definitely not currently possible in VIA. It seems to be in normal QMK because the advanced documentation mentions it like it's a normal thing.

But I otherwise agree, it really does make things easy. I just wish it did a little bit more...

Web based esp32 flasher, specifically for squeezelite-esp32

https://sle118.github.io/squeezelite-esp32-installer/

ESPHome in HomeAssistanat also makes use of WebUSB. It's a pretty seamless and nice interface.

https://www.esphome.io/guides/getting_started_hassio.html

Wled [1] install is similar: https://install.wled.me/

[1] https://github.com/Aircoookie/WLED

My glucose monitor used webUSB to upload data to the manufacturer's web site, from which I could then download it (facepalm).

We track some interesting examples here too https://developer.chrome.com/blog/fugu-showcase/?api=webusb

I’ve used it to control DMX light fixtures.

https://gist.github.com/alexanderson1993/5e280410dd10639555b...

I know this might be a silly question but I vaguely remember a (very) old iPhone jailbreak that involved going to a website on your pc and plugging your iPhone into it. I never really investigated how it worked, does anybody remember that or how it accomplished that?

I remember trying that on a 3G or 3GS long ago. But I have no idea how it worked.

It might have used the Netscape Plugin Application Programming Interface (NPAPI) https://en.wikipedia.org/wiki/NPAPI. However it would have involved a step of downloading and installing a plugin, a few extra clicks.

I think you can now compile/upload programs to Arduino Devices with a browser now which is a cool application of WebUSB

https://docs.arduino.cc/learn/starting-guide/the-arduino-web...

Not sure if Web Serial APIs count, but I'll run with it.

I created a two-part project: a web app you configure ad simulate a few* peripherals in, and a bridge device that can interact with the simulated peripherals. Essentially, a bridge between the physical microprocessor you've programmed, and the web app. Doesn't work on Firefox because those APIs aren't available however.

* few being one of seven-segment display, "ultrasonic sensor", and a simple LED.

https://github.com/sk0g/peripheral-emulator-bridge

https://github.com/sk0g/peripheral-emulator-web-app

Does a device need to specifically support WebUSB, or will it work with any USB device so long as the web page supports it? Or is it the browser that needs to support the device? I found contradictory information on this when searching.

Should work with any device. The web page needs to implement the driver/protocol to communicate with the hardware.

What if the device has strict timing requirements?

Even storage devices like thumb drives larger usb3 disks?

The website has to start the interaction with the USB device, it can be any USB device (not sure anymore, but i think you had to filter for Vendor ID). The browser needs to support WebUSB, currently only Chrome.

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.

Thanks, I think I misunderstood the last bit to mean the USB device needed to specifically support WebUSB.

Apparently the basic requirement is that the device should not have a driver already claiming the interface.

More info here: https://web.dev/build-for-webusb/

My keyboard (ZSA Moonlander) has ultraconvenient flashing via webusb.

We put an air quality monitor on a tethered weather ballon which sends real time data with LoRa to a base station. To keep things simple the base station receiver connects through usb and we log the incoming data directly into Chrome with webUSB. The reason to do that way was to keep it simple and without the need for a server or separate applications. Just needed a few lines of JavaScript.

GrapheneOS uses WebUSB to flash your phone.

Pretty wild first experience doing it for me - I'm used to the hassle of sideloading a bootloader and then flashing.

I suspect WebUSB will allow eID readers to work natively without having to install custom firmware in the future. This affects all EU countries.

I haven't had a good look at WebUSB but the landing page thing interests me if there is a way to user program the configuration.

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.

Yes, you need to provide a WebUSB USB descriptor on the device with a link to your site.

Updating firmware of synth.

Same, for example Noise engineering https://noiseengineering.us has 2 lines of eurorack synthesizer modules which are each built on the same hardware and they let you swap firmwares (change your delay module firmware to the distortion module firmware, your drum synth firmware to a compression effect firmware...).

(Also you can write your own fw)

I’ve seen it used as a POS with a chip reader.

Can you elaborate on this solution? It sounds interesting.

The magnetic strip kind used to be able to just act as a keyboard. Didn't need WebUSB to use one with a web site.

WebUSB is a lot nicer because then you don't have credit card swipes, when the wrong thing is in focus, going to the wrong place.

Not the same, but I wrote a serial logger/plotter using WebSerial, as an alternative to the Arduino IDE.

https://github.com/skybrian/serialviz

Also a hack to connect to a Lego NXT brick. (Not shared since I'd need to polish it up.)

Wooting added a web app option for setting up their newer keyboards. Full feature parity with the desktop version

The Chrome DevRel team (that I’m part of) have collected many WebUSB apps in our showcase: https://developer.chrome.com/blog/fugu-showcase/?api=webusb.

Similar to your examples. The NReal Air AR glasses are activated and the firmware is patched using WebUSB:

https://activation.nreal.ai/en/nreal-air-upgrade-plus.html

Not a direct answer, but ESPHome uses WebSerial to flash images which is similar.

I can flash the firmware on my ergodox ez with it. That’s pretty wild

Came here to say that. That oryx configurator is indeed pretty slick.

https://configure.zsa.io/

Blew my mind that it worked flawlessly almost 3 years ago already.

Changing settings on an electric open source powered paraglider. Easy to interface with Arduino

Eg. https://config.openppg.com

I may be wrong about this but I think ESPHome uses it for flashing updates to to ESP8266/ESP32 devices. It always worked for me better than the OTA optioh.

POS systems printing directly to USB thermal printers

The online flasher for WLED uses it. install.wled.me

Chromebook recovery uses webusb it looks so magical and just works, but it does ask for you to have admin rights on the machine !!

I used it for my CNC milling machine. It’s used to configure quadcopters.

It's great for quads, I've used this to flash ESC firmware in the field with just a mobile browser and Internet connection: https://esc-configurator.com/

I think flipper might use it.

teledildonics? :)

Reply on news.ycombinator.com