Hacker News new | past | comments | ask | show | jobs | submit login
WebUSB is dead (hbyconsultancy.com)
63 points by hatemben 54 days ago | hide | past | web | favorite | 123 comments



I find the push to turn web browsers into VMs for running sandboxed JavaScript/WebAssembly applications fascinating. WebUSB, WebGPU, WebTransport, etc etc. I think it's really cool, and enables cool things, but I have 1 problem with it.

I wish we separated the browser application from the VM application. ie, let us make simple, secure content with HTML and minimal CSS. For things like Wikipedia and even a lot of YouTube that's all you need. People can use an extremely simple (and private/secure!) program to access this kind of content. A text version of my personal site is browsable with cURL or even netcat[0].

Make the VM a separate program that people use for fancy web apps.

[0]: https://anderspitman.net/19/#netcatable


I really wish this is the direction the web would go. This "browser as OS" stuff isn't something that I'm even a little OK with, and I'd love to have a browser that simply didn't have the support for any of it.


Viewing a document on the web needs to be decidable. The original design of the web was HTML documents with forms. This IBM 3270 style design used the browser as the user interface to server-side programs. The browser's job of presenting a document was decidable and the form submission, page load process allowed the user to understand and control the data sent to a server. The server learns what was in the form and URL when the user decided to click the submit button.

Moving the software into the browser improved latency, but questions like "Is this webpage doing something dangerous/annoying?" became undecidable. If we provably cannot determine if a webpage will halt without running it, we obviously cannot as any more complicated questions about the webpage's behavior. As long as webpages have access to a Turing complete language, the browser will be de facto an OS. Unfortunately, returning to a web of documents isn't going to happen anytime soon; too many people profit from this ability to run programs on other people's computers.

(Gary Bernhardt's amazing (and terrifying) talk "The Birth & Death of JavaScript"[1] was absurdist comedy, not a guide to future browser designs)

[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...


> Unfortunately, returning to a web of documents isn't going to happen anytime soon; too many people profit from this ability to run programs on other people's computers.

Yes, I've resigned myself to this truth long ago. Since then, I've been watching the web get smaller and smaller as more and more websites break unless they're allowed to run code client side.

I fully expect that the majority of the web will become inaccessible to me within my lifetime. Alas, the future does not always bring wonderful things!


Decideability is absolutely not the problem. Subjectivity is a problem - There is no objective definition of an obnoxious ad.

I mean, behaviour of a website may be undecideable. Behaviour over the 5 minutes you're viewing it is. I dont think notions from computability theory are particularly enlightening here.


There is no way to know for sure that the minified JS on a website isn't sending every keystroke you enter into a password field before you click submit, until you run the JS.


Why wouldn’t “deminifying” work? Then you just read the code.


Funnily enough Gary Betnhardt seems to only write and talk about javascript nowdays.


Deactivate javascript: Done


Yes, I do that already, but that doesn't remove the code in the browser. Also, I'd really love a JS interpreter that was restrictive enough that I could leave it on without exposing me to this stuff.


Not just an interpreter – unless there's a standardized subset that one can look for as a web developer then one can't really adopt to it (through either graceful degradation or progressive enhancement). Same reason why eg. Noscript addons creates havoc at times. Web sites expects a certain baseline and when it's not there, they expect that javascript will be disabled altogether and <noscript>-tags to get executed, but just disabling some code prohibits that fallback, making it less usable than fully disabling js.


Good point. I guess there's no real hope, then. I'll take the runner-up position in that case -- I want a browser that has no support for Javascript and the like at all. In the meantime, I'll just continue to leave it disabled.


Closest I can think of is efforts like https://jerryscript.net/ and https://duktape.org/ – but the challenge isn't in the language itself really, but in the web API:s that gets added to it.

Eg. Node.js doesn't have WebUSB either :)


And then you can't see the article, because its CSS hides the text and Javascript un-hides it; and people call you an extremist.


I wish there was a reader mode only browser. You would need to somehow extract navigational links though.


That's not a good way to handle it, harmful to the web :/


And then large swathes of the web stop working. Usually you're better off, but you're screwed if a site you need uses javascript to render its content.


Only problem with that is it breaks so many sites now. Most major sites I've tested without JS recently are borked.


And that is how it should be. All parties need to align on how the future of the Web will look. If most users want a site with fancy features, that's what developers will make, and that is what businesses will prioritize


> And that is how it should be.

Well, I don't think that's how it should be, but that's certainly how it's turning out.

How it should be is that websites degrade gracefully, and remain usable (if more limited in terms of geewhizzery) without client-side scripting.


And how do you expect that to happen? HTML hasn't been designed for that at all. Nowadays even extremely minor features require usage of JavaScript. For example a simple auto complete field that loads things from the database as you type. There is no way "graceful" way to implement this without JavaScript. There are some ugly ways that offer an extremely poor user experience (drop downs with 100000 elements) but those require additional developer resources on top of whatever basic feature you're building. You will also have to add a huge amount of forms and intermediate pages because of the limitations of HTML that will only be used by 1% of your user base and they will hate the experience no matter how much effort you put into it.

No, the ship has sailed. Just activate JavaScript and block ads/trackers.


> HTML hasn't been designed for that at all.

It absolutely has. That's a fundamental design goal for HTML.

> For example a simple auto complete field that loads things from the database as you type. There is no way "graceful" way to implement this without JavaScript.

True, so if the user doesn't have JS enabled, you don't do that. Omitting that functionality doesn't remove the ability to make use of the website.

You're arguing that making proper websites is too expensive to justify. That's your call, of course, but that's a different argument than "it can't be done".

> Just activate JavaScript and block ads/trackers.

No, that's too risky. What I'll do instead is not use the website.


> let us make simple, secure content with HTML and minimal CSS.

Browsers aren't stopping you or Wikipedia or Youtube from sticking to HTML and minimal CSS.

Your problem isn't with browsers, it's with Web developers who don't share your priorities.


Yep, but there is a bit of a chicken/egg problem. If someone created a wicked-fast, private, secure browser that worked with a subset of HTML/CSS, people could start designing their sites in a way that's compatible with both that and modern browsers. It would actually be less work for the developer because you need to become familiar with a smaller number of tags and properties. Over time hopefully bigger sites would make themselves compatible, and eventually you get a killer app like Wikipedia on board and the rest is history. </pipedream>


Sorry but this vision is totally unrealistic.

You're right there's a chicken/egg problem: no-one's going to use that fantasy browser, because it can't browse the Web. We know this because faster experimental browsers exist, and essentially no-one uses them. Even browsers with tens or hundreds of millions of users struggle to get Web developer attention, even when they're almost completely compatible with the dominant browser and don't require fundamentally rearchitecting, and arguably crippling, one's Web site.

Also, from a technical point of view, ripping out JS and DOM APIs does not magically mean you get a "wicked-fast, private, secure browser". It would be a lot more secure, but building a fast HTML/CSS rendering engine that still has to handle window resizing, zooming, incremental loading, editing and other interaction is still incredibly hard, in fact not hugely easier than supporting JS. (Source: I'm a former Mozilla distinguished engineer who worked on this stuff.) By far the easiest path to such a browser would be to take an existing engine and rip out stuff, and I don't think you're going to end up with something much faster. Disabling JS in a regular browser is going to give you most of the wins.


Everything is unrealistic until it becomes real. I naturally tend towards cynicism sometimes, but I try to practice dreaming a little. I find I'm happier when I try to imagine the world as it could be and what I can do to push it that direction.

True, general web layout is a hard problem. But there are a lot of knobs to turn. What if we removed CSS layout altogether, and only allowed linear pages, a la reader mode? That's a big tradeoff, but maybe it would work. If that's too much, maybe only allowing flexbox would be enough. As for editing, at that point you're making a web app.


> As for editing, at that point you're making a web app.

Are you getting rid of Web forms now? Also, remember that at the very beginning Berners-Lee's WorldWideWeb browser supported HTML editing, so it's definitely part of some vision of the "good old days".

Yes, if you cut down or eliminate CSS, or just redesign it, you could build a faster renderer.

But these questions point to one of major defects of the "cut-down Web" vision: lots of people have a limited set of Web features that they like, but they tend not to agree on what that set is. You like flexbox. Some people really like grid. Some people really need ruby, or floats, or columns, or editing, or vertical breaking (pagination). Pretty soon you've got something nearly as complicated as real CSS.


> But these questions point to one of major defects of the "cut-down Web" vision: lots of people have a limited set of Web features that they like, but they tend not to agree on what that set is.

Democracy to the rescue:

1. Start a FLOSS mailing list thread to get as much input as possible on the best starting point for this reduced set of functionality. Gopher, resurrecting Xanadu, revisiting Hypercard, and so on. Let the conversation flow.

2. Invite the people who chose Firefox Reader View to private gitlab instance and get to work.


I think getting rid of editability would be great. The whole point is a minimal browser. I don't really want to cut down the web. I want to start from scratch but in a manner compatible with our current JavaScript VMs.


I agree but a lot of the pre-flexbox stuff in CSS is just plain crap. However, I don't think removing obsolete CSS constructs will make anything faster or better because you're not forced to use them.


If you want to push the world in your direction, join a browser company. You may or may not be able to push them in your direction, but you'll at least understand the problem space a lot better to see where it's worth pushing.


You're talking about this from a value-proposition point of view. Whether something is worth doing doesn't depend only on the final value. It also depends on the amount of effort to do the thing. If the amount of effort is tiny, then it's probably best to do the thing and see what happens.


I share your dream, brother. This is why I design for every browser, with progressive enhancement.

The browser you describe already exists, it's one with JS disabled, and you ignore the sites which don't work without it. This is how I browse every day.

I don't feel like I'm missing much.

I enable JS for reddit because I have to mod things, but I find myself visiting that site less and less now. HN works. Facebook works (good enough.) Gmail works. Google Search and DDG work. GitHub... meh.


I can already see my own apps work without Javascript support. I'll convert video streams into permanently loading gifs and add 2 million invisible pixel sized form buttons arranged in a grid on top of the entire website so that I can send pixel coordinates to my server. Oh, and there will be a virtual keyboard made out of a form element so that there is no need to listen to keyboard events. There will be a huge spike in users who disable Javascript and they will flood my servers until the site crashes from the massive load.

I seriously hope this will never happen.


You don't need a new browser for that, people could use a small subset and have wicked-fast, private, (more than otherwise) secure sites today.

But the demand isn't that big, and the effort wouldn't have much return.


Sounds like you want browsers to have a restrict:GoogleAmp mode


Quite the opposite: Reader Mode. Reader Mode works on behalf of the user, while amp works on behalf of Google.


I was thinking more of the simplified HTML/CSS specification for AMP. Or at least that what I thought AMP was. I did a quick google search, first link was to the Google Amp guidelines, which has a link to ampproject.org. I can't get there, the browser won't let me because something is wrong with their SSL certificate (the cert's common name is firebaseapp.com, and it is serving up on amlpproject.org).


Dillo. Elinks.


Thats kind of missing the point. Original poster wanted a minimal browser that has lower security surface.

This is sort of like saying: Just because the computer doesn't have a password doesn't stop you from simply not using computers you're not supposed to. So your problem is not with the lack of passwords but with people who use computers they aren't supposed to.


I was really reacting to the phrase "let us make simple, secure content..." as browsers aren't "letting us" do that.

You can get most of the security benefits by disabling JS in the browser.


*it's users who don't share your priorities.


*it's Capital that doesn't share your priorities.


That too.


This is how the Web was originally designed, which is why we had Flash and Java applets. But it's hard to make those VMs secure, and yet somehow it's been easier to keep modern browsers reasonably secure as they keep adding features.


One problem is that browser vendors are using the complexity of modern browsers to create an oligopoly. When even Microsoft doesn't want to maintain their own browser, something is wrong.

A simple browser that only implemented a subset of HTML and the good parts of CSS (ie flexbox) could be implemented easily by a small team.


The driver is the desire by web app builders to build more and more niftiness into web apps. The browser vendors and standards bodies are attempting to satisfy this desire and that's leading down a path that is having the effect of creating an oligopoly because a browser must become this enormous OS-inside-an-OS. I don't think it's a conspiracy.

Most things that look like conspiracies are in fact unplanned outcomes that result from an unintentional alignment of multiple perverse incentives. A different way of saying the same is that most things that appear to be conspiracies are actually "emergent" behaviors in complex systems.

A different example of something similar is real estate hyperinflation. I don't think somebody sat down and said "lets make housing impossible for any family making less than 5X the local median income to reasonably afford." What happened instead was that multiple decisions made for independent and unrelated reasons created an aligned set of perverse incentives that drove the price of housing nuts. There is no one cause or one responsible party.


Flash reached a point where it was basically unmaintainable spaghetti, and not something that was going to be trivially reimplemented by a third party. Sadly, that's exactly what's happening to the Web now. Instead of being standards-first, and browsers implement it, we've basically shifted to descriptive standards that attempt to formalize what a corporate cabal unilaterally decides. And we're in inch away from a homogeny of browser engines...


Well multilaterally decide. Its a small group but firefox isnt totally irrelavent yet.

And thats ok in my opinion. The IETF describes itself as "rough consensus and running code" and it seems to work well. I dont have a problem with the web following that model.


You're not wrong, but people have been pointing these issues out for years, and browser vendors are very aware of these opinions, and have taken no serious action I can see to realign their incentives.

EDIT: But that can also be explained by incentives+emergent behavior. So at the end of the day, you're simply correct.


There's no mystery to it. Look at Firefox. It's actually not more secure than old Java used to be. It has CVEs all the time. Chrome constantly patches security bugs too.

The difference is they have much more aggressive automatic upgrade processes than Flash or Java did, so bugs remain usable for way less time. And Chrome did sandboxing.

But Firefox doesn't/didn't. It got a free pass from the community because Mozilla is somehow seen as "not a corporation" and did a lot of drum beating about openess/webbyness/etc. So people gave it a break although the architecture wasn't really any different to something like Java applets and if anything was much worse.


HTML clients & standards have stagnated badly because we know javascript and heavy-handed CSS can work around any problems—even if those solutions are almost always bad (usually: highly janky, at least).

Example: Table sorting. Hell, maybe table pagination, too.

This is part of why developing HTML-based UI still seems so weird and shitty compared to native, even with the aid of Javascript. Those native SDKs provide way more support for common, basic use cases. Even within the narrow scope of rich document format & display, HTML without Javascript is crippled (see again: super-basic and common table functionality). Plus you'll get a hell of a lot better performance letting C/C++/Rust handle those kinds of basics, rather than trying to re-create them in CSS and Javascript.

Another example: there's a clear, fairly common need for tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag. To get that whole thing. A couple properties to enable/disable things like zooming. Some sensible standard for how to request tiles by X/Y at a given total canvas size (so, just a convention for image URLs) so that just has to be implemented once per server-side language, and can easily be pre-generated and served from actual files. A way to drop other elements on the image at some X/Y value for pins or linking people's faces to wikipedia entries or whatever, kinda like old school imagemap elements. That's clearly useful even for document-centric usecases (aside from maps, consider, say, ultra-high-res images of painted church ceilings). The browser and HTML should include that.

Search. Complete- or hint-as-you-type search fields should be a built-in element, with results from local or remote (some convention for the URL) markup-based sources.

There's a ton of stuff like that which, in 2020, really ought not require Javascript. Lots of which are still basically rich-document UI elements that've been in demand for 15-25 years at this point, with the holes filled a thousand times over at great cost in person-hours by slow, janky, battery-eating JS and CSS. And that's not even considering overhauling HTML to better suit use in "applications", which could also be done and arguably should be done, since we've pretty much lost the battle to keep that from happening.

I'd love more of the Web to be Javascript-light or -free, but modern HTML standards & clients aren't really up to the task. Mostly because (I think) Javascript has freed them from having to worry about it. "Table sorting by column? Well yes of course everyone wants that basically everywhere all the time, but let Javascript handle it".


> tiled dynamically-loading images, as in maps applications. That should be a tag, and... that's all. Just a tag.

You say that, and then you disprove your point by going on to list a bunch of extra features that that tag would have to have. And even with those features, major map sites wouldn't use it because they render map content client-side using vectors, not map tile images, and have lots of other features your tag wouldn't support.

Implementing your vision would mean a massive increase in the API surface of browsers, with concomitant increase in browser bloat, and browser and standards development effort ... while there's a strong argument that browsers are already too complicated.

Even so, when we've tried to implement declarative features on the Web we've seen over and over again that it's impossible to satisfy everyone's needs without scripting. (See e.g. HTML5 form validation, SVG vs canvas, VRML vs WebGL, ...) That is why stuff like the Extensible Web Manifesto emerged.


I’m pretty sure CSS, JavaScript, and the way both interact with each other and with HTML are the main reasons writing a useful browser engine is rapidly becoming impossible—and we’ll end up replacing it with Wasm rendering to a canvas for most things while not cleaning up HTML to be something simpler and delightfully less-capable, sadly. I think you could significantly increase the richness of just HTML without making it, per se, 1/10 the challenge of implementing all of those together.


The interactions between JS, CSS and HTML are not the main problem. The main problems are:

Feature interaction complexity between CSS features is a huge problem. Some of that could have been avoided if CSS had been designed differently, but some of it seems unavoidable (e.g. laying out text with mixed directions, mixed writing modes, ruby, font substitution, modern font features, etc etc --- at speed --- is just really complex).

Modern high-performance JS is really complicated to implement.

The plethora of APIs exposed to JS --- WebXYZ --- is incredibly complicated.

HTML is pretty complicated, e.g. HTML forms.

But if you take away JS, CSS/HTML don't get a whole lot easier, assuming you're still supporting interaction in some way. I mean, for your proposed map API, if the user can manipulate the functionality and you have lots of features that can be customized declaratively, it's not much more complicated to expose those controls to JS.

If you can simplify the problem so that CSS and HTML don't need to support incremental relayout/DOM changes, that would help a lot, but removing JS isn't enough for that. Things like zooming, window resizing, incremental loading, and any kind of editing put a lot of the same requirements on the engine.


This is a great point. You definitely couldn't implement every thing with just HTML/CSS. But I think you could do a lot. In some cases you would definitely have to resort to old-school methods like literally paging your content, which isn't ideal, but maybe worth the tradeoffs.


And it's entirely possible to do that today. Things like WebUSB require permission prompts, which you can say no to or disable entirely.


That text protocol is pretty much what HTTP looked like originally[1]. If you just support an optional "GET " before the document path, you'll essentially have an implementation of HTTP 0.9.

[1] https://www.w3.org/Protocols/HTTP/AsImplemented.html


Yup. Once I got to the point I was considering adding support for range requests for streaming videos, I figured it would make more sense to implement a subset of HTTP. HTTP started as a pretty dang good protocol and I really hope we never full ditch HTTP/1.1 in favor of the newer binary versions. I'm all for progress, but simple things should remain simple.


I agree, but at this stage the Chrome VM has won.

Safari is still relevant due to iOS and iPad not macOS, and although I mostly use FF privatly, it is seldom a project acceptance requirement to also validate against it.

Ironically it were the IE haters that kind of helped this to happen.


You used to be able to do this:

https://en.wikipedia.org/wiki/HTML_Application


Don't laugh but I made one of these last year, just needed something dead simple.


For a more modern solution, you could use PHP or similar:

https://cup.github.io/rosso/html-application


No, I mean I made something that I didn't have to install anything for. PHP wasn't on the machine. But I could do .hta. Boom.


And now we have electron. Everything old is new again.


Not exactly related but you might enjoy curling this website: https://wttr.in


So what you're saying is we should build a browser inside the browser sandbox?


I just got an Ergodox-EZ (ergonomic split keyboard which takes some adapting to), and their helpful training tool [0] leverages WebUSB (which I didn't even know about before I started using it). It's useful because it can talk to the keyboard to find out what's the current layout and layer, and show you the relevant info and keys being pressed.

From my point of view as a user: on one hand it kind of sucks because I use Firefox as my main browser, and launching Chrome/Chromium every time is a bit out of my usual path.

On the other hand, I appreciate not having to install something on my computer just for this. It's nice for small apps that you won't be interacting with that often or for too long.

[0] https://configure.ergodox-ez.com/train


And it's nice that the web app only has a narrow set of permissions.

You could imagine the same for an unzipping app. It theory, an unzipping app doesn't need anything else than specific file system permissions, i.e. read for a specific set of bytes and write access to a specific filepath.

https://github.com/GoogleChromeLabs/unarchiver

I work on the Capabilities team on Chrome and I think it's pretty cool the web can do more, and provide safe experiences for users.


It seems bad form to declare something is dead when you didn't work on it directly, and other people clearly are working on it as evidenced by the latest version of the spec being less than two months old.

I don't know whether WebUSB is healthy or not -- but the OP clearly doesn't either.


Google themselves just made it possible to flash Android devices from within the browser, by using WebUSB: https://android-developers.googleblog.com/2020/01/flashing-a...

I interpret the definition of "dead" here to be:

  No other implementation than the one in Chrome
Rather than:

  No implementation or spec work at all


I sure consider anything only working in one browser to be dead.

Now that might change as we soon will only have one browser.


I think you’ve confused “so far has failed to take off” with “dead”.


I would say it's "bad", but "dead" isn't the right term for me in that case


This topic fascinates me because I've successfully built an app and business around an Electron app (no Linux, yet) that connects to USB devices on Mac and Windows. The app uses native node modules for USB (not chrome).

I've been successful using these npm modules: "@nodert-win10-rs3/windows.devices.custom" and "enumerated" on Windows and "usb" on Mac. Interestingly, "usb" relies on libusb which isn't really an option for the common Windows user.

A naive developer will read about WebUSB and think, "oh, Electron is Chrome, so this must be a good solution!" but remember that Electron apps consist of one node process (main) and multiple chrome processes (renderers, aka, BrowserWindow objects).

In my experience, it is poor design to exclusively connect to USB hardware using a BrowserWindow. Instead, it's much better to use the main node process to handle all exclusive USB access, and then push state to renderers using IPC.

So, once you go down this road you realize that WebUSB on Electron isn't viable. The idea seems good, but was dead on arrival for me. Your mileage may vary.

Ten years ago I would never have identified as a hardware-focused software developer. Now it's become part of my professional identity. My speciality is Electron/USB. You can check out my USB-heavy Windows/Mac app at https://www.label.live. I'm available for consulting if you have a need for custom desktop software that talks to hardware. I've solved dozens of incredibly difficult problems over the last few years. Super fun.


> Instead, it's much better to use the main node process to handle all exclusive USB access, and then push state to renderers using IPC.

You should absolutely not do this - don't do anything in the main process at all; blocking it even a little bit makes your entire app janky and hang'y. If you want to connect to USB hardware in an isolated context, create a hidden renderer process (aka a BrowserWindow that you don't call `show` on), though tbh I would just use your existing BrowserWindow, I'm not sure why you immediately dismiss it as "poor design".


You’re assuming the USB read and writes block, but they are in fact async and work quite well for this purpose. My app is document-based so the user may have multiple label designs open. Because of this, USB is handled from a central location. That could be another renderer, but then you have to shuttle data from renderer to renderer (via main) which in and of itself becomes laborious.


Very good looking app, but please adding pricing to your website.It took far to many clicks on my mobile device to figure out the in-app purchase costs around $48, and even then I don't know if that is a subscription or not. The price is reasonable no reason to hide it.


The title is completely misleading. It should read "I couldn't use WebUSB".

And WebUSB is by no mean dead. Geez, it just got supported by Microsoft in the last version of Edge!


Yeah, surprised Dang left it as is...


Looks like Web Bluetooth is more supported. Surprised Firefox doesn't support it.

https://caniuse.com/#search=Web%20Bluetooth

I know you can connect game controllers to your computer, but maybe that uses the Gamepad API instead. Haven't dug too much into that but was playing with a Babylon Demo and thought the camera controls with a Xbox One Controller was a bit nicer than using my mouse.

https://caniuse.com/#search=Gamepad%20API


I think Web-Something is going to be critical for the next few years of IoT development. WebBluetooth looks like an obvious candidate, and if it works, the niche for WebUSB gets smaller.

I've played with WebBluetooth some and hope it gets more love!


Only bad thing is apparently Bluetooth spec has a connection limit. Sounds like it's 7? So sounds like some people might be pushing close to that...

Say they have their Magic Mouse, Magic Keyboard, Airpods(probably counts as 2 connections) and then sometimes the case status shows up too. So 5 connections. Looks like the limit is 7, so some are pushing it.

[0] https://superuser.com/questions/931188/how-many-devices-can-...


I wouldn't count WebUSB dead yet. People lament the death of WebSQL but https://caniuse.com/#feat=sql-storage points to 77.59% availability despite having been "killed" years ago


WebUSB is very much NOT dead. We use it every day in the latest version of Chrome w/ our WebUSB Printer and Scales in Chrome Version 79.0.3945.130 (Official Build) (64-bit) and Edge.

The website's comment system is what is dead. Getting a 403 when posting a comment: https://files.littlebird.com.au/Shared-Image-2020-02-04-20-1...


The title here is pretty misleading. WebUSB certainly isn't dead, but it's true that Google are the only ones pushing it forward.


I write a lot of engineering and test software that interacts with hardware. Generally it communicates over serial or UDP. I package the software as an executable that gets installed on lab PCs.

There is a lot of configuration management. An operator has to use the correct build of software, and needs to configure the software with the appropriate settings. After some testing he needs to save off the data to the appropriate places for analysis and archival.

It seems to me that this type of application would be appropriate to implement as a web application. This would help me manage deployments better and would automate the CM/data flows.

I have been casually monitoring the Web Serial, Web USB, and Web Socket APIs, since they would enable me to implement the low-level communications I need. The opposition to these standards bums me out, but I keep hoping that the security concerns can be resolved and that attitudes will change.


Great discussions and apologies as I am checking this very very late. The purpose of my post was not to create buzz as some of you mentioned. I have been in the web industry since 2001 contributing in open source community, and author of an online PHP magazine since 2005. creating buzz was somehow part of my business, but not this time.

WebUSB was really a very cool approach to connect Web to USB devices in spite of all the security issues that you may or you may not face. I had the chance to work on it and see its limitations two years ago. I found out very small of successful implementations and solutions (Google use it to flash Android from the web, finally (: ).

To make this thread more interactive, I am adding a proof of concept of a code generator to generate WebUSB code :-) https://github.com/hatemben/usbmon

Feel free to fork/test and play with. It's true that there are tons of security issues related to WebUSB, and there are always solutions to security issues. For me WebUSB is dead two years ago, I just remembered to announce it last week.

-Hatem


WebUSB is pretty much alive on the Chrome VM.

The last week's released Android Flash Tool, makes use of it.

https://flash.android.com/


About ten years ago, I wrote an IE/win7 plugin that broke the security model of IE to allow the browser to communicate with a USB device (in this case, a remote control).

It was a nasty, nasty hack, and things like this shouldn't be allowed. Management insisted that our product have a web-interface because they had information that our competitor was going from desktop apps to web apps. Ironically, our competitor was never able to get its web interface working.


You'd flash the (now-defunct) Chip SBC using Chrome - I always wondered how that worked, it must have been WebUSB! It worked brilliantly. Pity the tech hasn't found much take-up. I can imagine use-cases for it are scarce.

http://linuxgizmos.com/hackable-arm-linux-sbc-starts-at-9/


Currently using it in a commercial project to control microscope lights form a web-app. Works on Linux and MacOS. Not on windows because Windows cannot see the device as a Webcam and a generic USB endpoint at the same time (my old StackOverflow question https://stackoverflow.com/questions/44942495/getusermedia-an...). In the beginning the project was born to run on vanilla Google Chrome but now is distribuited with NWJS. I would really love to see a definitive good WebUsb crossbrowser API spec.


WebUSB sounds like a truly gaping security hole. Imagine exploiting USB drivers over the web (yes, even though USB doesn't require DMA support, the drivers operate on a very low level -- https://security.stackexchange.com/questions/118854/attacks-...).

WebGPU is more useful but direct access to hardware that could have coherent memory access/DMA is just irresponsible.

Chrome needs it for chromebooks. Not sure why it's needed for less constrained machines.


There are 2 worlds on the web, what a page can access simply by going to it and what a page can access when you grant it permissions after it asks. The latter is where WebUSB falls, I call it the realm of the web app, and is no more risky (arguably less due to design) than the current "do you want to download and run nativeusbapp.exe" permission.


It moves the target for user education yet again though. You know how we get the "allow notifications" popup everywhere now? Recently someone spotted a page which tries "to verify you're human, click allow on the notification".

If we spam users with requests like that and lose control of simple things, there's no chance for us to ask a meaningful question about webusb. I've seen this on my mom's mobile phone. It's full of news notifications that annoy her - because she defaulted to clicking "allow", because she's a typical user.


The WebUSB popup asks you to select the USB device per session not allow/disallow all devices for all sessions.


So I know of a very popular keyboard controller than can be made to run unsigned code by sending it the right HID data.

Said code persists after reboot.

Please point out if this attack is not viable:

Ask for permission to use your keyboard. No matter how scary the warning, non-technical users will allow a website to use the keyboard because "of course it needs a keyboard"

Upload a malicious payload to keyboard. Remember, now it can present itself as any USB device. Or maybe stay simple with a keylogger, maybe with heuristics to get juicy data (what are the first 20 characters typed at boot and after "www" is typed)

Game over?


Nope, the first 3 (plainly written) sections of the standard will tell you why if you're curious https://wicg.github.io/webusb/#introduction

The upcoming WebHID API considers and mitigates this attack as well https://wicg.github.io/webhid/#introduction


Excuse me, what? Please explain your reasoning.

(And yes I read the section 3 of the standard before writing the comment above, see my other comment in this thread)

WebHID even says it more plainly:

> In general, these types of attacks are device-specific and cannot be mitigated at the API level.

Both documents you linked literally go:

"We know these attacks exist, we don't care as long as we show a prompt, device manufacturers fix your shit it's not our problem"

-

I can't reply for some reason but:

I didn't see any mention of HID devices not being listed, not was it immediately apparent that a HID device would already be held in the kernel context

I also still don't see blocking input from trusted devices, I see the same language I called out:

"Device manufacturers should watch out"

-

"I think it works like this, why doesn't it" is a great way to learn things, except when the reply is a low effort: "here's that thing you read, did you actually read it?"


Going with the good faith assumption you read it trying to find why instead of why not in the WebUSB standard you can find this paragraph under 3.1 Abusing Access to a Device:

"Lastly, since USB devices are unable to distinguish requests from multiple sources, operating systems only allow a USB interface to have a single owning user-space or kernel-space driver. The UA acts as a user-space driver, therefore allowing only a single execution context to claim a USB interface at a time. The claimInterface() function will fail if multiple execution contexts attempt to claim an interface."

I.e. the keyboard couldn't be claimed even if you managed to get it to list as it's claimed via the OS HID driver so can't be claimed via the userspace driver. HID devices are also hid from the listing (no pun intendend) which is what resulted in the WebHID standard in the first place.

For WebHID understand it's an early draft and that the method described in section 3.1 of blocking access to HID devices that can generate trusted input is actually the go forward implementation plan not merely a suggestion.

.

I don't mind discussing WebUSB further but not if the conversation is just going to be in a "I thought it might work this way, show me the line that says it isn't" way. There are many blog posts that cover it better than I could anyways (such as https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.h...)


That may be obvious if your used to USB, but it's actually quite a leap otherwise. An explanation in your original post would have gone a long way.


Just to clarify I'm no expert in USB in any way, shape, or form and do not wish to claim to be. I have never worked with USB (beyond quite literally sticking a device in the port or reading about which USB storage drive to get) prior to reading the original article this post linked to and don't want to give the false impression I'm an expert in the field because I've read a few documents/demos followed by a couple of blog posts after.


My original reply:

I didn't see any mention of HID devices not being listed, not was it immediately apparent that a HID device would already be held in the kernel context

I also still don't see blocking input from trusted devices, I see the same language I called out:

"Device manufacturers should watch out"

-

"I think it works like this, why doesn't it" is a great way to learn things, except when the reply is a low effort: "here's that thing you read, did you actually read it?"

Also I'm pretty sure the parent's point is jumping from "the kernel and userspace are not allowed to both access a device" to "keyboards cannot be accessed" is non-obvious

I still don't see where the filter on HID devices is mentioned, or the exception for trusted devices


Note on reply disappearing: I think sometimes HN hides the reply unless you go to the permalink (i.e. what the "2 minutes ago" link points to). Or at least that's how I work around it when I don't see the reply button. Not really sure why it does that, never looked into it.

It's not so much about the HID class itself as "why" (it's more an effect you find out later once you know what the HID class is) as it is "if an OS driver doesn't already hold the USB keyboard how could you type on it". The opening paragraph of the standard tips this off straight away:

"...Standard device classes include keyboard, mice, audio, video and storage devices. Operating systems support such devices using the "class driver" provided by the OS vendor..."

That combined with the closing paragraph of 3.1 under security considerations I quoted before led to the answer for the particular question without the explicit mention of "HID" in the document:

"Lastly, since USB devices are unable to distinguish requests from multiple sources, operating systems only allow a USB interface to have a single owning user-space or kernel-space driver. The UA acts as a user-space driver, therefore allowing only a single execution context to claim a USB interface at a time. The claimInterface() function will fail if multiple execution contexts attempt to claim an interface."

I later ran across "HID" reading a blog post while testing some code which is how I fumbled to finding WebHID. For the WebHID portion the hint I originally mentioned came from this paragraph in 3.1:

"In some cases, a device may expose functionality that should not be accessible at all from a web page. Specific devices may be blocked by recognizing the device by its vendor and product ID and hiding such devices during enumeration. The HID report descriptor allows a device to describe its own capabilities, and this information can be used to block classes of devices even when the vendor and product ID cannot be known in advance. This can be accomplished by inspecting the usage values assigned to collections within the report descriptor; for instance, access to keyboard-like devices can be denied by denying access to devices that include a top-level collection with the Keyboard usage ID."

I guess "mitigates" wasn't fair as the feature still hasn't even had an experimental implementation added behind a flag in Chrome yet let alone have a demonstrable implementation of the proposed protection. I'd say "considered" was fair though and not at all hidden/hard to find.

I also wanted to point out that the wording around "manufacturers should do" in both is presented an argument for defense in depth (IIRC they even called out defense in depth explicit in one of the calls to action) not their argument for "since manufacturers should do this we shouldn't do anything". Again about reading to find "why" vs "why not" which usually requires reading in context instead of searching for a key phrase.

.

Don't get me wrong, questions are a fine method of learning! It's just your initial question was "Please point out if this attack is not viable" not an ask of "I saw this in the standard, can you explain why this attack is not viable?" so I told you it's not viable and then mentioned it's in the first 3 sections in case you were curious. The response I got back was that you had already read section 3 and got a different takeaway. Well of course you did, I didn't say why was in section 3 I said it was in the first 3 sections, which are quicker reads than the comment chain the question came from! Going on good faith I pulled the exact quote out, explained it further, and then mentioned "I thought it might work this way, show me the line that says it isn't" isn't how I want to talk about the standard to then get told my original comment which answered exactly what you asked was low effort! Looking back I can see the confusion with section 3/first 3 sections and that originally you very likely meant "could you explain why" not a literal "is it or not" so my apologies for misinterpreting where you were trying to drive the conversation but I ask you consider the above as well before judging my reply/cautiousness to be just low effort/dismissive.

Anyways I hope the content above the "." gets us on the same page. I'd have shared some modified WICG/webusb GitHub repo linked demos I worked on earlier to validate my understanding before I said "nope" but they don't work on JSFiddle/CodePen because WebUSB requires a feature-policy header to be set to be used in a page + "allow" to an iframe (which seems like other great protections but absolute pains for testing!) so you'll just have to take my word on the real world test :).


Which keyboard controller, precisely?

Have you reported the issue to the maker?

Has the responsible disclosure window elapsed?


It's very different because way more users (not all users) will pick up on the fact "this website wanted to run an unannounced exe after a totally unrelated action, and that is bad"

Than will pick up on "this website wants to use your keyboard"

Your tech illiterate users fall for the former, but many people with just average technical knowledge would fall for the latter.

"This website uses your keyboard directly to secure your password, press yes when presented with the dialog"


> is no more risky (arguably less due to design) than the current "do you want to download and run nativeusbapp.exe" permission.

I'm nervous about justifying one thing based on the fact that a different, objectively terrible, thing is allowed already.


What's so terrible about using USB devices? I have my crypto token with USB interface and I'm using it to interact with website. The only alternative is to store private key in file and it's worse.


The terrible thing I was referring to was the prompt asking users if they want to execute a binary they just downloaded.



I did literally last night (what a happy coincidence!) and it gave me a great laugh

"We identified the biggest security problem with this, but to get adoption we're going to rely on prompts (which we all know users pay attention to)"

Then the next section is:

"We know how the previous shortcomings can be exploited to pwn the host too, hosts, don't let yourselves get pwn'd k thnx"

What feedback is there to give, they know what's wrong, they just don't care.



Isn't that a play by play of exactly what I described?


It's up to them to prove that WebUSB is secure, not on me to prove it's insecure. Direct hardware access over the web is inherently dangerous.

If they have a way of truly sandboxing malicious uses, without entering into permissions request overload (no human is infallible), I'd love to hear it.

the "discussed at X f2f" is not filling me with confidence.



And here's a PR for adding that to CanIUse: https://github.com/Fyrd/caniuse/pull/5262


WebUSB sounds like a truly gaping security hole

"Greetings, Rando Middle Manager. Your cousin Larry has been arrested by police in Elbonia. Please to pay US$500,000 into this Bitcoin account to free hime. Or if you do not have funds, plug in company secure USB drive and click OK."


Ah, that's inconvenient.

A probably-viable (but also inconvenient) alternative is to code your own bridge: a server that talks the relevant USB protocol in the host OS and exposes an HTTP endpoint that a browser can connect to. More complicated than having the browser just be the bridge, and it introduces the significant risk of mis-implementing the security model and leaving your hardware open for remote-zombification though.


Meanwhile, I just used WebUSB to flash an updated version of the firmware to my NumWorks calculator.


Super clickbait title. It's not being removed from Chrome...


Why does the site need a loading bar to display a text only post?

It sucks that webusb is cjome only, but there are definitely at least a few projects using it.


It works on Edge.


Edge is either a dead end or Chrome now.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: