10 ms·

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.

by 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.
  - icebraining 11y ago
    All other bazillion USB devices ever made are not designed to deal with security, and exposing them over the internet will blow up spectacularly. Which is why the devices have to announce they support WebUSB to be exposed to any web apps, and can even restrict their usage to specific domains.
    - monocasa 11y ago
      > and can even restrict their usage to specific domains Because there's no such thing as a XSS attack?
- lucid00 11y ago
  > Seriously though, wired connections are out. Bluetooth is the thing. ...and that's why we have Web Bluetooth, which is already in the Chrome Dev Channel. https://webbluetoothcg.github.io/web-bluetooth/ https://webbluetoothcg.github.io/web-bluetooth/
  - kuschku 11y ago
    Okay, this is getting ridiculous. Seriously, this is the moment where we should just stop, kill all existing browsers, and start from scratch. This is NOT acceptable, and this is probably the dumbest thing I’ve ever seen. WebBluetooth, WebUSB, WebGL? God I hope that this shit will never appear on any of the websites I visit, as I’ll make sure to patch it out of my browser.
    - Natanael_L 11y ago
      Lynx is still available
      - kuschku 11y ago
        I wish to be able to browse websites, which contain (a) text, (b) associated images, (c) low forms of interactivity, say, comments, or interactive graphics. This is pretty much the web 2012, or most of German-language web today still. For browsergames, let’s just use the same paradigm as with apps instead: Bundle them via node+webkit, and integrate a "run locally" API into browsers that automatically downloads a program and runs it locally in a sandbox, but seperately. In the long term, for games we’ll need to develop a different concept anyway. But there’s a good reason why no one develops 3D games in PDF, despite PDF supporting 3D objects, scripting, and modification of the document via scripts.
    - breakingcups 11y ago
      This is just Google trying to reinforce their everything-in-the-cloud-as-web-app model, which they are in a position to do considering they make one of the leading browsers, especially amongst developers. It's shoehorning everything into ancient technology ill-suited for any of these applications, which is not exclusively Google's fault of course. First HTML was augmented with Javascript, which was augmented with XHTTPRequest, which led to an increased usage of Javascript (Here's where Google comes in), which led to a lot of manpower being invested in optimizing the Javascript engines (trying to run a quirky dynamic language as fast as possible) and then augmenting the browser with "native" OS features like: * Full-screen mode * Clipboard control * Native notifications, with background workers, etc. * WebMIDI * OpenGL * etc. Which is basically like building a second operating system on top of the already existing architectures. Google tried to further push people this way by coming up with Chromebooks, which in reality actually serve to reinforce my point, since most (not all!) users find them just not sufficient enough.
- makomk 11y ago
  Allowing access to FIDO U2F devices via this would fundamentally break the security model of U2F. It relies on websites being forced to go through a U2F-specific layer in the browser that ensures websites can only request authentication to that site. Without that, any website could do a forwarding attack where it forwarded the authentication request from any other website to the device and used the response to authenticate as you. In order for this to be used for a second factor, you'd basically have a separate authentication dongle for every website.
nailer 11y ago
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?".
- ZenoArrow 11y ago
  The sensible alternative is to not enable this functionality at all. USB security is a joke, the risks for this API are too high.
  - pdkl95 11y ago
    > The sensible alternative is to not enable this functionality at all. Far too many people seem to think the solution to security problems to ignore security and only consider the features you want. This is such a bad idea that I'm starting to question the motives behind it. If I wanted to break the security of an important class of software, it would look something like this "standard". > USB security is a joke Most hardware security - USB or otherwise - doesn't exist. Local peripherals were never designed with security in mind.
    - icebraining 11y ago
      Local peripherals won't be exposed unless they specific declare they support WebUSB.
      - pdkl95 11y ago
        Do you really think attackers will respect that limitation after they overflow a buffer in the browser? You're only looking at how it's supposed to work. What matters is how it will be exploited.
        icebraining 11y ago
        With or without WebUSB, browsers can already talk to USB devices, and so if you can exploit the browser to run your own code, you can too.
api 11y ago
What about the ways this could improve security, such as by really making hardware 2fa easy to do online?
- pdkl95 11y ago
  Find another way to access that kind of security hardware. That's the kind of thing that should be mediated through a strictly limited API in the browser anyway, where standardized UI can be provided.
- userbinator 11y ago
  All you really need for that is a smartcard and a (USB) card reader to plug it into. Those could be integrated into one USB device also. That is an existing technology which is already deployed and in widespread use.
  - lucid00 11y ago
    I'm unsure if Smartcards classify as NFC, but there's also WebNFC. https://w3c.github.io/web-nfc/ https://w3c.github.io/web-nfc/
    - Natanael_L 11y ago
      Yubikey NEO?
- avian 11y ago
  Many people have been using two factor authentication for some web pages through SSL, PKCS11 modules and client side certificates on USB cryptokeys or smartcards for ages. I always find it funny how each new browser and OS release makes it a little more hidden and a bit more convoluted to set it up. All while more and more web developers complain what a big problem secure authentication on the web is.
- Freak_NL 11y ago
  That is probably one of the driving forces behind this and similar technologies (NFC and Bluetooth LTE integration with the browser). All technologies supported by 2FA standard Fido U2F incidentally. So yeah, I understand why adding this to a web browser seems unwanted, but as long as the API is well-defined and built with security as its first and primary concern, this could actually improve the overall security of on-line services significantly by making two-factor authentication something your browser just does, and does right. I can recommend skimming the Fido U2F spec [1] to anyone with doubts about the applicability and necessity of this standard. The linked article basically starts with a section on privacy and security concerns though, so that is somewhat reassuring. 1: https://fidoalliance.org/specifications/overview/ https://fidoalliance.org/specifications/overview/ (look for U2F in particular)
BinaryIdiot 11y ago
> There is no reason whatsoever to allow remote access to USB devices Sorta but that's not what this standard is proposing. It's proposing a way of accessing a USB device from a web browser. There isn't any remote access happening here (at least not directly though with this standard you could theoretically do that). This is simply so web apps can get closer to native apps in functionality.
- creshal 11y ago
  Web apps, and malware injected into adverts. Oh joy.
- pdkl95 11y ago
  > It's proposing a way of accessing a USB device from a web browser. > There isn't any remote access If you don't see the contradiction between these two statements, I don't know how to help you. Stop thinking of what this is supposed to do; it's the failure cases that are the problem. Good security design involves concepts like compartmentalization and defense-in-depth. Finding a browser exploit shouldn't also grant low level access to the USB buss. > This is simply so web apps can get closer to native apps in functionality. That's a terrible idea. Blurring the lines between a webpage and a native app simply teaches people to treat webpages as if they were a local app, when the should be learning to treat anything form the network as potentially hostile. If you don't have a clean separation between the remote UI and the local UI, you're creating the perfect situation for phishing attacks.
  - derefr 11y ago
    > If you don't have a clean separation between the remote UI and the local UI, you're creating the perfect situation for phishing attacks. I don't know what you're imagining my computer works like, but I don't have a separation between local and remote UI. I have a separation between OS and application UI (e.g. the Windows Ctrl+Alt+Del dialogue) but everything else is untrustworthy, local or no. A local app can be executing untrusted logic "sourced from" the internet just as well as a remote app can. To say otherwise is to presume that all updates to all apps on your PC go through a third-party that verifies that they never add any remotely-accessible "extension points" that weren't there in previous updates. Obviously, this is not the case, even for the strictest corporate device-management release-engineering program.
awalton 11y ago
> There is no reason whatsoever to allow remote access to USB devices. Unless you want to connect your local USB device to some VM in the cloud. Which is the direct use case that came up when this came up in discussion with Reilly Grant when we were both at VMware. It comes up surprisingly often as a requested feature, as IT organizations get increasingly lazy/less funded/laid off and don't want to have to install clients or anything on local machines, just pop open a browser, point it at the VM and connect up the device. Not that I'm advocating for this in any way... I thought it was pretty out there (along with WebMIDI), but hey, why not, the Web Browser is the One True Platform and everyone and their parent company and sister company has nearly quit doing native application development on any OS (as sad as that makes me).
- robert_foss 11y ago
  Even if you want to remotely attach a USB device, doing it through the browser is a severely silly way to do it. Why not attach USB devices over IRC? Or SAMBA? Just because it is possible, doesn't mean that it's reasonable or good.
  - voltagex_ 11y ago
    It's not quite SMB, but Microsoft supports USB-over-RDP: https://blogs.msdn.microsoft.com/rds/2010/06/10/introducing-microsoft-remotefx-usb-redirection-part-1/ https://blogs.msdn.microsoft.com/rds/2010/06/10/introducing-...
- chatmasta 11y ago
  If you want to connect a USB device to the cloud, that's great. All you need is a usb<->socks proxy running on your local machine, tunneling USB traffic to the remote server. Why should we build this functionality into the browser? Is it really that much more convenient than installing an app to run the proxy? The use case you describe is sufficiently rare, that if you need it, downloading an app should not be a high cost to pay. If only 1% of browser users need this USB proxy, why expose an additional attack surface for the 99% who do not need it?
  - 11y ago
bobwaycott 11y ago
This was my immediate thought, as well. Stop. Just stop.
Matthias247 11y ago
Fully agree. I don't even see the use cases. For most things that are mentioned in the comments (mostly something like connecting proprietary USB devices to the browser) a native application that proxies the related data to browsers seems like a much better approach. For well understood device classes that would be used by a bigger number of websites it makes far more sense to standardize high level APIs which covers exactly these devices (like it happened for webcam and other stuff). The WebUSB approach also limits each device to be connected and controlled by exactly one browser frame which makes it not very desirable for sensor and other input applications.
- erikpukinskis 11y ago
  > a native application that proxies the related data to browsers seems like a much better approach Why do you think that? It seems needlessly complex to me when you could just have a simple permission pop up in the web app. What's the benefit of downloading an executable?
  - Matthias247 11y ago
    And then you get the permission popup each time you open the page? Seems needlessly annoying to me. Or only once? Then most users would not have an idea on how to revoke the access right. Uninstalling the application they installed for the purpose seems more straightforward. Besides the permissions stuff giving a single browser window access to raw usb data seems also technically wrong. There are lots of reasons why we now have drivers instead of applications directly using the hardware like 30 years before. A driver or dedicated application can allow multiple clients (browser windows) to access the devices functionality. A driver directly embedded in a web page can't. A driver in the webpage even means that once you close that page the communication state between PC and USB device is in any state (can't see a way for automatically doing anything meaningful on goaway), so the only thing that could be done is disconnect and reconnect the device. So some further implications are: Multiple tabs for your web app are not possible. And even other stuff like Ctrl-R would not work as desired (disconnect device, reconnect device, wait, wait, wait, ...).
staticvar 11y ago
Thanks to all those who are concerned about security aspects of this spec. We must always be asking "what if". But do understand that there is no fundamental difference between installing a 3rd party app on your phone and granting a website access to USB. There is some code, you are granting it permission to mess with your life. The only thing difference here is the context, which you will get used to.
mellis 11y ago
There are use cases for things like Arduino (a microcontroller development board). We'd like to allow uploading to Arduino boards from an online IDE. We'd also like to allow for interaction between sensors and actuators on an Arduino board and websites (e.g. programs written in the Scratch visual programming language). Yes, we can do much of this by having the user install a local application that communicates via web sockets, but that has its own security implications and adds an additional step for the user.
- jonathankoren 11y ago
  Why are you trying to connect to the web at all? > Yes, we can do much of this by having the user install a local application that communicates via web sockets, but that has its own security implications and adds an additional step for the user. You're target audience is arduino hackers, and you're worried about them installing an app? You need to seriously reassess your assumptions.
  - voltagex_ 11y ago
    Or the target is someone teaching a class of newbies how to start with Arduino. Same device, different audience, different needs.
    - jonathankoren 11y ago
      It still doesn't make any sense. Who that's not intimidated with soldering irons and wiring circuits up that can literally burst into flames if you do it wrong, is going to say, "Heavens to Betsy! I have to click an installer! My word, I'm comin' down with the vapors!"?
      - voltagex_ 11y ago
        Strawman. I can teach an Arduino class with no soldering at all.
        11y ago
oakwhiz 11y ago
Some USB devices can be firmware-flashed over USB. They expose secret commands or additional descriptors for doing this. A popular method is to expose an HID endpoint that is actually used for uploading firmware. If the implementation allows access to these endpoints in a way that allows them to upload firmware, this is very bad for security. If you accidentally plug your USB device into an unknown computer on a webpage, it's reasonable to expect that the device could have been reprogrammed. And a reprogrammed USB device may very well expose any descriptor(s) it wants to - HID keyboard, mass storage device, ethernet connection...
- josephg 11y ago
  Section 2 of the spec names and addresses exactly this concern: > USB hosts and devices historically trust each other. There are published attacks against USB devices that will accept unsigned firmware updates. These vulnerabilities permit an attacker to gain a foothold in the device and attack the original host or any other host to which they are later connected. For this reason WebUSB does not attempt to provide a mechanism for any web page to connect to arbitrary devices. ... > For this reason this specification outlines two mechanisms that can be combined by the UA before a site is granted access to a device. 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. These are similar to the [CORS] mechanism and can conceptually be thought of as treating USB devices as their own origins in the "usb" scheme. For devices manufacturered before this specificiation is adopted information about allowed origins and landing pages can also be provided out of band by being published in a public registry. Second, so that the user's privacy is protected the UA may prompt the user for authorization to allow a site to detect the presense of a device and connect to it.
  - username223 11y ago
    > USB hosts and devices historically trust each other... We've seen this exact recipe for years of pain play out again and again. C was designed when programmers wrote code for themselves and other people who weren't trying to break that code; if you manage to overflow a buffer in some command-line utility that uses "gets()", you're basically punching yourself in the face. SMTP was designed to send messages between non-commercial entities who wanted to communicate; then the people who stuffed your mailbox with ads realized they could stuff your internet mailbox with ads almost for free. In both cases, a system built for a trusting environment was used in an untrusting one, and there was much pain. A public registry and an optional nag about an on-by-default feature won't come close to addressing the problem. With thousands of types of USB devices out there, who will go through and audit them all, and keep the registry up to date? And how many users will see the nag and just do the easiest thing to make it go away, or even have the knowledge to make the decision? It seems like browsers need an "annoying/harmful Web 3.0 features" tab with an ever-growing list of check boxes for WebGL, notifications, geolocation, USB, etc., with all of them set by default to "deny without asking."
guidedlight 11y ago
Proprietary technologies are doing this already, we would actually be safer if it was done in an open and transparent manner.

by pdkl95 11y ago

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.
- icebraining 11y ago
  All other bazillion USB devices ever made are not designed to deal with security, and exposing them over the internet will blow up spectacularly. Which is why the devices have to announce they support WebUSB to be exposed to any web apps, and can even restrict their usage to specific domains.
  - monocasa 11y ago
    > and can even restrict their usage to specific domains Because there's no such thing as a XSS attack?
lucid00 11y ago
> Seriously though, wired connections are out. Bluetooth is the thing. ...and that's why we have Web Bluetooth, which is already in the Chrome Dev Channel. https://webbluetoothcg.github.io/web-bluetooth/ https://webbluetoothcg.github.io/web-bluetooth/
- kuschku 11y ago
  Okay, this is getting ridiculous. Seriously, this is the moment where we should just stop, kill all existing browsers, and start from scratch. This is NOT acceptable, and this is probably the dumbest thing I’ve ever seen. WebBluetooth, WebUSB, WebGL? God I hope that this shit will never appear on any of the websites I visit, as I’ll make sure to patch it out of my browser.
  - Natanael_L 11y ago
    Lynx is still available
    - kuschku 11y ago
      I wish to be able to browse websites, which contain (a) text, (b) associated images, (c) low forms of interactivity, say, comments, or interactive graphics. This is pretty much the web 2012, or most of German-language web today still. For browsergames, let’s just use the same paradigm as with apps instead: Bundle them via node+webkit, and integrate a "run locally" API into browsers that automatically downloads a program and runs it locally in a sandbox, but seperately. In the long term, for games we’ll need to develop a different concept anyway. But there’s a good reason why no one develops 3D games in PDF, despite PDF supporting 3D objects, scripting, and modification of the document via scripts.
  - breakingcups 11y ago
    This is just Google trying to reinforce their everything-in-the-cloud-as-web-app model, which they are in a position to do considering they make one of the leading browsers, especially amongst developers. It's shoehorning everything into ancient technology ill-suited for any of these applications, which is not exclusively Google's fault of course. First HTML was augmented with Javascript, which was augmented with XHTTPRequest, which led to an increased usage of Javascript (Here's where Google comes in), which led to a lot of manpower being invested in optimizing the Javascript engines (trying to run a quirky dynamic language as fast as possible) and then augmenting the browser with "native" OS features like: * Full-screen mode * Clipboard control * Native notifications, with background workers, etc. * WebMIDI * OpenGL * etc. Which is basically like building a second operating system on top of the already existing architectures. Google tried to further push people this way by coming up with Chromebooks, which in reality actually serve to reinforce my point, since most (not all!) users find them just not sufficient enough.
makomk 11y ago
Allowing access to FIDO U2F devices via this would fundamentally break the security model of U2F. It relies on websites being forced to go through a U2F-specific layer in the browser that ensures websites can only request authentication to that site. Without that, any website could do a forwarding attack where it forwarded the authentication request from any other website to the device and used the response to authenticate as you. In order for this to be used for a second factor, you'd basically have a separate authentication dongle for every website.

nailer 11y ago

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

ZenoArrow 11y ago
The sensible alternative is to not enable this functionality at all. USB security is a joke, the risks for this API are too high.
- pdkl95 11y ago
  > The sensible alternative is to not enable this functionality at all. Far too many people seem to think the solution to security problems to ignore security and only consider the features you want. This is such a bad idea that I'm starting to question the motives behind it. If I wanted to break the security of an important class of software, it would look something like this "standard". > USB security is a joke Most hardware security - USB or otherwise - doesn't exist. Local peripherals were never designed with security in mind.
  - icebraining 11y ago
    Local peripherals won't be exposed unless they specific declare they support WebUSB.
    - pdkl95 11y ago
      Do you really think attackers will respect that limitation after they overflow a buffer in the browser? You're only looking at how it's supposed to work. What matters is how it will be exploited.
      - icebraining 11y ago
        With or without WebUSB, browsers can already talk to USB devices, and so if you can exploit the browser to run your own code, you can too.

api 11y ago

What about the ways this could improve security, such as by really making hardware 2fa easy to do online?

pdkl95 11y ago
Find another way to access that kind of security hardware. That's the kind of thing that should be mediated through a strictly limited API in the browser anyway, where standardized UI can be provided.
userbinator 11y ago
All you really need for that is a smartcard and a (USB) card reader to plug it into. Those could be integrated into one USB device also. That is an existing technology which is already deployed and in widespread use.
- lucid00 11y ago
  I'm unsure if Smartcards classify as NFC, but there's also WebNFC. https://w3c.github.io/web-nfc/ https://w3c.github.io/web-nfc/
  - Natanael_L 11y ago
    Yubikey NEO?
avian 11y ago
Many people have been using two factor authentication for some web pages through SSL, PKCS11 modules and client side certificates on USB cryptokeys or smartcards for ages. I always find it funny how each new browser and OS release makes it a little more hidden and a bit more convoluted to set it up. All while more and more web developers complain what a big problem secure authentication on the web is.
Freak_NL 11y ago
That is probably one of the driving forces behind this and similar technologies (NFC and Bluetooth LTE integration with the browser). All technologies supported by 2FA standard Fido U2F incidentally. So yeah, I understand why adding this to a web browser seems unwanted, but as long as the API is well-defined and built with security as its first and primary concern, this could actually improve the overall security of on-line services significantly by making two-factor authentication something your browser just does, and does right. I can recommend skimming the Fido U2F spec [1] to anyone with doubts about the applicability and necessity of this standard. The linked article basically starts with a section on privacy and security concerns though, so that is somewhat reassuring. 1: https://fidoalliance.org/specifications/overview/ https://fidoalliance.org/specifications/overview/ (look for U2F in particular)

BinaryIdiot 11y ago

> There is no reason whatsoever to allow remote access to USB devices Sorta but that's not what this standard is proposing. It's proposing a way of accessing a USB device from a web browser. There isn't any remote access happening here (at least not directly though with this standard you could theoretically do that). This is simply so web apps can get closer to native apps in functionality.

creshal 11y ago
Web apps, and malware injected into adverts. Oh joy.
pdkl95 11y ago
> It's proposing a way of accessing a USB device from a web browser. > There isn't any remote access If you don't see the contradiction between these two statements, I don't know how to help you. Stop thinking of what this is supposed to do; it's the failure cases that are the problem. Good security design involves concepts like compartmentalization and defense-in-depth. Finding a browser exploit shouldn't also grant low level access to the USB buss. > This is simply so web apps can get closer to native apps in functionality. That's a terrible idea. Blurring the lines between a webpage and a native app simply teaches people to treat webpages as if they were a local app, when the should be learning to treat anything form the network as potentially hostile. If you don't have a clean separation between the remote UI and the local UI, you're creating the perfect situation for phishing attacks.
- derefr 11y ago
  > If you don't have a clean separation between the remote UI and the local UI, you're creating the perfect situation for phishing attacks. I don't know what you're imagining my computer works like, but I don't have a separation between local and remote UI. I have a separation between OS and application UI (e.g. the Windows Ctrl+Alt+Del dialogue) but everything else is untrustworthy, local or no. A local app can be executing untrusted logic "sourced from" the internet just as well as a remote app can. To say otherwise is to presume that all updates to all apps on your PC go through a third-party that verifies that they never add any remotely-accessible "extension points" that weren't there in previous updates. Obviously, this is not the case, even for the strictest corporate device-management release-engineering program.

awalton 11y ago

> There is no reason whatsoever to allow remote access to USB devices. Unless you want to connect your local USB device to some VM in the cloud. Which is the direct use case that came up when this came up in discussion with Reilly Grant when we were both at VMware. It comes up surprisingly often as a requested feature, as IT organizations get increasingly lazy/less funded/laid off and don't want to have to install clients or anything on local machines, just pop open a browser, point it at the VM and connect up the device. Not that I'm advocating for this in any way... I thought it was pretty out there (along with WebMIDI), but hey, why not, the Web Browser is the One True Platform and everyone and their parent company and sister company has nearly quit doing native application development on any OS (as sad as that makes me).

robert_foss 11y ago
Even if you want to remotely attach a USB device, doing it through the browser is a severely silly way to do it. Why not attach USB devices over IRC? Or SAMBA? Just because it is possible, doesn't mean that it's reasonable or good.
- voltagex_ 11y ago
  It's not quite SMB, but Microsoft supports USB-over-RDP: https://blogs.msdn.microsoft.com/rds/2010/06/10/introducing-microsoft-remotefx-usb-redirection-part-1/ https://blogs.msdn.microsoft.com/rds/2010/06/10/introducing-...
chatmasta 11y ago
If you want to connect a USB device to the cloud, that's great. All you need is a usb<->socks proxy running on your local machine, tunneling USB traffic to the remote server. Why should we build this functionality into the browser? Is it really that much more convenient than installing an app to run the proxy? The use case you describe is sufficiently rare, that if you need it, downloading an app should not be a high cost to pay. If only 1% of browser users need this USB proxy, why expose an additional attack surface for the 99% who do not need it?
- 11y ago

bobwaycott 11y ago

This was my immediate thought, as well. Stop. Just stop.

Matthias247 11y ago

Fully agree. I don't even see the use cases. For most things that are mentioned in the comments (mostly something like connecting proprietary USB devices to the browser) a native application that proxies the related data to browsers seems like a much better approach. For well understood device classes that would be used by a bigger number of websites it makes far more sense to standardize high level APIs which covers exactly these devices (like it happened for webcam and other stuff). The WebUSB approach also limits each device to be connected and controlled by exactly one browser frame which makes it not very desirable for sensor and other input applications.

erikpukinskis 11y ago
> a native application that proxies the related data to browsers seems like a much better approach Why do you think that? It seems needlessly complex to me when you could just have a simple permission pop up in the web app. What's the benefit of downloading an executable?
- Matthias247 11y ago
  And then you get the permission popup each time you open the page? Seems needlessly annoying to me. Or only once? Then most users would not have an idea on how to revoke the access right. Uninstalling the application they installed for the purpose seems more straightforward. Besides the permissions stuff giving a single browser window access to raw usb data seems also technically wrong. There are lots of reasons why we now have drivers instead of applications directly using the hardware like 30 years before. A driver or dedicated application can allow multiple clients (browser windows) to access the devices functionality. A driver directly embedded in a web page can't. A driver in the webpage even means that once you close that page the communication state between PC and USB device is in any state (can't see a way for automatically doing anything meaningful on goaway), so the only thing that could be done is disconnect and reconnect the device. So some further implications are: Multiple tabs for your web app are not possible. And even other stuff like Ctrl-R would not work as desired (disconnect device, reconnect device, wait, wait, wait, ...).

staticvar 11y ago

Thanks to all those who are concerned about security aspects of this spec. We must always be asking "what if". But do understand that there is no fundamental difference between installing a 3rd party app on your phone and granting a website access to USB. There is some code, you are granting it permission to mess with your life. The only thing difference here is the context, which you will get used to.

mellis 11y ago

There are use cases for things like Arduino (a microcontroller development board). We'd like to allow uploading to Arduino boards from an online IDE. We'd also like to allow for interaction between sensors and actuators on an Arduino board and websites (e.g. programs written in the Scratch visual programming language). Yes, we can do much of this by having the user install a local application that communicates via web sockets, but that has its own security implications and adds an additional step for the user.

jonathankoren 11y ago
Why are you trying to connect to the web at all? > Yes, we can do much of this by having the user install a local application that communicates via web sockets, but that has its own security implications and adds an additional step for the user. You're target audience is arduino hackers, and you're worried about them installing an app? You need to seriously reassess your assumptions.
- voltagex_ 11y ago
  Or the target is someone teaching a class of newbies how to start with Arduino. Same device, different audience, different needs.
  - jonathankoren 11y ago
    It still doesn't make any sense. Who that's not intimidated with soldering irons and wiring circuits up that can literally burst into flames if you do it wrong, is going to say, "Heavens to Betsy! I have to click an installer! My word, I'm comin' down with the vapors!"?
    - voltagex_ 11y ago
      Strawman. I can teach an Arduino class with no soldering at all.
      - 11y ago

oakwhiz 11y ago

Some USB devices can be firmware-flashed over USB. They expose secret commands or additional descriptors for doing this. A popular method is to expose an HID endpoint that is actually used for uploading firmware. If the implementation allows access to these endpoints in a way that allows them to upload firmware, this is very bad for security. If you accidentally plug your USB device into an unknown computer on a webpage, it's reasonable to expect that the device could have been reprogrammed. And a reprogrammed USB device may very well expose any descriptor(s) it wants to - HID keyboard, mass storage device, ethernet connection...

josephg 11y ago
Section 2 of the spec names and addresses exactly this concern: > USB hosts and devices historically trust each other. There are published attacks against USB devices that will accept unsigned firmware updates. These vulnerabilities permit an attacker to gain a foothold in the device and attack the original host or any other host to which they are later connected. For this reason WebUSB does not attempt to provide a mechanism for any web page to connect to arbitrary devices. ... > For this reason this specification outlines two mechanisms that can be combined by the UA before a site is granted access to a device. 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. These are similar to the [CORS] mechanism and can conceptually be thought of as treating USB devices as their own origins in the "usb" scheme. For devices manufacturered before this specificiation is adopted information about allowed origins and landing pages can also be provided out of band by being published in a public registry. Second, so that the user's privacy is protected the UA may prompt the user for authorization to allow a site to detect the presense of a device and connect to it.
- username223 11y ago
  > USB hosts and devices historically trust each other... We've seen this exact recipe for years of pain play out again and again. C was designed when programmers wrote code for themselves and other people who weren't trying to break that code; if you manage to overflow a buffer in some command-line utility that uses "gets()", you're basically punching yourself in the face. SMTP was designed to send messages between non-commercial entities who wanted to communicate; then the people who stuffed your mailbox with ads realized they could stuff your internet mailbox with ads almost for free. In both cases, a system built for a trusting environment was used in an untrusting one, and there was much pain. A public registry and an optional nag about an on-by-default feature won't come close to addressing the problem. With thousands of types of USB devices out there, who will go through and audit them all, and keep the registry up to date? And how many users will see the nag and just do the easiest thing to make it go away, or even have the knowledge to make the decision? It seems like browsers need an "annoying/harmful Web 3.0 features" tab with an ever-growing list of check boxes for WebGL, notifications, geolocation, USB, etc., with all of them set by default to "deny without asking."

guidedlight 11y ago

Proprietary technologies are doing this already, we would actually be safer if it was done in an open and transparent manner.