24 ms·

WebUSB API: draft spec to safely expose USB device services to the web

137 points by fitzwatermellow 11y ago

melvinmt 11y ago
Looking for a PS/2 port to safely connect my USB keyboard... dammit!
miga 11y ago
I suppose that is a great idea, but still requires some kind of explicit user permission to guarantee security.
- sparkie 11y ago
  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.
0x006A 11y ago
A demo using the WebUSB API with Arduino: https://github.com/webusb/arduino https://github.com/webusb/arduino
owenwil 11y ago
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 11y ago
  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 11y ago
    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.
- voodootikigod 11y ago
  This does already (sort of) exist in a couple of projects: * Chromebots - http://www.iceddev.com/blog/chromebots-lowering-the-barrier-to-entry/ http://www.iceddev.com/blog/chromebots-lowering-the-barrier-... (for controlling arduino via JS using browser-serialport https://github.com/garrows/browser-serialport https://github.com/garrows/browser-serialport as a chrome packaged app (so requires a little more than just 'visit a website, root a /dev' * Nodebots - http://nodebots.io/ http://nodebots.io/ for controlling a multitude of hardware via node.JS through bluetooth, BLE, or USB/Serial (which most hacker level hardware still prefers). * WhatWG WebSerial - https://whatwg.github.io/serial/ https://whatwg.github.io/serial/ which is doing similar to this, but less from one specific vendor Ideally the world would converge to a single unified implementation, that said there is a lot of differences between USB-serialport, USB-HID, and a multitude of other communication methods over USB. TL;DR you can do hardware with JS already, this should make things in the browsers slightly easier (one less dependency) at the risk of making it available for all things. Sum: Tradeoff, like all the things.
fidget 11y ago
`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 11y ago
  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.
- cmrx64 11y ago
  Note that the policy isn't mandatory. Privileged contexts will likely have access anyway.
- deleted 11y ago
  [deleted]
orf 11y ago
Oh boy, I can't wait for the first exploit involving this to hit.
revelation 11y ago
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!
forgotmypassw 11y ago
This is madness.
pdkl95 11y ago
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.
- sneak 11y ago
  FIDO U2F. Hardware Bitcoin wallets. HSMs in general. Seriously though, wired connections are out. Bluetooth is the thing.
  - jjoonathan 11y ago
    Great, now all my devices can share the bandwidth and reliability characteristics of a stoned boy scout trying to send smoke signals with a flammable blanket! EDIT: and the less said about pairing difficulties the better. EDIT2: From the downvotes it seems that many people have had a radically different experience from mine, which is good, because mine has been awful. HTCOne-Dell: 1MB file will transfer ~50% of the time, pairing took several tries. HTCOne-MBP: complete no-go, doesn't even pair. Nexus6-MBP: paired first try, works reliably at a blazing 100kb/s. Nexus6-Dell: doesn't even pair. Nexus6-Fitbit: takes minutes to download a day's activity over bluetooth classic, stalls out completely 50% of the time. BLE doesn't seem to work at all. MBP-Fitbit: requires dongle, synced once, has had 100% failure rate ever since. Dell-Fitbit: requires dongle, 100% failure rate. Compare to USB which delivers tens of MB/s in bandwidth with 100% reliability and no pairing process (RIP plug and play). I love the promise of bluetooth, but in my experience it has consistently fallen spectacularly short of that promise in every regard.
  - creshal 11y ago
    APIs to access HSMs exist already, though – PKCS11 and friends. And HSMs are designed to deal with accesses questionable sources, so if you wanted to improve their accessibility with a HSM-specific standard, it'd be not much of a headache. All other bazillion USB devices ever made are not designed to deal with security, and exposing them over the internet will blow up spectacularly.
SCHiM 11y ago
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!".
camoby 11y ago
What could possibly go wrong?
Sir_Cmpwn 11y ago
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 11y ago
  Firmware update is exactly the kind of thing that shouldn't be allowed.
madmax96 11y ago
"Look, it's a web-browser!" "No, it's a platform!" "It's an operating system!"
nly 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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"
askyourmother 11y ago
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.
- fixermark 11y ago
  WebGl actually exceeded my personal expectations regarding security. This may actually be alright.
  - creshal 11y ago
    It took years to put band-aid security measures onto a standard that initially allowed random websites to dump your VRAM contents and/or remotely exploit kernel-layer video driver bugs. And graphics drivers/hardware are a much easier to control market than USB devices. You have five or six GPU vendors to yell at and/or blacklist broken driver versions, and tens of thousands of USB vendors.
- Navarr 11y ago
  Why shouldn't we? Security on the browser level is actually stricter than that at the OS level most of the time. Any app you download from any random place and run can access your webcam - but a webapp has to request it. I don't think the web makes Trojans or security flaws any more likely, it just changes where they sit. For the OS you've got buffer overflows which have been common for years and bash injection vulnerabilities. The issue is if someone can break out of the sandbox. I think it's perfectly acceptable to make a web technology that can be the OS. I don't see any reason that such progress should be halted. The browser was an application to view and consume content. Basically a book reader where you could access thousands of books just by putting in the right URL to the book. Now it's the same thing but for applications. For features, functionality. With the right standards it's cross-platform - write once run anywhere. With improving specs and browser vendors caring about speed and UX it can begin to reach the same speeds anything "native" could. I don't think the security risks outweigh the benefits, and even with those risks we can work hard to mitigate them.
cm3 11y ago
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 11y ago
  Servo is a rendering engine, the DOM and JS are currently provided by Gecko,
  - cm3 11y ago
    Of course, but it needs to be modular in order for users to omit parts. You may have misinterpreted my note.
    - masklinn 11y ago
      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 11y ago
        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.
logotype 11y ago
This just can't be good from a security perspective!
nxzero 11y ago
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 11y ago
  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.
  - deleted 11y ago
    [deleted]
roflc0ptic 11y ago
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?
- Klathmon 11y ago
  I'd like to know too, because I just can't accept that the answer to security issues is just "Don't do that"... It really looks like they are doing this right. Fully behind permissions that are already protected against clickjacking, very limited scope, requires HTTPS, and is being implemented with security as a first priority. People are acting like access to USB is something that no PC should ever do...
  - crazyhatfish 11y ago
    At the moment, nothing in a browser is direct access. Everything is abstracted, which includes the filesystem and geolocation. This provides a layer of security against massive horrible bugs in the OS. With WebUSB there seems to be very little abstracting, all the values you pass to it are then sent on to the device. Small bugs once protected by numerous layers of security usually requiring superuser abilities are now made massive as they are connected to one of the largest fuzzers there is, the internet.
- userbinator 11y ago
  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.
sillysaurus3 11y ago
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.
- weddpros 11y ago
  the industry was never able to deliver half correct default ICC profiles, and you'd like to alter these badly calibrated screens dynamically?
  - sillysaurus3 11y ago
    It's the only way to do it. The light sensor delivers a realtime feed of what your eye currently sees. A website can react appropriately. It's actually more powerful than monitor calibration. Calibration doesn't account for the viewing condition (the brightness of your environment) whereas this hardware can.
    - weddpros 11y ago
      and only works in a browser... which makes it useless for all the people who care about color. It should really be the responsibility of the OS only... and browsers should all be ICC aware to begin with (a few years ago, only Safari was)
Namidairo 11y ago
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.
weddpros 11y ago
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...
userbinator 11y ago
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.
- mtgx 11y ago
  It's the curse of the IoT (Internet of Threats). This is just the beginning unfortunately.
- Natanael_L 11y ago
  WebDMA
- BinaryIdiot 11y ago
  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 11y ago
    I did read the spec. It's very very close to the level of access that the kernel has to a USB device.
kabdib 11y ago
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.
vbezhenar 11y ago
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 11y ago
  Chrome Apps already have USB access: https://developer.chrome.com/apps/app_usb https://developer.chrome.com/apps/app_usb
- Freak_NL 11y ago
  Already possible in Chrome, and soon in Firefox, with Edge having announced eventual support; have a look at Fido U2F [1]. Yubico sells U2F tokens that can be used to authenticate with GMail, Dropbox, and GitHub in your browser; today. I just hope that these standards become implemented soon enough for governments to choose them over home brewed or proprietary solutions. 1: https://fidoalliance.org/specifications/overview/ https://fidoalliance.org/specifications/overview/
chatmasta 11y ago
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.
darpa_escapee 11y ago
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.
deleted 11y ago
[deleted]
whoopdedo 11y ago
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 11y ago
  > 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.
shiftoutbox 11y ago
whoosh
droithomme 11y ago
I do not want this.
edoceo 11y ago
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.

melvinmt 11y ago

Looking for a PS/2 port to safely connect my USB keyboard... dammit!

miga 11y ago

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

sparkie 11y ago
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.

0x006A 11y ago

A demo using the WebUSB API with Arduino: https://github.com/webusb/arduino https://github.com/webusb/arduino

owenwil 11y ago

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 11y ago
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 11y ago
  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.
voodootikigod 11y ago
This does already (sort of) exist in a couple of projects: * Chromebots - http://www.iceddev.com/blog/chromebots-lowering-the-barrier-to-entry/ http://www.iceddev.com/blog/chromebots-lowering-the-barrier-... (for controlling arduino via JS using browser-serialport https://github.com/garrows/browser-serialport https://github.com/garrows/browser-serialport as a chrome packaged app (so requires a little more than just 'visit a website, root a /dev' * Nodebots - http://nodebots.io/ http://nodebots.io/ for controlling a multitude of hardware via node.JS through bluetooth, BLE, or USB/Serial (which most hacker level hardware still prefers). * WhatWG WebSerial - https://whatwg.github.io/serial/ https://whatwg.github.io/serial/ which is doing similar to this, but less from one specific vendor Ideally the world would converge to a single unified implementation, that said there is a lot of differences between USB-serialport, USB-HID, and a multitude of other communication methods over USB. TL;DR you can do hardware with JS already, this should make things in the browsers slightly easier (one less dependency) at the risk of making it available for all things. Sum: Tradeoff, like all the things.

fidget 11y ago

`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 11y ago
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.
cmrx64 11y ago
Note that the policy isn't mandatory. Privileged contexts will likely have access anyway.
deleted 11y ago
[deleted]

orf 11y ago

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

revelation 11y ago

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!

forgotmypassw 11y ago

This is madness.

pdkl95 11y ago

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.

sneak 11y ago
FIDO U2F. Hardware Bitcoin wallets. HSMs in general. Seriously though, wired connections are out. Bluetooth is the thing.
- jjoonathan 11y ago
  Great, now all my devices can share the bandwidth and reliability characteristics of a stoned boy scout trying to send smoke signals with a flammable blanket! EDIT: and the less said about pairing difficulties the better. EDIT2: From the downvotes it seems that many people have had a radically different experience from mine, which is good, because mine has been awful. HTCOne-Dell: 1MB file will transfer ~50% of the time, pairing took several tries. HTCOne-MBP: complete no-go, doesn't even pair. Nexus6-MBP: paired first try, works reliably at a blazing 100kb/s. Nexus6-Dell: doesn't even pair. Nexus6-Fitbit: takes minutes to download a day's activity over bluetooth classic, stalls out completely 50% of the time. BLE doesn't seem to work at all. MBP-Fitbit: requires dongle, synced once, has had 100% failure rate ever since. Dell-Fitbit: requires dongle, 100% failure rate. Compare to USB which delivers tens of MB/s in bandwidth with 100% reliability and no pairing process (RIP plug and play). I love the promise of bluetooth, but in my experience it has consistently fallen spectacularly short of that promise in every regard.
- creshal 11y ago
  APIs to access HSMs exist already, though – PKCS11 and friends. And HSMs are designed to deal with accesses questionable sources, so if you wanted to improve their accessibility with a HSM-specific standard, it'd be not much of a headache. All other bazillion USB devices ever made are not designed to deal with security, and exposing them over the internet will blow up spectacularly.

SCHiM 11y ago

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!".

camoby 11y ago

What could possibly go wrong?

Sir_Cmpwn 11y ago

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 11y ago
Firmware update is exactly the kind of thing that shouldn't be allowed.

madmax96 11y ago

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

nly 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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"

askyourmother 11y ago

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.

fixermark 11y ago
WebGl actually exceeded my personal expectations regarding security. This may actually be alright.
- creshal 11y ago
  It took years to put band-aid security measures onto a standard that initially allowed random websites to dump your VRAM contents and/or remotely exploit kernel-layer video driver bugs. And graphics drivers/hardware are a much easier to control market than USB devices. You have five or six GPU vendors to yell at and/or blacklist broken driver versions, and tens of thousands of USB vendors.
Navarr 11y ago
Why shouldn't we? Security on the browser level is actually stricter than that at the OS level most of the time. Any app you download from any random place and run can access your webcam - but a webapp has to request it. I don't think the web makes Trojans or security flaws any more likely, it just changes where they sit. For the OS you've got buffer overflows which have been common for years and bash injection vulnerabilities. The issue is if someone can break out of the sandbox. I think it's perfectly acceptable to make a web technology that can be the OS. I don't see any reason that such progress should be halted. The browser was an application to view and consume content. Basically a book reader where you could access thousands of books just by putting in the right URL to the book. Now it's the same thing but for applications. For features, functionality. With the right standards it's cross-platform - write once run anywhere. With improving specs and browser vendors caring about speed and UX it can begin to reach the same speeds anything "native" could. I don't think the security risks outweigh the benefits, and even with those risks we can work hard to mitigate them.

cm3 11y ago

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 11y ago
Servo is a rendering engine, the DOM and JS are currently provided by Gecko,
- cm3 11y ago
  Of course, but it needs to be modular in order for users to omit parts. You may have misinterpreted my note.
  - masklinn 11y ago
    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 11y ago
      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.

logotype 11y ago

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

nxzero 11y ago

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 11y ago
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.
- deleted 11y ago
  [deleted]

roflc0ptic 11y ago

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?

Klathmon 11y ago
I'd like to know too, because I just can't accept that the answer to security issues is just "Don't do that"... It really looks like they are doing this right. Fully behind permissions that are already protected against clickjacking, very limited scope, requires HTTPS, and is being implemented with security as a first priority. People are acting like access to USB is something that no PC should ever do...
- crazyhatfish 11y ago
  At the moment, nothing in a browser is direct access. Everything is abstracted, which includes the filesystem and geolocation. This provides a layer of security against massive horrible bugs in the OS. With WebUSB there seems to be very little abstracting, all the values you pass to it are then sent on to the device. Small bugs once protected by numerous layers of security usually requiring superuser abilities are now made massive as they are connected to one of the largest fuzzers there is, the internet.
userbinator 11y ago
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.

sillysaurus3 11y ago

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.

weddpros 11y ago
the industry was never able to deliver half correct default ICC profiles, and you'd like to alter these badly calibrated screens dynamically?
- sillysaurus3 11y ago
  It's the only way to do it. The light sensor delivers a realtime feed of what your eye currently sees. A website can react appropriately. It's actually more powerful than monitor calibration. Calibration doesn't account for the viewing condition (the brightness of your environment) whereas this hardware can.
  - weddpros 11y ago
    and only works in a browser... which makes it useless for all the people who care about color. It should really be the responsibility of the OS only... and browsers should all be ICC aware to begin with (a few years ago, only Safari was)

Namidairo 11y ago

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.

weddpros 11y ago

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

userbinator 11y ago

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.

mtgx 11y ago
It's the curse of the IoT (Internet of Threats). This is just the beginning unfortunately.
Natanael_L 11y ago
WebDMA
BinaryIdiot 11y ago
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 11y ago
  I did read the spec. It's very very close to the level of access that the kernel has to a USB device.

kabdib 11y ago

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.

vbezhenar 11y ago

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 11y ago
Chrome Apps already have USB access: https://developer.chrome.com/apps/app_usb https://developer.chrome.com/apps/app_usb
Freak_NL 11y ago
Already possible in Chrome, and soon in Firefox, with Edge having announced eventual support; have a look at Fido U2F [1]. Yubico sells U2F tokens that can be used to authenticate with GMail, Dropbox, and GitHub in your browser; today. I just hope that these standards become implemented soon enough for governments to choose them over home brewed or proprietary solutions. 1: https://fidoalliance.org/specifications/overview/ https://fidoalliance.org/specifications/overview/

chatmasta 11y ago

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.

darpa_escapee 11y ago

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.

deleted 11y ago

[deleted]

whoopdedo 11y ago

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 11y ago
> 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.

shiftoutbox 11y ago

whoosh

droithomme 11y ago

I do not want this.

edoceo 11y ago

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.