Porting USB applications to the web. Part 1: libusb
web.dev
web.dev
This article is a bit old, but since then the situation as become even better: - Windows 10 is being more and more popular, so WebUSB really is a "plug and play" solution on Windows now too - Windows comes with Edge that also has WebUSB support
I really with Firefox would include it too!
Super slick from a user POV, just connect the device via USB cable and hit the flash button. I admit I was a bit skeptical to all this, but having just tried it I must admit it was very, very convenient. The ESPHome instance was running as a container on my Home Assistant device, again a simple one-click install.
[1]: https://esphome.io/
[2]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_...
Also cool to see a competitor to Texas Instruments. I'm in the USA and had to get TI calculators for classes.
> Firefox would include it too!
That'd be nice.
Here's more information from the author of Zadig: https://github.com/pbatard/libwdi/wiki/WCID-Devices
Hasn't Windows 10 been a thing that's come and gone now in favor of Windows 11?
Windows 11 has additionally made a lot of questionable choices that are forcing a lot of people to stay on Windows 10 involuntarily (e.g. they don't support motherboards w/out TPM's and they don't officially support CPUs that aren't relatively new; e.g. it only "supports" Intel CPUs that are 8th gen or newer regardless of cores/frequency)
Search that is significantly slower than win10 while being "vastly better" only because win10 search was straight up non-functional and win11 can at least find what you're looking for (whether it's in a reasonable order and doesn't reshuffle with every keystroke seems to be a gamble each update).
"Nicer UI" that only a minority of users actually like, removes support for very common configurations, some of which are objectively more efficient for certain use-cases (side taskbar, ungrouped windows...).
Don't get me wrong, if it works for you, that's great! But make no mistake, Windows 11 is a complete dumpster fire from a UX perspective.
I suppose, but I refuse to give it any credit for finally fixing the search that worked fine over a decade ago.
The rest is pretty marginal.
That alone is enough for me to hate it.
Can we please end this FUD that keeps parroted over and over?
Microsoft themselves mention that TPM 2.0 and CPU model requirements are just soft-requirements checked if you go the upgrade path but are not enforced if you do a fresh install from image[1] when only TPM 1.2 is the single hard requirement, but every CPU after 2011 should have it. I installed from image Win 11 on multiple PCs with chips way older than Intel 8th gen and had no speedbumps.
[1] "Important: An image install of Windows 11 will not check for the following requirements: TPM 2.0 (at least TPM 1.2 is required) and CPU family and model."
[1] https://support.microsoft.com/en-us/windows/ways-to-install-...
>We do not recommend installing Windows 11 on a device that doesn't meet requirements.
And on a linked page: https://support.microsoft.com/en-us/windows/installing-windo...
>Installing Windows 11 on a device that does not meet Windows 11 minimum system requirements is not recommended.
>If you proceed with installing Windows 11, your PC will no longer be supported and won't be entitled to receive updates.
---
I would update to Windows 11, but the possibility that I will stop receiving updates (or that at some point updates will no longer be compatible) makes it unappealing.
The fact that they straight up say that these configurations may not be eligible for auto-updates is very much saying they do not support these configurations.
https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
However, as mentioned in the article, if it's a "well-known" device, then you still need to use Zadig and override the driver to something like WinUSB.
https://www.tenforums.com/tutorials/80233-enable-disable-goo...
I think it was something roughly like this but in terms of asking end users to use it... looked like a no go.
I wish iOS would let users write `libusb` code that worked. :(
Chrome is the new IE – doing whatever they want, and expecting every other browser vendor to enthusiastically chase them because they have the largest market share.
That sounds cool!
Chrome Experiments [1] has existed because Chrome has been at the forefront of the web for years.
Or, in the case of serial or remote debugging. Just run a terminal or gdb next to the target and connect to that instead.
Their excuse is "security". Which is funny as native apps do the exact same thing and more, often without dedicated permissions.
Mozilla also rejects most of it and joins Apple in claiming its due to security. It's speculation, but I think they really don't have the resources anymore to build such massive features and conveniently spin it into something good for the user.
Not sure I agree that makes it justified, but it does sketch me out a bit the more low level systems my browser has access to
But for now, yeah, it has the downside of being Chrome(ium) only, which makes it far less useful than it could be.
There are several specs (like USB, Bluetooth, and MIDI) which are Chrome only, and for which other browser makers have explicitly stated they don’t agree with and will not support. Further, they have said that their rejection of these specs is due to security issues (e.g. providing full access to local hardware behind a single permission prompt)
This is much a higher bar than just lack of interest or resources to getting cross-browser compatibility.
including Edge, Chromium, and Vanadium.
Getting temporary access to video is different than getting access to upload firmware that changes how the webcam works.
It is also more abstract - the browser is not going to be able to enumerate the ramifications of what they are approving. Think a script which is asking for access to a YubiKey - there’s no way the browser can enumerate the various security ramifications of doing so, and the webpage itself may do so incorrectly (this is a reason that I believe Chrome deny-lists access to FIDO keys to WebUSB).
Finally, video access is a known quantity and thus gives opportunities to surface potential abuses in certain ways, such as displaying a colored ‘recording active’ indicator across tabs when the camera is in use, or providing a way to temporarily restrict video access without needing to find the application control option.
I’ll leave it to others to speculate on what happens to the website in 2 years.
if you want something else to complain about, this depends on chrome-only USB support
Which is the primary reason I will never purchase another Razer product.
Because you can’t force a company to keep a website up and running. But you can keep a driver on an offline computer.
It seems this depends a lot more on the company policy rather than specific technology used for the implementation.
In good faith I would not expect something which uses experimental browser APIs to maintain functionality when archived by Internet Archive's automated crawling solutions. Same applies to offline saving.
The device can provide a landing page URL for the browser to show when the device is plugged in, but otherwise any site meeting the secure origin requirements and that has user permission can access a USB device, same as any other website.
Both Safari and Firefox consider WebUSB harmful, and will not implement. Their reasons have been voiced loud and clear to the Chrome team (as they were voiced regarding many other standards).
Chrome, however, is the dominant browser and engine, so they dont' care. At all. It's now a "standard", and you will never other browser implementers' positions on web.dev (which is now a full-on unashamed Chrome propaganda vehicle).
But yeah, I'm also hoping for WebUSB to make its way to other browsers, but for now I'll take any improvement to building & distributing apps across many operating systems at once :)
With that said, thank you for writing and sharing the article. It's interesting even with the above mentioned irritant.
For example, File System Access API was also part of WICG and similarly deemed by commenters as Chrome-only API because it implemented it first, but is now at least partially implemented in Safari 15.2. Who knows what we'll see adopted next? As long as there's a Web spec and apps using an API, browser vendors can prioritise.
As it stands, there’s no short-term prospect of a second implementation: Mozilla’s current position is that WebUSB is harmful because it’s super dangerous and the risks can’t be adequately explained, and is a tracking hazard <https://mozilla.github.io/standards-positions/#webusb>, and WebKit have likewise consciously decided not to implement WebUSB for similar reasons (“due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns”) <https://webkit.org/tracking-prevention/#anti-fingerprinting>.
That multiple browsers use the same engine and implementation is irrelevant for standardisation—otherwise Chromium would be the very definition of the standards. To show this even more clearly, WebSQL was scuttled because everyone used SQLite and there was no satisfactory way of specifying what would be permitted.
Speaking frankly here: as the post author and a “WebAssembly Advocadoer @Google”, you’re speaking from a position where authority will be assumed, but in this comment you expressed some very significant errors and presented a badly biased view. This is not good.
Considering the hazards, the last thing I want is random js in random website start messing with my operating system file system and USB connected devices.
All browser engines have been following living specs even for core stuff like HTML/CSS instead of the W3C "officially finalised" standards for a while now, so I didn't bring the latter up as they weren't relevant to the conversation about the spec itself or its stability.
However, I admit that I missed myself and should've called out that the spec, while stable, is still a draft - that's a mistake on my part.
How much more in this case, given Mozilla and Apple’s positions on it! It’s extremely likely that if it does get taken onto the standards track it will only be with breaking changes.
WebUSB is not finalised and is not stable, even if it hasn’t changed recently—because the only reason it hasn’t changed is because no one but Chromium is willing to touch it because it’s such a run-away-screaming scary idea for security. That it is metastable (that’s a more suitable word) in its current state is an indictment against it, not a good thing.
The WHATWG Living Standards are a completely different kettle of fish—it’s not a case of even for core stuff, it’s a case of that being a model that makes sense for the well-established core stuff where changes affect many places, given implementation practice (and indeed that’s why browser makers forked HTML, because the W3C development model wasn’t working for them); but the Living Standard approach doesn’t make sense for new stuff and well-isolated functionality, like most CSS and JavaScript APIs.
I guess it makes sense from business perspective, but I still believe in the original idea of making more powerful apps with Web technologies, even though the companies that work on those ideas changed over time.
Firefox OS needed those sorts of things for its “apps” since it had no lower-level “native”, and I think that they were only exposing features like that to trusted code (meaning apps you deliberately installed) rather than general web content, until they could be sure it was reasonable.
I think they also designed the OS with a better peripheral security model than Windows/Linux/macOS, nullifying or mitigating one of the two critical problems of WebUSB (that the computer trusts peripherals too much, so that one that’s hijacked can more easily become a remote code execution vulnerability).
(I write all this as one who kept a fairly close eye on Firefox OS, but has never run it.)
I'd actually be pretty happy if browsers chose to implement those APIs with the same restriction in mind - that is, only for explicitly installed PWAs. I said this elsewhere in the past, and I still think that's a reasonable restriction that could provide a path forward.
> or mitigating one of the two critical problems of WebUSB (that the computer trusts peripherals too much, so that one that’s hijacked can more easily become a remote code execution vulnerability)
I'm not very well-versed in the details, but I believe that's also the reason why WebUSB (or Chromium implementation of WebUSB?) doesn't allow certain classes of devices to be ever accessed via that API.
Yes, certain classes are restricted from access via WebUSB for security, https://wicg.github.io/webusb/#protected-interface-classes. But as the note says, it’s about balance: that list is necessary for security, but not sufficient.
Same can be said about native apps. Like with other hazards, in the end it's all about balance - you can't stop users from _ever_ doing stupid things.
I think that's the root of our disagreement. Few years ago I've been of the same mind about giving the web new powerful features, but after watching the space and seeing the existing alternatives I've come to change my mind.
As mentioned in another thread below (https://news.ycombinator.com/item?id=30013287), vendors who need this sort of functionality, already find ways to implement it via other proprietary methods like local executables that, unlike implementations of Web APIs, are not reviewed by other teams and usually expose all sorts of critical stuff over local HTTP servers or in another insecure fashion.
In the end, it's not a question of "if" we want to expose those features to the web apps, it's "how" we can do so with minimal risks to the users, and that's where web APIs with thought-out permission models, explicit requests and history of cross-origin checks can help.
Of course, you can also say that vendors can continue to implement those things insecurely anyway even when new APIs exist, but 1) in practice when they're given a simpler way to do the same thing, they tend to go for that more often instead of inventing custom hacks and 2) that's where advocacy of the new APIs comes in, and what I'm trying to do by showing what the web can be if we let it.
As for your other arguments about potential for breaking changes if/when those APIs get adopted by other browsers, I agree I might be overoptimistic and your prediction might very well turn out to be true. Those APIs map to basic USB concepts quite closely, so I can't imagine what changes would be necessary, but, of course, I don't have enough experience with WebUSB outside this project to say that it's 100% impossible :)
In the end, it's a bit of a chicken-and-egg problem - in order for browsers to see the interest or get feedback, there have to be apps trying to build something with those APIs and reporting bugs / feature requests, and for those apps to use those APIs, there has to be at least one implementation first. This problem can be chewed from either end, and I'm trying to do my part by showing developers how those APIs can be used for porting interesting apps and libraries.
WebUSB is so scary for security because neither USB devices nor desktop operating systems have been written with such a use case in mind. There are two key problems in WebUSB: ⓐ USB devices weren’t designed with public exposure in mind, so that they’re commonly insecure and brickable or hijackable if you get access to them; and ⓑ operating systems weren’t designed with malicious USB devices in mind. Combine these, and you’ve got potential total sandbox escape and remote code execution, guarded only by a flimsy permissions popup that doesn’t explain what can happen—can’t explain what can happen. The threat here is probably the most severe (using the definition in the severity/probability model of risk assessment) ever contemplated for the web.
Yes, there are legitimate uses of such an API. Yes, this makes life much easier and even safer for such uses. But if the concept doesn’t also give you the heeby-jeebies, you haven’t thought the implications through enough, haven’t seen how bad programmers are at their jobs, and haven’t observed how hopelessly ineffective permissions popups are at protecting users. I watched the video in your article and was horrified that it’s not even trying to protect you or indicate that this is anything other than routine: you just get a “‹origin› wants to connect” popup with a list of routinely-cryptic device names (“ILCE-6600” rather than “Sony α6600”) that you can choose from. Yet this is a thing that, with the wrong USB device and a malicious attacker that knows about a vulnerability in it, could literally set fire to your computer, steal all your passwords, or silently install malware on the USB device or computer.
For myself, I might prefer to have WebUSB, because I trust my judgement in what I execute and because it’s more likely to support my platform. But for the population at large, on the balance of things, no, I agree with Mozilla’s position that it’s harmful, and would regretfully condemn people to continue downloading and executing untrusted code from the manufacturer, because that’s more likely to be done deliberately and only for first-party code.
WebUSB is problematic because there’s probably no safe subset of its functionality: it seems to be fundamentally dangerous. People have tried proposing a few subsets, from memory (I’ve occasionally paid a little attention to it), but so far they’ve all been rejected as either not safe enough or too crippling; and so Chromium has declined to be crippled and implemented the wildly unsafe with only mild mitigations to limit the class of devices exposed, and Gecko and WebKit have declined to play it dangerously. It’s similar to the question of exposing raw TCP, which was contemplated, but ended up being deemed too dangerous, and so it was wrapped up in HTTP as WebSockets: something not quite as useful, but safe. It’s possible someone could come up with something like that for WebUSB, something that constrains it to something safe. Such a constraint could easily require major API changes. That WebUSB currently matches the fundamental USB concepts closely is no saving grace in the stability of the protocol.
That sounds like WebSerial and WebHID to me, which don't require similar shenanigans with Zadig on Windows or Linux permission changes, because they allow access to a limited subset of USB device functions.
But that will never cover all the use-cases for USB apps. For those the only choices are not to do anything at all and let closed native executables to continue dominate this space (which gives them unlimited access without even those simplest permission prompts), or to work on WebUSB and encourage devs who do need to interact with such devices over USB to switch to that instead. I don't see 3rd option or how it would be possible in our non-ideal world, and among those two WebUSB still seems like a better idea.
As is never mentioning the fact that WebUSB is considered harmful by both Safari and Firefox, and hiding it behind "oh, I do hope other browsers will implement it". They won't, you are perfectly aware of it, and the reasons why they won't.
At the same time, I'm perfectly happy to respond to questions and concerns of other people like the one above who can express their thoughts without resorting to personal attacks.
What a wonderful word, "respond". Not answer. Respond. That's exactly what you're doing: responding
HN: This is not "finalised"
Respond: oh yes, it is finalised. Because browsers [sic! plural] conform to the living standard
HN: It's not implemented or supported by browsers (plural).
Respond: Oh, it doesn't matter, all that matters is that Chrome implemented it
(Aside: for something to be considered standard and finalised there should be at least two independent implementations. See history of why WebSQL on top of Sqlite never happened)
HN: Others view this standard as harmful
Respond: why are you attacking me personally
> who can express their thoughts without resorting to personal attacks.
To me you are just another in a long list of Chrome's talking heads who all behave absolutely identically (and their behaviour is very well documented across various internet platforms): ignore, deflect, gaslight. What you see is simply a reaction to this. To your credit you haven't stooped down to gaslighting.
Want to see a different approach? Change your (as in Chrome team's) behaviour. That is, however, unlikely: Chrome stands nothing to lose by ignoring any and all concerns about its behaviour.
> 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.
At the dame time both Firefox and Safari consider this feature harmful and will not implement it.
Just because you rammed it through standards bodies doesn't make it standard, or good.
And, unfortunately, you've co-opted web.dev to be a full-on Chrome propaganda machine.
Additionally, the status of this "finalized spec" is, quote, "Draft Community Group Report". It's nowhere near to being a) finalized and b) standardized.
The "finalized spec" literally has this in its description: "It is not a W3C Standard nor is it on the W3C Standards Track."
> For example, File System Access API
1. Is anyone talking about this API here? No. Only you, trying to pull conversation away from WebUSB
2. Filesystem API suffers from the same thing: it's a "standard", and now your team is busy pushing three more file standards
That's a really terrible argument, tbh.
Ah yes. As we all know, Chrome is very well known for how well it listens to users. Remember the alert fiasco? And many other fiascos?
Or remember "standards" like WebHID which are so bad that Mozilla engineers couldn't even understand them, but you still shipped them?
Or other "standards" which have multiple issues pointed out and still shipped by default in Chrome?
Please don't insult our intelligence by pretending that you, or Chrome team care at all about users or standards.
Good day to you too.
- deflect
- pretend Chrome-only APIs are standards
- gaslight other browser vendors
You are not different, and there's literally nothing in this world will stop you, and nothing I say or do can ever even begin to approach the behaviour of the Chrome team.
So, do hold up the mirror to your actions first.
Chrome team couldn't give two craps about any amount of constructive feedback from other browser implementers, framework authors and web developers on most of the stuff they ram through standards bodies. Why start now?
I'm not saying it has to be particularly constructive. But you can describe how a policy is terrible without your comment becoming a personal combative mess.
Something like:
Yeah, users comprise the web, and Chrome doesn't listen to them. See the alert fiasco, among others. [side note: probably elaborate here, I don't know what alerts you're talking about even after a search]
The Chrome team created a "standards" documents for WebHID that was so bad that Mozilla engineers couldn't even understand it, and still went ahead with shipping.
Others "standards" have had serious issues pointed out, with other browsers refusing to implement them, and Chrome keeps shipping them by default.
Users and proper standards haven't mattered at any point.
What's the point though? Look at this exchange between RReverser and chrismorgan: https://news.ycombinator.com/item?id=30019370
chrismorgan: WebUSB is not finalized, there’s no short-term prospect of a second implementation, it is not on the standards track, given other implementers' positions if it ever becomes standardized it will be with breaking changes, etc.
RReverse: lol it was first proposed by Mozilla in Firefox OS, and WebUSB is good, actually
chrismorgan: "My main disagreement with you is not based on the soundness or otherwise of WebUSB functionally, but your position on it as a specification."
... and the discussion was safely deflected to discussing FirefoxOS and the merits of WebUSB itself.
This is the modus operandi of Chrome's "developer advocates": ignore, deflect, gaslight. It happens again, and again, and again with any and all public personas out of the Chrome team. No matter how constructively you engage with them. To RR's credit he doesn't stoop low to gaslighting (as in "we blame other browsers for everyting").
The only recourse is to cut through all the bullshit and call out the deflections and the lies.
Constructive tone has been tried with Chrome team again, and again, and again, and again.
It's gotten so bad that in various "Request for position on standards" Safari team simply ends up saying "no" without stating reasons. Because it literally doesn't matter anymore.
All is left is directly pointing out the outright lies (see e.g. https://news.ycombinator.com/item?id=30019370) that Chrome's various talking heads will tell you.
And yes. I will keep saying this in many places. And there's a good reason for that, as someone else noted in the discussion: https://news.ycombinator.com/item?id=30014807 Do you by any chance go and admonish people for "not being constructive" about Safari or Firefox?
The goal was to port pcsclite or scdaemon to use webusb instead of libusb.
It's been a while; I forget exactly where (very early) I left off/felt defeated. I definitely didn't consider making an additional backend for libusb!
Very cool -- I can't wait to see part 2 ;).
So far - i could only bridge USBIP communication, not much success with binding a proxied usb to a vm.
Did you see something like this?
Comlink takes care of the RPC part of any API, so you only need to choose and hook up a communication backend.
Why would anyone want to do this if it only works on one browser?
There's of course Chromium, but the code base of Chrome is so huge, I'm not even sure Chromium has been properly audited to be "clean" wrt being subservient to Mountain View.
I do understand the old dream of a "universal API", it's snake oil that has been peddled to the IT crowd since I was a teenager (looong time ago).
I also wish it could happen, but Chrome certainly isn't it.
As a matter of fact, that is exactly what Chrome uses under the hood.
Except that instead of exposing the libusb API as unchanged as possible at the JS layer, they've somehow decided - they being Google and hence smarter than everyone - to re-engineer to API to be o-so-slightly different, but not actually any better.
What a crock.
Chrome is at least as dominant as IE 5 & 6 were. The only reason that you're not hearing constant screaming about the near-monopoly (indeed, most of the screaming is abusing Apple for not just "doing what Google says" in the browser space) is because for some reason people think that the monopoly is good when an advertising company is doing it.
Only on mobile is it less, and only because of iOS Safari
And as a side benefit, also makes it extremely easy to maliciously control hardware. A win for Google on two fronts here.
Connecting to a USB device requires only a single click. That just requires an attacker making the user believe what he wants, by stressing the user or by misleading or conditioning the user about what it is. It is not a more secure design than the UAC boxes in Windows Vista that users learned to "click be gone" by routine because they were annoying.
I was thrilled when I first heard about WebUSB because I had been looking for a way to configure USB device firmware using a web browser.
However, I learned that it has glaring security flaws:
* The web page bypasses the operating system's driver infrastructure, where VendorID/ProductID pair is used to look up only valid drivers. Some operating systems require USB device drivers to be signed. A web page requires only a click from the user.
* WebUSB allows web access even to devices that don't have explicit support for it. Older devices can have been designed under other pretences of security. Not all hardware engineers even know about WebUSB, so this applies to newer designs too. This is already serious, because there are devices used for 2FA that connect via USB that could be exploited this way.
* A device can not control which of its interfaces that a web page can claim or not claim.
* WebUSB contains no authentication of the web page on the device's behalf. (There was some idea that it should have, but that was removed for convenience )
Not ready for prime-time IMHO.
Such implementations exposing all sorts of critical stuff over local HTTP servers are often highly insecure, and are the very reason why WebUSB and other device APIs are being pushed as part of the browser.
You've got the same trust problem for any other exe you download and run though. Any steam game you play could reprogram your device to show profanity for example.
What are some other potential uses for this down the road?
EDIT: Looks like the Popcorn Computer is still available and does roughly the same thing https://wiki.popcorncomputer.com/wiki/Original_Popcorn:Flash...