Porting USB applications to the web. Part 1: libusb(web.dev)
web.dev
Porting USB applications to the web. Part 1: libusb
https://web.dev/porting-libusb-to-webusb/
129 comments
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_...
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_...
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.
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]
[deleted]
Thank you for linking to NumWorks. Everything about that product seems of extraordinary high quality. The code, the open hardware build specs, very nice!
How come your Windows use case didn't require Zadig? I couldn't get any USB device to work via WebUSB without it.
They probably use WCID, which is a mechanism for devices to tell Windows that they are compatible with the generic WinUSB driver. Zadig is useful for older versions of windows, non-WCID devices, and when you want to override that auto-specified driver.
Here's more information from the author of Zadig: https://github.com/pbatard/libwdi/wiki/WCID-Devices
Here's more information from the author of Zadig: https://github.com/pbatard/libwdi/wiki/WCID-Devices
They mentioned below that they have their own devices they can control. As I understand it, for those kinds of IoT usecases the workflow is easier because, instead of overriding the driver defined by the OS, you can define WebUSB-compatible descriptor that will "just work" across all platforms.
>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?
Hasn't Windows 10 been a thing that's come and gone now in favor of Windows 11?
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)
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)
"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.
The numbers are quite easily available to check. On Steam, Win11 is at 10% vs Win10 at 81% (december 2021). Look at how long Win7 stuck around (it's still above 3%!) and back then, Win10 had actual benefits over Win7. This time, the upgrade is a regression across the board.
Yeah, 11 is currently just a buggy beta for some bad UI changes. That will hopefully change in the future, but right now it has basically nothing on its feature list to counteract the problems. If you don't use WSL2 then... there's better HDR support sometimes? And the android app thing doesn't count until it's in release builds.
For starters, Windows 11 has vastly better search, nicer UI, and improvements to multi-monitor support. I have no regrets about updating.
Multi-monitor support that...removes the clock from non-primary displays... Also still no sign of tray icons, keybinds for moving windows between monitors or anything else that was already possible since Windows 7 using DisplayFusion.
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.
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.
> vastly better search
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.
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.
You can't tell the taskbar to "never combine" in Windows 11.
That alone is enough for me to hate it.
That alone is enough for me to hate it.
Snap Layouts are also excellent.
>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-...
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-...
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.
>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.
"Support" refers not to the ability to make the installation, but rather whether or not Microsoft is going to spend energy making sure their OS works well on the given configuration.
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.
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.
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...
https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
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!
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.
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.
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.
Ah yeah, that should be easier! I was mostly coming from the perspective of trying to get DSLR working in the demo :)
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.
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. :(
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. :(
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.
> Safari/FF are the new IE
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.
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.
> 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
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
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.
Or, in the case of serial or remote debugging. Just run a terminal or gdb next to the target and connect to that instead.
No. Apple rejects almost anything from project Fugu as it pretty much closes all gaps between the web and native apps. It would violate their idea of the app store, not just in revenue, but also in control, deeper integration with apple-only features, etc.
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.
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.
The app store does provide a lot of traceability. If you get pwned via an app store app there’s someone’s door to knock on vs some random url you end up on.
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
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
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.
But for now, yeah, it has the downside of being Chrome(ium) only, which makes it far less useful than it could be.
> 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.
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.
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.
What 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?
> 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.
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.
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.
I’ll leave it to others to speculate on what happens to the website in 2 years.
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
if you want something else to complain about, this depends on chrome-only USB support
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.
> 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.
Which is the primary reason I will never purchase another Razer product.
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.
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 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.
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.
It seems this depends a lot more on the company policy rather than specific technology used for the implementation.
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.
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.
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.
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).
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
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.
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.
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.
Oh, that's great to hear. I might take another look at it then.
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.
This is also available in Microsoft Edge. Still, would be awesome to see support in Firefox and Safari!
> 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).
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).
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 :)
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 :)
The OSS community has an easier time supporting it than when there's only a crappy windows binary blob?
A crappy WebASM blob or heavily obfuscated JS blob is similar to a crappy windows binary blob, though.
Probably worse, because at least there’s well established tooling for reverse engineering Windows binary drivers, allowing for someone to eventually write FOSS drivers.
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.
I get what your opinion on the subject is but your example is hilarious to me since literally every time I have to download a device driver, it's on a manufacturer's website that looks (and performs) like it's been in continuous operation since 1986.
[deleted]
Btw, author of the port / demo / article here - happy to answer any questions you have :)
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.
https://caniuse.com/webusb
With that said, thank you for writing and sharing the article. It's interesting even with the above mentioned irritant.
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.
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.
WebUSB 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>, 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.
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.
Thank 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.
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.
It 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.
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.
The spec is not on the standards track at this time, but is in a place where that is the explicit goal (the I in WICG stands for incubation). Combined, these facts emphatically mean that it’s not finalised. The whole purpose of these standardisation processes is to get multiple parties working on something in order to produce a better result than any one party would achieve. I have two clear examples in mind, both from IETF rather than W3C, but the principle transfers: Google presented QUIC and Fastmail JMAP to IETF as complete, functional protocols matching what they had been using themselves, but there were some pretty radical changes based on other people’s feedback before each was declared stable.
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.
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.
Slightly tangential, but I still find it fascinating that it was Firefox OS was the first to introduce the idea of adding all sorts of hardware APIs accessible from JavaScript, or at least that was the first time I heard of that idea and played with it (and still have a ZTE phone from the time), but, after the Firefox OS was discontinued, they essentially stopped being interested in those capabilities altogether and started to even actively discourage others from exploring it.
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.
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.
Yeah, I’m sad that Firefox OS died.
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.)
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.)
> and I think that they were only exposing features like that to trusted code (meaning apps you deliberately installed) rather than general web content
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.
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.
Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous. I don’t believe installing PWAs currently exposes any new security surface, so this would be a significant change, and worse still a persistent hazard with probably no indication of what’s going on when it’s in use. I think there’s still potential in the general concept, but it’d take work and is certainly not ready yet in any browser.
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.
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.
> Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous.
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.
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.
> because it’s such a run-away-screaming scary idea for security
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.
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.
My main disagreement with you is not based on the soundness or otherwise of WebUSB functionally, but your position on it as a specification. Still, I’ll address the matter of WebUSB itself.
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.
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.
> It’s possible someone could come up with something like that for WebUSB, something that constrains it to something safe.
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.
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.
> 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.
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.
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.
I think I already made it clear in another thread why I'm not going to interact with your comments in particular. There's no need to try and post variations of the same comment throughout the tree.
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.
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.
> I'm perfectly happy to respond to questions and concerns of other people
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.
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.
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/
> 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]
> 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
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
> 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.
That's a really terrible argument, tbh.
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.
> 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.
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.
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.
Good day to you too.
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.
- 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.
For another third party perspective, I find your tone entirely appropriate, given that web.dev is a propaganda machine for Chrome. Pushback is necessary.
Pushback can be done with being so personal and insulting, and it's easier to read that way too.
Re-read the subthread. The only place he reacts is in the "non-constructive feedback". All the constructive feedback is promptly ignored.
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?
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?
Yeah I saw that the first time.
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.
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.
Just 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.
> all over the thread is not even remotely constructive
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?
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?
I'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 ;).
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 ;).
Glad 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.
One 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?
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?
I 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
Comlink takes care of the RPC part of any API, so you only need to choose and hook up a communication backend.
Comlink takes care of the RPC part of any API, so you only need to choose and hook up a communication backend.
This 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.
Ah, 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.
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.
Is that not a Chrome-only thing?
Why would anyone want to do this if it only works on one browser?
Why would anyone want to do this if it only works on one browser?
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.
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.
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.
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.
> 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.
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.
> 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.
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.
Sorry, 63% of browser usage is dominant, but not a monopoly by any means. The web is just as accessable on other browsers.
95% on Desktop being Chrome, CEF, or forks of Chrome is quite a bit higher than your number.
Only on mobile is it less, and only because of iOS Safari
Only on mobile is it less, and only because of iOS Safari
So? The web works just as well on other browsers. I swear this community would have tried to break up The Beatles because they had a "monopoly on music". Chrome is not a monopoly, it's just popular.
Part 2 is out: https://news.ycombinator.com/item?id=30165184
the 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?
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.
And as a side benefit, also makes it extremely easy to maliciously control hardware. A win for Google on two fronts here.
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.
Access to online banking requires two-factor authentication, a one-time password or a challenge-response mechanism with a secret key on a smartcard.
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.
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.
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.
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.
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.
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.
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 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.
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.
I 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...
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...
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/