14 ms·
Porting USB applications to the web. Part 1: libusb
- RReverser 5y agoBtw, author of the port / demo / article here - happy to answer any questions you have :)
- sorenjan 5y agoWhy do you write "to the web" when it's actually "to Chrome and Chrome's siblings"? Chromium doesn't define the web. It's a common theme in articles from web.dev, where Google pretends that Chrome only features are general web features. https://caniuse.com/webusb https://caniuse.com/webusb With that said, thank you for writing and sharing the article. It's interesting even with the above mentioned irritant.
- RReverser 5y agoI understand where you're coming from, but at the same time it's a feature defined as a finalized spec in the Web incubator. Even if it's currently implemented by one engine, 1) that engine is used in browsers from many different vendors - Google, Microsoft, Samsung, etc. which represent a huge chunk of the Web and 2) there's still hope that other browsers will implement it in the future. 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.
- dblohm7 5y ago> Even if it's currently implemented by one engine, 1) that engine is used in browsers from many different vendors - Google, Microsoft, Samsung, etc. which represent a huge chunk of the Web That's a really terrible argument, tbh.
- RReverser 5y agoIs it? It's worth keeping in mind that it's users and apps that comprise the web, not the implementation details of any given browser.
- dmitriid 5y ago> It's worth keeping in mind that it's users and apps that comprise the web, not the implementation details of any given browser. 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.
- RReverser 5y agoFunny how you use words like "insult" yet don't see the irony in the tone you use when talking to other people :) Good day to you too.
- dmitriid 5y agoWell, you don't care about that, either. Because the entire behaviour of every single public person from Chrome team has been: - 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.
- afavour 5y agoJust from a third party perspective here: your tone in this post and all over the thread is not even remotely constructive. You have one point that you’ve made rudely in about five different places. We get it.
- malepoon 5y agoIt's too bad these Chromium "specs" tend to be pretty low quality and rushed. They're then never changed because "too bad, we shipped it already, can't break the web!" See the garbage they tried to push in the form of NaCl, WebSQL, etc.
- baxuz 5y agoDon't forget Web components v1
- ciupicri 5y agoRegarding File System Access I notice that [1]: > 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. [1]: https://wicg.github.io/file-system-access/ https://wicg.github.io/file-system-access/
- deleted 5y ago[deleted]
- dmitriid 5y ago> but at the same time it's a feature defined as a finalized spec in the Web incubator. 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
- chrismorgan 5y agoWebUSB is not finalised in any way. It’s a WICG draft (draft means not finalised, and WICG means explicitly unofficial), with only one shipping implementation in browsers. (There’s also an implementation for Node.js, but I think that’s considered irrelevant.) My recollection of the rough processes is that to become a Candidate Recommendation (which is the first stage you could reasonably argue “finalised spec” corresponds to) it would need at least a second shipping implementation, and to be adopted by a working group. 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 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 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.
- mehdix 5y agoThank you for clarification. As an ill-informed reader, by reading the parent comment I was under the impression that it was already a standard. 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.
- RReverser 5y agoIt sounds like you're talking about the W3C standards track (correct me if I'm wrong, just guessing from the context) whereas I'm talking about the spec itself as the document and the API. Those are two different things after all. 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.
- worldmerge 5y agoThat was really cool! WebUSB seem really interesting, I can see using it in some future projects so I don't have to deal with OS specific things.
- tehlike 5y agoOne thing i recently attempted (and still looking into it as i have time to work on it) was to do a usbip-bridge for webusb. The idea is using a device attached to user's machine and exposing it to a vm in cloud. There are various use cases for this. 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?
- RReverser 5y agoI didn't see it but did think about it. I think it should be possible by wrapping WebUSB into something like Comlink, e.g. I know Surma experimented with allowing Comlink to be used with WebSockets: https://twitter.com/dassurma/status/1218207376899235840 https://twitter.com/dassurma/status/1218207376899235840 Comlink takes care of the RPC part of any API, so you only need to choose and hook up a communication backend.
- tehlike 5y agoThis is actually at a lower level. This is to bind webusb remote device as a virtual device in Linux. It would be more flexible and has very interesting use cases.
- RReverser 5y agoAh, I see. That would be interesting, but removes the cross-platform compatibility from the equation, which, for me, is the most valuable piece of WebUSB and other similar APIs.
- travisby 5y agoI'm really excited to see this post! I've actually tried doing something similar -- I want to use/create a smartcard reader on the web that works with gpg. 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 ;).
- RReverser 5y agoGlad to hear! If you want to give it another try, you should be able to use my linked libusb fork in any app that depends on libusb, and compile that with Emscripten.
- qbasic_forever 5y agoDoes web USB actually have a chance of making it into browsers besides Chrome? Last I read there was a strong pushback against it for security reasons from everyone else in the web standards space. I'd love to have access to serial devices and embedded hardware but I'm not holding my breath.
- MuffinFlavored 5y agoI went really far down the WebUSB rabbit hole. It was almost perfect except for the fact that... when you do intensive stuff, Chrome has built in tab throttling in terms of CPU resources. https://www.tenforums.com/tutorials/80233-enable-disable-google-chrome-background-tab-throttling-windows.html 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. :(
- Ajedi32 5y agoI think if enough people start actually using it other browsers will eventually implement support. But for now, yeah, it has the downside of being Chrome(ium) only, which makes it far less useful than it could be.
- dwaite 5y ago> I think if enough people start actually using it other browsers will eventually implement support. 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.
- exodontist 5y agoIt totally works. I've built robots controlled via web USB like 10 years ago. It's great. I've written midi tools that work with webmidi..they worked well also. Dunno why ppl are hating on it. Safari/FF are the new IE and IE is chromium now. It's a strange world but the way you get these standards adopted is to make killer apps that use them.
- tinus_hn 5y agoThe next step is that you buy the device, but you don’t get a driver. You can conveniently use it from the manufacturers website. I’ll leave it to others to speculate on what happens to the website in 2 years.
- deleted 5y ago[deleted]
- Palomides 5y agoplenty of USB devices need proprietary configuration software (like any fancy mouse/keyboard), razer has a whole pile of online crap already if you want something else to complain about, this depends on chrome-only USB support
- dstaley 5y agoThis is also available in Microsoft Edge. Still, would be awesome to see support in Firefox and Safari!
- RReverser 5y agoTo be fair, Edge is also Chromium-based (I guess that's what the previous author meant, rather than specifically Chrome-only). 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 :)
- dmitriid 5y ago> Still, would be awesome to see support in Firefox and Safari! 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).
- 5y ago
- AviationAtom 5y agoI think this whole concept is roughly similar to what the doomed C.H.I.P. ($9 SBC) Web Flasher Project did, no? 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_an_OS https://wiki.popcorncomputer.com/wiki/Original_Popcorn:Flash...
- ocdtrekkie 5y agoThis is basically the "our only desktop OS is a web browser" company's equivalent to asking everyone to rewrite their apps in UWP. And as a side benefit, also makes it extremely easy to maliciously control hardware. A win for Google on two fronts here.
- qbasic_forever 5y agoI don't buy the security concern is any worse than a website being able to maliciously make requests against your bank website and drain all your accounts. We've spent decades engineering cross site request security to mitigate those issues. This is no different of a trust problem, just with a physical device. I'm confident if we can build things that give users enough trust to type in their bank account website, enter credentials, and send/transfer funds while knowing it is secure, then we can do the same for making sure the widget you plugged into your device is being controlled by the site you expect and allowed.
- Kye 5y agoIt was both surreal and concerning when I plugged in my new Launchpad X, went to Novation's website for their hardware tool, and got a firmware update directly from the page. I wish I had your confidence in the security practices of hardware companies. The growing IoT botnet swarm suggests it's misplaced.
- qbasic_forever 5y agoHow is it different from you downloading an executable binary from their site and running it? You're taking the same leaps of faith that the exe hasn't been tampered with, you haven't been man-in-the-middled, the developers of the exe wrote correct code, etc.
- Kye 5y agoIt's not Novation or the domain I distrust. It's the fact that it didn't have to ask for permission to connect. It just did it. I don't know if another site could just swoop in and drop a little firmware that makes my Launchpad show adorably profane things in a 64x64 grid. I can change permissions to require it to ask, but why isn't that default? It seems to be enabled now, but I don't know if that was me or a browser update.
- Ecco 5y agoWe have been using WebUSB extensively for 4 years now, and we are extremely happy with the result so far. We make a graphing calculator and we want our users to be able to easily update it. We considered a bunch of options, and WebUSB definitely was the best [1]. 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! [1] https://www.numworks.com/blog/webusb-firmware-update/ https://www.numworks.com/blog/webusb-firmware-update/
- dylan604 5y ago>Windows 10 is being more and more popular, Hasn't Windows 10 been a thing that's come and gone now in favor of Windows 11?
- Ecco 5y agoOh, well, maybe :) My point was that in Windows <= 7 you needed to install a custom driver to allow WebUSB to work with your specific device. From Windows 8 and up, you can use WebUSB to talk to your device without installing anything at all, which makes it a lot easier for the end users!
- RReverser 5y agoUnfortunately, that's not entirely true. If your device is designed for WebUSB and has its specific descriptor, then yeah, you don't need to change any drivers. 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.
- Ecco 5y agoYes indeed. But if, like us, you have full control over how your device operates, then you at least have a path to make it plug'n'play on Windows > 7. Before that, we were out of luck.
- ur-whale 5y agoIs that not a Chrome-only thing? Why would anyone want to do this if it only works on one browser?
- qbasic_forever 5y agoShipping cross platform code that talks to USB devices is a nightmare. Libusb has made leaps and bounds to improve it vs. the myriad of native platform APIs, but you still will have to painfully walk users through a process that's often fraught with OS-specific confusion and issues.
- ur-whale 5y ago> Libusb has made leaps and bounds to improve it vs. the myriad of native platform APIs 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.
- RReverser 5y agoBecause that browser provides a universal API that works across pretty much all the popular operating systems, whereas the alternative is to build and maintain code for each of those systems separately.
- ur-whale 5y agoThat browser is Google controlled spyware, and even temporarily installing it on my box to talk to a USB device gives me the willies. 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.
- rodgerd 5y ago
- akersten 5y agoNovelty of the demo aside, whoever named Project Fugu did a great job. Eating around the lethal guts of a poisonous fish is precisely how I feel seeing libusb accessible by JavaScript.
- rowanG077 5y agoWhat are the security implications? You only give acces to a specific device afaik. Is the attack surface of libusb too large? Why is it different then for example webcams?
- dwaite 5y ago> Why is it different then for example webcams? 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.
- tonymet 5y agothe browser code base is bigger slower and clumsier than most OSs. why are we paying people to rewrite 25 year old code with worse UX?
- RReverser 5y agoPart 2 is out: https://news.ycombinator.com/item?id=30165184 https://news.ycombinator.com/item?id=30165184