
WebUSB is dead - hatemben
http://www.hbyconsultancy.com/blog/webusb-is-dead.html
======
anderspitman
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](https://anderspitman.net/19/#netcatable)

~~~
roca
> 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.

~~~
anderspitman
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>

~~~
roca
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.

~~~
anderspitman
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.

~~~
roca
> 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.

~~~
jancsika
> 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.

------
pedrovhb
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](https://configure.ergodox-
ez.com/train)

~~~
sayhello
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](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.

------
cjbprime
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.

------
VoxPelli
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...](https://android-
developers.googleblog.com/2020/01/flashing-android-open-source-project-
builds.html?linkId=81318357)

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

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

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

~~~
qubex
I think you’ve confused “ _so far has failed to take off_ ” with “ _dead_ ”.

------
semireg
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](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.

~~~
anaisbetts
> 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".

~~~
semireg
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.

------
Ecco
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!

~~~
schappim
Yeah, surprised Dang left it as is...

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

[https://caniuse.com/#search=Web%20Bluetooth](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](https://caniuse.com/#search=Gamepad%20API)

~~~
musingsole
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!

~~~
Keverw
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-...](https://superuser.com/questions/931188/how-many-devices-can-be-
hooked-up-to-one-pc-bluetooth-adapter-at-a-time)

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

------
schappim
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...](https://files.littlebird.com.au/Shared-
Image-2020-02-04-20-18-46-hMKf4)

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

------
emddudley
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.

------
pjmlp
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/](https://flash.android.com/)

------
oceanghost
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.

------
hatemben
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](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

------
chubs
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/](http://linuxgizmos.com/hackable-arm-linux-sbc-starts-at-9/)

------
fbn79
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...](https://stackoverflow.com/questions/44942495/getusermedia-and-webusb-
over-the-same-device-windows)). 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.

------
nimish
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-...](https://security.stackexchange.com/questions/118854/attacks-
via-physical-access-to-usb-dma)).

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.

~~~
zamadatix
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.

~~~
viraptor
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.

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

~~~
BoorishBears
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?

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

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

~~~
BoorishBears
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?"

~~~
zamadatix
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...](https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.html))

~~~
jdsully
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.

~~~
zamadatix
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.

~~~
BoorishBears
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

~~~
zamadatix
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 :).

------
shadowgovt
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.

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

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

------
ksbakan
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.

~~~
sowbug
It works on Edge.

~~~
loeg
Edge is either a dead end or Chrome now.

