
WebUSB API: draft spec to safely expose USB device services to the web - fitzwatermellow
https://wicg.github.io/webusb/
======
pdkl95
Apparently some people are _trying_ to open up as much attack surface as
possible.

If you're implementing this... please _stop_. This _will_ cause serious
problems. There is no reason whatsoever to allow remote access to USB devices.

~~~
nailer
The same logic could be applied to local software, which inevitably is also
remote in origin.

At least browsers generally have a better permission model than desktop apps:
"do you want to allow this web page for access to USB devices?".

~~~
asjfkdlf
I am not sure I agree "browsers generally have a better permission model than
desktop apps". Yes, browsers ask the user if they would like to allow, but do
desktops apps have rampant XSS vulnerabilities? If you allow a site to use
USB, you have to be worried that any XSS vulnerability will compromise your
USB devices.

~~~
nailer
Weirdly enough I was talking a couple of days ago about requiring things like
CSP (which would go very far in defeating XSS) for stuff like webcrypto and
other sensitive bits of HTML5.

Someone working for one of the major browsers mentioned they'd considered it
but decided against it - not sure on the reasons why but if they're reading
this they might like to elucidate...

~~~
asjfkdlf
That would be a good first step. It would have to be a subset of CSP. Don't
allow inline scripts or eval.. Only on https is another step I see as very
important.

------
sillysaurus3
This spec is one of the most interesting features to come to the web. I can
think of at least three ways I can use something like this to deliver
interesting experiences to users, which would not otherwise be possible.

Yes, it increases the attack surface. This is a real danger, and should not be
taken lightly. But no one is taking it lightly.

Another danger, which I haven't seen mentioned yet, is that it increases your
fingerprint. If a website can list the Web USB devices currently connected,
that's a way to deanonymize you.

But if you set aside those negative qualities, WebUSB, I think, is one of the
more important features on the horizon.

For example, I could build and ship a light sensor. The idea is that you'd
connect it to your laptop, and websites would be able to react to your
environment's lighting + your current screen brightness. Think dynamic color
schemes that always look good no matter what kind of monitor you're using, or
whether it's night or day. This is only possible with hardware; no amount of
software will make this feature available. And I can't think of any convenient
way to do it other than WebUSB.

~~~
castis
You might find this interesting, Mozilla is working on an ambient light sensor
API. [https://developer.mozilla.org/en-
US/docs/Web/API/DeviceLight...](https://developer.mozilla.org/en-
US/docs/Web/API/DeviceLightEvent)

~~~
sillysaurus3
[https://w3c.github.io/ambient-light/#dom-
ambientlightsensorr...](https://w3c.github.io/ambient-light/#dom-
ambientlightsensorreading-illuminance)

Unfortunately, it looks like their definition of brightness is a floating
point number, and that's the only thing their API exposes. Hopefully future
versions of the standard will be updated to better match the real world.

What we perceive as brightness is (a) the number of photons of each wavelength
that (b) intersect a given point in space and (c) are exiting in a given
direction. Obviously, all of this information can't be encoded in digital
form. There's simply too much data to encode, let alone measure accurately.
But reducing the data to a simple 1D number renders the data almost useless.

No website will be able to achieve good results if the dynamic color scheme is
based on a single number.

That's also why the WebUSB spec is exciting. I don't have to wait for this
spec to be drafted, or for browsers to support it, or to live with any
shortcomings it ships with. I'm free to create.

~~~
robbles
What kind of physical sensor are you proposing that would give you data like
that? I think most ambient light sensors in laptops are just LDRs, which are
only capable of giving you a 1D number.

~~~
sillysaurus3
I propose that this is a capital-H Hard Problem, and that new technology is
needed to address it. I further propose that this technology exists, but is
not yet mainstream. The fact that monitors can be calibrated to great accuracy
is proof that the tech exists.

There is an opportunity here, but to understand this space, you have to dive
into it. There are some excellent books on the subject of colorimetery, but a
quick bootstrapped understanding might look like:

1\. Your eyes are designed to fool you.

2\. How your eyes fool you is determined entirely by the photons that enter
it.

3\. Each of these photons has a wavelength. The more of them at a given
wavelength, the more your perception shifts.

4\. What you perceive as color is a combination of wavelengths. But --
critically -- these combinations affect each other. It is _not true_ to say
that the more photons that arrive at a given wavelength, the more intensely
you perceive that wavelength. It causes a shift in your perception, but this
shift is not necessarily a simple increase in brightness.

These are first principles, and it's a very brief sketch of the problem. But
everything else follows from this. What ambient light sensors currently do,
how APIs are designed, etc is all secondary. The problem is both as simple and
as difficult as outlined above.

Now, you can say that this isn't worth tackling, or that the current systems
are good enough, and so on. But you'd be missing out on quite an experience.
Seeing the type of results you can get from a perfectly calibrated environment
is really mindblowing. And the interesting part is, it's impossible for me to
describe these results in text, or by showing you a photo, or a video, for the
same reason you can't describe an Oculus experience. You have to be there.

Personally, I find colorimetry one of the most intellectually fun and
gratifying areas of science.

------
roflc0ptic
So I see a lot of negative comments about the security implications of this.
Presuming that the browser gates access to USB devices in the same way it
gates access to geolocation, what's the risk here? How is it different than
installing 3rd party software on your OS?

I've read about the "inner platform" effect, and I don't know. I'm just not
convinced it's a bad thing here. For all its warts, the web is far and away
the best cross platform application delivery system. Use this in conjunction
with things like IPFS and browser based persistent storage, and can run signed
versions of trusted, auditable code that can do lots of awesome stuff. Without
users having to futz with installers.

What am I missing?

~~~
userbinator
_Presuming that the browser gates access to USB devices in the same way it
gates access to geolocation, what 's the risk here? How is it different than
installing 3rd party software on your OS?_

Except that most people will easily dismiss the "are you sure" warnings to the
point that I could see browser developers eventually defaulting that to
enabled and not asking ("it's for better UX!")

The desktop is unfortunately moving in a similar direction (witness all the
telemetry in Windows 10, etc.) but there at least seems to be a greater notion
of user control than with what browsers are turning into.

~~~
Klathmon
Are there any examples of that happening on the web yet? All browser vendors
agree that most of these new features need to be behind explicit permissions.

Hell people are still complaining about full screen permissions pop-ups and no
browser has gotten rid of them yet because they know the problems that could
come from it.

If anything there is a push to go the other direction, making previously
"enabled by default" things behind permissions.

~~~
userbinator
It's really just a general trend of removing and/or hiding things that might
be useful for the user to make a decision of what to do:

[https://news.ycombinator.com/item?id=7677898](https://news.ycombinator.com/item?id=7677898)

[https://news.ycombinator.com/item?id=5968237](https://news.ycombinator.com/item?id=5968237)

You're right that they're (ostensibly) placing emphasis on permissions at the
moment, but I don't see that staying the same if websites start adopting and
using these features in any quantity.

------
fidget
`First, so that the device can protect itself from malicious sites it can
provide a set of origins that are allowed to connect to it.`

Sounds kinda DRM-ey. The CORS system works because the owner of a URL is the
person who can attach headers to responses. That doesn't sound the same in
this case, as the owner of a device is the person who owns it, not the
manufacturer who decides what metadata it broadcasts (though obviously working
out what the UX should be is a hard problem)

~~~
justinschuh
This particular restriction is intended to address things like authentication
devices (e.g. gnubby) where you basically destroy the entire security model if
a user accidentally allows a malicious website to connect to it.

That stated, the last round of discussions gave me the impression that
browsers generally (and in particular Chrome) are leaning towards implementing
this as a very alerting warning rather than an outright block.

------
orf
Oh boy, I can't wait for the first exploit involving this to hit.

------
vbezhenar
It would be nice if this spec would be implemented in major browsers allowing
access from JavaScript to USB crypto tokens.

In my country (and, AFAIK, in many other places) those tokens are used to
provide some government services which require digital signature. Few years
ago Java applets were widely used to provide that functionality. There's no
other way for JavaScript to access crypto token. It wasn't that smooth, but it
worked. Now, when Java applets started to disappear in major browsers,
websites require you to download a program which must be run, it listens at
local port and website uses websocket to communicate with that program. This
process becomes much more complicated for user, especially for non-Windows OS.

If JavaScript would be able to access USB crypto device, the whole user
experience improvement would be huge.

~~~
gst
Chrome Apps already have USB access:
[https://developer.chrome.com/apps/app_usb](https://developer.chrome.com/apps/app_usb)

------
nly
This is actually pretty exciting. I can see being able to plug in to an
arbitrary computer and visit
[https://www.yourdevicemanufacturer.com/](https://www.yourdevicemanufacturer.com/)
to manage your personal devices really taking off. No drivers or shitty apps
to install or update? This will be huge.

I can see why people would be concerned about attack surface, but if you're
plugging your devices in to foreign USB ports, then you're potentially 0wned
already. At least this way, if it's done right with regard to permissions, the
driver side will always be up to date. Plus Javascript is memory-safe.

Holy freakin ghost though, this should be HTTPS only.

~~~
imtringued
The problem is that every website you give USB access to can keylog anything
you type. Nobody here cares about foreign ports or whatever.

I can already use all my three USB devices (mouse, keyboard, flash drive) in
conjunction with websites. Where is the supposed utility? Beyond some niches
like connecting an arduino and a gamepad I can't see this being useful.

~~~
sillysaurus3
The spec is explicitly not for keyboards:

 _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. There is however a long tail of devices that do not
fit into one of the standardized device classes. These devices require
hardware vendors to write native drivers and SDKs in order for developers to
take advantage of them and this native code prevents these devices from being
used by the web._

~~~
weddpros
Seriously? What they really want is Javascript device drivers?

Like so many things USB, it will be half baked at best...

USB couldn't even design a proper connector, had data rates (USB2) 4x below
specs, etc. I wouldn't trust them to guarantee any level of security...

Also, USB's main argument has always been "yes but it's cheap"

------
madmax96
"Look, it's a web-browser!" "No, it's a platform!" "It's an operating system!"

------
userbinator
What's next, WebFirewire? WebSATA? WebPCIe?

USB is enough of an attack surface locally. I don't think I'd ever trust a web
page (or app, as the case may be) with access to my USB devices.

~~~
BinaryIdiot
Read the spec. It doesn't grant access to your USB devices directly. It's an
abstraction layer gated similar to how geolocation works and the vendor
supplies how much of the device the web browser can touch. It's actually
pretty clever.

~~~
monocasa
I did read the spec. It's very very close to the level of access that the
kernel has to a USB device.

------
Sir_Cmpwn
Though I agree with the concerns about security, I can personally think of a
cool use-case: [http://knightos.org](http://knightos.org). It'd be nice if
users could just plug in a calculator and install KnightOS on it from any web
browser. Ditto with
[https://packages.knightos.org](https://packages.knightos.org) \- plug in
calculator and click a button to install the package.

~~~
monocasa
Firmware update is exactly the kind of thing that shouldn't be allowed.

------
weddpros
Maybe the NSA thinks they don't have enough control on our machines? "If only
we could control their USB devices too"...

Then the FBI asks/orders Yubico (or others) to help bypassing USB dongles
remotely?

I think I won't trust such a thing...

------
darpa_escapee
This is what happens when the generation that brought us front ends that
require 450MB of memory to display a web page start aging and join committees.

------
chatmasta
This trend of shoving as much functionality into browsers as possible is
really worrying. It's indicative of lazy architecting, because most of the
time the complex features you desire are fully available using native OS APIs.
There does not need to be a bridge for every feature in the browser. For apps
using OS level APIs, more often than not, users will need to grant some
permission to access their device. The permission scopes in modern operating
systems are very strict and hardened. It would be very difficult for an app to
execute a "drive by" exploit without first requesting some form of permission.
At the very least, the user needs to explicitly download the app into their
device (as opposed to simply viewing a webpage). The permissions API of
browsers, compared to OS, are less mature, operate in userspace, and are
inherently less secure.

If an exploit exists in the browser, suddenly every device with that browser
becomes vulnerable to a drive by exploit, as opposed to every device that
downloaded a single malicious app. The user may be completely unaware, because
there is no download confirmation or permission granting involved in viewing a
webpage (assuming the exploit bypasses the weak permissions API of the
browser). A malicious actor could load the exploit into an iframe via an ad
network and the user would have no idea.

------
0x006A
A demo using the WebUSB API with Arduino:
[https://github.com/webusb/arduino](https://github.com/webusb/arduino)

------
camoby
What could possibly go wrong?

------
whoopdedo
A lot of points about the dangers of exposing a USB device to the internet.
I'm concerned about a future where all my USB devices require internet access.
Is network chatter destined to increase until nothing we own will function
without phoning home? It's a firewall headache.

~~~
BinaryIdiot
> A lot of points about the dangers of exposing a USB device to the internet.

It gets exposed to the web browser, not the internet. They can become
accessible via a usb:// protocol and use JavaScript for interaction. They gain
no low level access.

> I'm concerned about a future where all my USB devices require internet
> access.

Many people on HN are worried about this though why mention it in a comment on
this article? Did you read it? It exposes the USB devices to the web browser
through an API that has parts similar to CORS. You'll be able to take a usb
device and interface with it using an offline, HTML5, web application.

------
cm3
I'm surprised there's no Chromium or Firefox which removes microphone, webcam,
js local file access, and this new vector, to name just a few.

Alternatively Servo would be modular enough that I could build a custom
version without many features.

~~~
masklinn
Servo is a rendering engine, the DOM and JS are currently provided by Gecko,

~~~
cm3
Of course, but it needs to be modular in order for users to omit parts. You
may have misinterpreted my note.

~~~
masklinn
The things you want to omit have nothing to do with Servo is the point of my
comment. Servo's modularity is irrelevant to removing webcam access. Which
incidentally I believe you can already do in both Firefox and Chrome by
disabling the MediaSource API altogether.

~~~
cm3
Servo isn't strictly just the HTML+CSS part, if you have a look at the
project's sources.

Modularity is relevant because if stuff isn't modular and has code paths to
deal with missing functionality, you'll have a much increased burden, aka a
fork.

In Firefox (and maybe Chrome, don't use, so not sure) you can disable it in
the configuration but that could easily be enabled again by some script or
extension.

------
forgotmypassw
This is madness.

------
SCHiM
The ethical security concious part of me is saying "No, no no, no!"

The unethical job-security concious part of me is pleading "yes yes yes!! Add
more devices to the internet!".

------
owenwil
If implemented right this could be fantastic, especially for devices like
Chromebooks, but am I reading it right that this API basically brings hardware
drivers to JavaScript?

~~~
jrockway
You'll find that most USB drivers do very little beyond moving bytes from one
place to another, so it's kind of a natural fit because it can enable a lot of
convenience for end users. (Think kids trying to program their Arduino, or a
web-based GUI for your ham radio... things like that.)

It's already been played with in Chrome a bit:
[https://developer.chrome.com/apps/app_usb](https://developer.chrome.com/apps/app_usb)

~~~
gravypod
I was thinking about how nice it would be to be able to run a GNU Radio client
on a local server and have only the downsampling run on a thin client.

Would be lots of fun.

------
nxzero
Pretending like USB devices aren't already a target, safe, etc. - won't make
the net safe.

Being able to interface USB with the net is a natural step in the internet of
things.

~~~
kevin_thibedeau
It would be more natural to add a new IP-over-USB device class and let
products opt in to bring an IoT experience without invading the entire legacy
stack and exposing all its security holes.

------
Namidairo
It wouldn't surprise me if someone were to use this to effectively share a
licensing dongle.

Although I'd imagine latency might be an issue.

------
kabdib
Nothing says "I love you" more than malware persistently embedded in your USB
devices.

Here's how hardware teams work (in my experience)

\----

Manager: "Hmmm... we need firmware. Hey, who can update the USB stack for the
next version of our USB toaster?"

Team: _shrug_

Manager: "Figby! Don't you do Arduino stuff on the weekends? You do it. Be
done next Friday."

Figby: "Meep?"

USB is hard enough to get working properly, now you need to add "resistance to
attack from the host" to the feature set. Figby is in trouble because he's
being crushed under four rocks now:

1\. USB is hard to get working. The standard is pretty complicated, and
speaking frankly here, the device class standards are pretty badly fucked up.
Camel-by-committee class bad. You spend a lot of time getting edge cases to
work. (Don't get me started on DFU, OMFG).

2\. Figby probably has a bunch of legacy to deal with. If the USB stack he's
working with started from a fine commercial framework, he's better off. But
he's likely working with something horrible hatched by a former semi-hardware
guy a while ago, who was fired because six months into the prior version of
the project, management finally realized he could barely spell 'C'. Oh, and
the code makes liberal use of #define, and the source doesn't use curly
braces, but DO..OD and WHILE..ELIHW, and there is deep, _deep_
misunderstanding of what 'volatile' actually does.

3\. Figby also has to work with the host driver team. If they are not actively
hiding from the hardware team they are either on the wrong side of the planet,
or have absolutely no time to devote to USB issues. The new driver will arrive
about three days after Fibgy's "golden master" date.

4\. Figby has no time. Everything is feature work. If there are security bugs
in the code (... and there _are_ ) they have been ignored or deferred as
"won't fix" for several product versions. If there are security reviews, they
are cursory check-off meetings where people who don't know anything about
security make collective shrugs around bugs that are embedded in the product
at the level of DNA. The code is swiss-cheese and would take months to make a
dent in. Besides, this is a hardware company; isn't the OS supposed to keep us
safe?

... now this WebUSB thing lands on Figby's plate. "Marketing really really
wants this feature so they can add another checkbox to the package." What are
the chances that Figby's going to fix security issues in the product before
just turning the thing on for the whole internet to see? Because Friday.

Figby adds command handlers and descriptors for WebUSB. He'll get to the
security stuff later, when the rest of everything else works.

Yeah.

This is a horrible idea.

------
logotype
This just can't be good from a security perspective!

------
edoceo
Promoting the Browser to the OS level!? Read-only for private key loading may
be useful but beyond that seems dangerous. Use standard download and save
method.

------
miga
I suppose that is a great idea, but still requires some kind of explicit user
permission to guarantee security.

~~~
sparkie
Android and iOS apps tend to require "explicit" user permissions when
installing them. I quote explicit, because it's really implicit: accept these
terms or don't use the app.

How many people actually look at these before clicking install?

They're not fine grained enough to allow the user to weigh up the security
implications of them, which leads to apps requesting every permission under
the sun, or just outright refusal to use the app (by a small minority who know
the script).

We can see how this will pan out in the browser: The browsers will initially
offer the "allowed devices" set that is described here, but eventually users
will find it "too confusing", and they'll reduce it to "Do you want to allow
this website to access any USB device?"

The common user will get fed up of this popup appearing and the browser
vendors will happily oblige by having an enabled-by-default option: "Allow
websites to access my USB devices".

Then some giants (ie, google) will provide SaaSS to filter which devices can
be accessed from which websites for you. Browser vendors will be quick to use
this service, turned on by default, much the same way as they use google for
anti-phishing and whatnot now without asking the user.

------
melvinmt
_Looking for a PS /2 port to safely connect my USB keyboard... dammit!_

------
droithomme
I do not want this.

------
askyourmother
Yet another browser aperture that will require the usual multitude of post-
implementation band-aid security fixes.

Sigh.

We get it.

We could make the browser the OS.

But should we? Not, could we?

I actually miss the days where the browser would be an application to view and
consume content, with a modicum of scripting to progressively enhance the
experience.

~~~
gue5t
The reason people are making the browser the OS is because there's _money_ in
it. Ad money, SaaS money, middleman money.

People whose computers already do useful things, for free, will obviously
think that moving everything into the browser is stupid. But if you look at it
from the perspective of the profit-driven companies and people pushing for it,
the motivation is reasonable, if evil.

~~~
erikpukinskis
The reason I want to make the browser the OS is accessibility. Every other
platform requires limiting your audience to a certain kind of person, usually
drawn fairly close to class lines. I like software that's easily accessible
anyone interested, with a minimum fuss from a usability perspective. The web
is the only platform that matches that description.

Its big limitation is hardware access, so things like WebUSB, WebRTC, etc are
great in my book.

~~~
ctoth
As a blind person, I'll be the first to tell you that a vast majority of web
technologies are built with accessibility as an afterthought at most. Just
about when we've figured out how to make good accessible native apps,
everything's going into the browser and it's a giant mess. Ugh.

~~~
erikpukinskis
I mean accessibility in a much broader sense than just hearing and vision
impaired.

That said, your point is fully valid. The web is a wild untamed place, and
without gatekeepers there is no one to impose rules that help people like you.

I think we will overcome that with upcoming toolkits, particularly
conversational UI toolkits, but... Well, point taken. :)

------
revelation
_A device announces support for the WebUSB command set_

Wat.

 _This document describes an API for direct access to Universal Serial Bus
devices from web pages._

This isn't what any of this is about. Expose USB devices to the browser or
not, _do not_ add rogue standards for USB devices to comply with!

