[HN Gopher] Porting USB applications to the web. Part 1: libusb
___________________________________________________________________
Porting USB applications to the web. Part 1: libusb
Author : RReverser
Score : 113 points
Date : 2022-01-20 16:34 UTC (6 hours ago)
(HTM) web link (web.dev)
(TXT) w3m dump (web.dev)
| tinus_hn wrote:
| The 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]
| tehbeard wrote:
| The OSS community has an easier time supporting it than when
| there's only a crappy windows binary blob?
| mschuster91 wrote:
| A crappy WebASM blob or heavily obfuscated JS blob is similar
| to a crappy windows binary blob, though.
| kitsunesoba wrote:
| Probably worse, because at least there's well established
| tooling for reverse engineering Windows binary drivers,
| allowing for someone to eventually write FOSS drivers.
| RReverser wrote:
| I don't think it's worse because: 1) Wasm was designed to
| be easily decompilable / convertible to a text assembly
| representation by design, whereas for other platforms it
| requires fairly sophisticated disassemblers 2) Wasm can
| interact with the outside world (any I/O) only via
| explicitly defined import points, which are easy to
| intercept and/or replicate even if you don't know what's
| inside the binary itself.
| Palomides wrote:
| plenty 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
| matheusmoreira wrote:
| Proprietary manufacturer software is so bad. It's hard to
| describe how aggravating it is. At least Razer is popular
| enough so people have already reverse engineered the drivers
| and implemented open source versions. I had to do it myself
| on my laptop and it was certainly an _interesting_
| experience. I learned that the manufacturer 's driver was
| intercepting every single keystroke just to send a "light up
| this key's LEDs" command to the keyboard every single time.
| Why couldn't they do it on the hardware? It boggles my mind
| to this day.
| tinus_hn wrote:
| My example would be some 3D printer which you can only use
| from the website, and then after a few years you suddenly
| need a subscription to use your device. And a few years
| further support runs out and you can't use it at all anymore.
|
| Because you can't force a company to keep a website up and
| running. But you can keep a driver on an offline computer.
| RReverser wrote:
| You can likely visit the old version of the website via
| Internet Archive or save an offline snapshot yourself if
| you want, so it would be no different to driver on an
| offline computer.
| folkhack wrote:
| Have to disagree here. Anything remotely complex with JS
| usually doesn't work as-expected after archived on
| Internet Archive. Keep in mind we're not talking about a
| LAMP-driven WordPress blog with some jQuery sprinkled in
| - we're talking about an actual piece of software running
| in the browser ie: device driver.
|
| 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.
| RReverser wrote:
| Good point regarding the offline capabilities, I'm not
| sure how well the Internet Archive will handle Wasm, but
| for the rest - WebUSB was already stabilized and isn't
| considered experimental (although I admit that didn't
| stop some other non-cross-browser APIs from being removed
| in the past).
| petee wrote:
| Archive is a little flaky on this front, but the other
| issue i see is when the company decides Archive is
| illegally hosting and files a DMCA or other lawsuit
| bserge wrote:
| jandrese wrote:
| It won't be cached on the Internet Archive because the site
| is hidden behind a signup link and DRMed to your printer.
| The company will go after third party developers with legal
| threats like all closed hardware companies.
| RReverser wrote:
| Companies that want to do so, already embed "ring home"
| mechanisms in their apps that periodically connect to the
| Internet and check that you still hold a valid license or
| refuse to continue working.
|
| It seems this depends a lot more on the company policy
| rather than specific technology used for the
| implementation.
| cluoma wrote:
| Given that the 'pile of online crap' has been around for a
| while now and seemingly not going anywhere, having access to
| this in the browser, and on any OS, sounds pretty convenient.
| dstaley wrote:
| This is also available in Microsoft Edge. Still, would be
| awesome to see support in Firefox and Safari!
| dmitriid wrote:
| > 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).
| RReverser wrote:
| To 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 :)
| lp0_on_fire wrote:
| > plenty of USB devices need proprietary configuration
| software (like any fancy mouse/keyboard), razer has a whole
| pile of online crap already
|
| Which is the primary reason I will never purchase another
| Razer product.
| monocasa wrote:
| The difference is that webusb requires the specific website
| allowed to interact with the USB device to be listed in a USB
| descriptor. What that means is that you can't replace the
| functionality with the same UX. So for instance Arduino can
| make a generally available web arduino IDE, but I can't
| replace that if it goes down.
| devanl wrote:
| The initial WebUSB proposal included the notion of "allowed
| origins", but it was eventually removed in favor of user
| freedom.
|
| 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.
| monocasa wrote:
| Oh, that's great to hear. I might take another look at it
| then.
| akersten wrote:
| Novelty 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.
| ur-whale wrote:
| Is that not a Chrome-only thing?
|
| Why would anyone want to do this if it only works on one browser?
| qbasic_forever wrote:
| Shipping 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 wrote:
| > 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.
| rodgerd wrote:
| > Why would anyone want to do this if it only works on one
| browser?
|
| 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.
| alar44 wrote:
| Sorry, 63% of browser usage is dominant, but not a monopoly
| by any means. The web is just as accessable on other
| browsers.
| RReverser wrote:
| Because 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 wrote:
| That 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.
| qbasic_forever wrote:
| Does 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.
| exodontist wrote:
| It 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.
| worldmerge wrote:
| > I've built robots controlled via web USB like 10 years ago.
| It's great. I've written midi tools that work with webmidi
|
| That sounds cool!
|
| Chrome Experiments [1] has existed because Chrome has been at
| the forefront of the web for years.
|
| [1] https://experiments.withgoogle.com/collection/chrome
| Ajedi32 wrote:
| I 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.
| tjoff wrote:
| Hope not, just use virtualhere or similar. No real point in it
| having to run in the browser.
|
| Or, in the case of serial or remote debugging. Just run a
| terminal or gdb next to the target and connect to that instead.
| MuffinFlavored wrote:
| I 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-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. :(
| ocdtrekkie wrote:
| This 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 wrote:
| I 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 wrote:
| It 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 wrote:
| How 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 wrote:
| It'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.
| qbasic_forever wrote:
| You need to explicitly allow a site to access a device,
| it should pop up a dialog and ask the first time you
| initiate it: https://web.dev/usb/
|
| 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.
| RReverser wrote:
| If it didn't even ask for permission, most likely it
| didn't use WebUSB, but connected via HTTP to a crappy
| local executable preinstalled by the vendor.
|
| 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.
| RReverser wrote:
| Btw, author of the port / demo / article here - happy to answer
| any questions you have :)
| worldmerge wrote:
| That 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.
| sorenjan wrote:
| Why 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
|
| With that said, thank you for writing and sharing the article.
| It's interesting even with the above mentioned irritant.
| RReverser wrote:
| I 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 wrote:
| > 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 wrote:
| Is 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 wrote:
| > 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 wrote:
| Funny 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 wrote:
| Well, 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.
| dmitriid wrote:
| > 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
| ciupicri wrote:
| Regarding 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/
| [deleted]
| malepoon wrote:
| It'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.
| AviationAtom wrote:
| Ecco wrote:
| We 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/
| magicalhippo wrote:
| ESPHome uses WebSerial[2] to flash microcontrollers via the
| browser, saving the user from having to install a whole
| development environment and whatnot to do the initial firmware
| upload.
|
| 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_...
| dylan604 wrote:
| >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 wrote:
| Oh, 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 wrote:
| Unfortunately, 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 wrote:
| Yes 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.
| RReverser wrote:
| Ah yeah, that should be easier! I was mostly coming from
| the perspective of trying to get DSLR working in the demo
| :)
| dljsjr wrote:
| Windows 11 has made a lot of questionable choices that are
| leading to a lot of people staying on Windows 10 voluntarily.
|
| 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)
| Kye wrote:
| "People are staying on [previous Windows] due to problems
| and questionable choices made with [new Windows]." The
| claim stays the same, but the version keeps incrementing.
| I'm not convinced this is a thing in meaningful numbers.
| ChuckNorris89 wrote:
| _> 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_
|
| 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-...
| jml7c5 wrote:
| On the other hand, from that page:
|
| > _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.
| sorenjan wrote:
| Steam hardware survey from December 2021 shows 81.74% Windows
| 10 64 bit, 10.15% Windows 11 64 bit. I would guess that
| Windows 11 is overrepresented among Steam users compared to
| Windows users in general, but that's just a guess.
|
| https://store.steampowered.com/hwsurvey/Steam-Hardware-
| Softw...
| [deleted]
| bserge wrote:
| worldmerge wrote:
| That's super cool! WebUSB is something I'm really interested in
| learning and WebBluetooth. Cross platform apps that need sensor
| access is a bit of a pain and the web seems like a no brainer
| to solve that.
|
| 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.
| [deleted]
___________________________________________________________________
(page generated 2022-01-20 23:00 UTC)