WebUSB API: draft spec to safely expose USB device services to the web
wicg.github.io
wicg.github.io
If you're implementing this... please stop. This will cause serious problems. There is no reason whatsoever to allow remote access to USB devices.
Seriously though, wired connections are out. Bluetooth is the thing.
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.
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.
Because there's no such thing as a XSS attack?
...and that's why we have Web Bluetooth, which is already in the Chrome Dev Channel.
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.
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.
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.
That's what they said about JavaScript, and look how that turned out.
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?".
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.
https://msdn.microsoft.com/en-gb/library/windows/hardware/hh...
"A USB configuration defines the capabilities and features of a device, mainly its power capabilities and interfaces. The device can have multiple configurations, but only one is active at a time. The active configuration isn't chosen by the USB driver stack, but might be initiated by an application, a driver, the device driver. The device driver selects an active configuration.
A configuration can have one or more USB interfaces that define the functionality of the device. Typically, there is a one-to-one correlation between a function and an interface. However, certain devices expose multiple interfaces related to one function."
So let's say I want to exploit this new WebUSB API. If I infect your computer with malware that installs a second USB driver for the hardware I want access to, and this second driver has support for WebUSB, I could theoretically control the driver being used by making a WebUSB request for the device, thereby exposing the hardware for further exploits.
But fine, let's say the malware installs the driver and deletes itself. What then? How are they going to get the browser to navigate to their site, and the user to click the authorization button?
You could do it a number of different ways. For example, could edit the hosts file (a.k.a. etc/hosts) to point to an amended site for a popular website address, could configure proxy settings on default web browser, could alter the browser shortcut to run a script in the background when the browser starts that scans for WebUSB-enabled devices, could set the driver up to check for updates and disguise the authorisation as the driver update confirmation, etc...
The reality is that if this malware gets enough permissions to install drivers, it can certainly talk to a regular device driver and communicate with the web. It doesn't need WebUSB for anything.
When - not if - someone finds an implementation bug in either the browser or the USB hardware, we will see exploits far worse than keylogging passwords. The bug could be in any USB device, not just the subset you're thinking about. Do you really want to trust your host-controller, every USB device, and the browser interface to be bug free? Are you sure there are no subtle non-bug interactions between devices? Have you even seen how USB devices are designed?
Limitations like "no HID devices" are how it's supposed to work, which is different from how it will actually work.
edit:
Also, did everyone forget about BadUSB?
Now, if you have a specific argument to make against my statement, then please share it. I have direct experience with the subject here, and ideally can provide context to address such arguments or clear up confusion. However, I really don't think it's productive to respond with non sequitur arguments and personal attacks.
So, the scenario you seem to be implying would require coordination between a malicious WebUSB site and a malicious device. While I can't claim that it would be impossible, it sure seems to approach de minimis if only given the extent of user interactions and preconditions.
You suggested in another comment that you had some prior background in this area, are you involved in the development of this new web API?
Justin Schuh is a Chrome security engineer and is one of the most knowledgeable people on the planet when it comes to browser security. He knows what he's talking about more than virtually anyone else in this thread.
Someone working for one of the major browsers mentioned they'd considered it but decided against it - not sure on the reasons why but if they're reading this they might like to elucidate...
There isn't easily exploitable issues like XSS on the desktop. Meaning, if you run a desktop app you generally don't have to worry that some rogue code is injected into the app, unless the developers keys are stolen which is rare.
The flaw with that is desktop apps have the ultimate permission model, you choose to have them, and don't just stumble across them.
One big difference is that one chooses to download the software and install it on a computer. In a browser, everything gets downloaded and executed automatically, including scripts. It's just a matter of opening or being redirected to a URL.
Add preloading of links on pages, and you have yourself a constant modifying environment (browser) which is controlled by third parties that don't first require a permission dialog.
So, this is much unsafer than consciously running an executable you've downloaded.
I just tested this on the phone today - it sees even my damn ambient light, in real-time. Why the hell is stuff like this allowed to be seen by default in a browser?
Might be splitting hairs, but it's not like the browser is providing a direct API to that data.
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.
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/ (look for U2F in particular)
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.
> 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.
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.
Just because it's in a browser doesn't mean it's remote access. Javascript APIs can be accessed locally.
Alternatively you could be more constructive and try to explain what your position here is because, as I'm reading this standard, I'm not seeing any remote access (it's all client-side). Granted, like I already mentioned, once access is granted you could use something like web sockets to make it accessible remotely but that's a very explicit thing a developer or malicious app has to do. Which, granted, is possible but the user also has to give it access to do such a thing which is no different than allowing camera access which already exists in a similar way.
If you want to argue that anything that can be coded to be accessed remotely is outright remote access then...well just about everything is remote access and it kinda loses its meaning.
> 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 shows me you didn't even read the standard. The standard OUTRIGHT says the same thing as you and outlines how their standard WOULD NOT grant low level access to the USB bus.
So why even bother commenting if you're not even going to read what's in the standard and comment, incorrectly, about it? This isn't really typical on Hacker News.
Anything that can be accessed client-side can be easily uploaded via XmlHttpRequest or whatever people use for that now. This is not a new concept.
> Granted, like I already mentioned, once access is granted you could use something like web sockets to make it accessible remotely but that's a very explicit thing a developer or malicious app has to do.
Hardly- user data is incredibly valuable and you can be sure that for many sites, if a page has access to USB info they will upload and track it. Presumably any foreign JS code imported (e.g. Google Analytics) can also access this data and include it in the information it tracks.
Correct but this standard is absolutely not "remote access to USB devices" as the parent suggested. If we're going to abstract the meaning of "remote" to anything that can be uploaded by something that can access it then it loses its meaning entirely.
The standard proposes nothing remote from the web to the browser; it's entirely between USB devices and the browser. Saying "allow remote access to USB devices" is entirely misleading hence my original comment.
> Hardly- user data is incredibly valuable and you can be sure that for many sites, if a page has access to USB info they will upload and track it. Presumably any foreign JS code imported (e.g. Google Analytics) can also access this data and include it in the information it tracks.
What's the "hardly" for? You and I don't seem to be disagreeing here.
That being said, I'm a little confused about your definition of "remote" access. If I have a jetty server with a remotely exploitable hole in it, someone who exploits that hole is depending on me running a local client, but I would still consider it a "remote" exploit. In the same vein, someone running a browser that I can compromise with purely code on external websites is still being "remotely exploited." The attack vector requires the client to visit a specific page or click a specific link, but I didn't have to walk up to their computer and insert a USB stick. That's what makes the attack a "remote" attack for me.
But if you read the linked specification you're not doing that. You're giving them access to an abstraction that is quite limited in what it can do. If you had direct access you could reflash firmware.
> If I have a jetty server with a remotely exploitable hole in it, someone who exploits that hole is depending on me running a local client, but I would still consider it a "remote" exploit.
Yes of course that's "remote". It requires network connections to access.
> In the same vein, someone running a browser that I can compromise with purely code on external websites is still being "remotely exploited." The attack vector requires the client to visit a specific page or click a specific link, but I didn't have to walk up to their computer and insert a USB stick. That's what makes the attack a "remote" attack for me.
That's not remote at all. That's entirely client based. The client just happens to load some sort of exploit on its own. If it was really remote you could push a script to the client using its network address.
The client functions the same with or without internet connectivity. The jetty server example does not.
When a browser gets a malicious advertisement or a user gets a malicious cross-site scripting attack, I consider that remote exploit. Yes, it required the client to do something (i.e. visit a malicious page), but there are plenty of things which you can do to create that state without much user interaction. If I might ask, what do you call attacks like these?
I agree though that my Jetty example wasn't a good one, I was just making the point that the exploit was still in client code (i.e. something running on the victim's machine).
Which sucks, obviously, but it's not surprising that there's an attempt to bring the web closer to parity with native, since it seems to be a more tractable problem than stoping what's happening to native platforms.
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).
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?
There could be something similar for USB, where there might not even be any "codecs" (drivers) included by default in browsers, but where there's a defined method of making USB devices available.
You'd still have to install a plugin for each device type that your browser doesn't natively understand, but standardization for how to make specific device types available to the browser would be much simpler. And there could be "rewriting proxy" drivers available for improved security which limits what requests that are possible, preventing most hardware exploits.
Although this might still be too much work for little gain.
Apparently it is, given how highly requested of a feature it is to have everything you could do with VMRC available through the web browser with no plugins or local software.
Again, I still don't think it's a good idea either, but I also don't like a lot of the crazy shit built into modern web browsers for maybe the 1% users, like the mentioned WebMIDI.
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.
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?
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, ...).
> 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.
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...
> 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.
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."
Furthermore, this public registry idea also implies that a USB VID/PID directly correlates with a device. There are USB devices in existence that emulate another USB device in order to utilize built-in drivers (inbox drivers) and maintain compatibility with existing software. There are also different USB devices that use the same VID/PID to identify themselves, because in order to obtain a VID/PID, you have to pay a licensing fee, which is not always feasible to everyone. If this public registry is used, it may create conflicts. If the CORS-like public registry entries are always trusted by the browser, it could even create security concerns where remote computers are allowed to seize control of local USB devices.
It would certainly be concerning if USB devices were firmware updated without users' consent, simply by going to the website of the manufacturer. Or even a web advertisement that connects to USB devices...
In the future we may even see some kind of attack on web servers in order to gain access to the USB devices of unsuspecting users...
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.
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.
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)
Why not WebSATA? WebPCI?
There are certainly a few key actors who would benefit from such a standard (benefits could be time to market), I'm just not sure it's enough benefits for the end user to justify a new standard!
Beyond that, I don't understand any of the other objections. Low level code in a high level language is one definition of power.
I'm not saying its a bad idea, just that this direct path in implementation is.
There are many other (better) ways of implementing it, like the Mozilla light sensor API. If that doesn't satisfy you, you should create a new spec for light sensors combined with a practical implementation and then push W3C to use your spec over Mozilla's.
Unfortunately, it looks like their definition of brightness is a floating point number, and that's the only thing their API exposes. Hopefully future versions of the standard will be updated to better match the real world.
What we perceive as brightness is (a) the number of photons of each wavelength that (b) intersect a given point in space and (c) are exiting in a given direction. Obviously, all of this information can't be encoded in digital form. There's simply too much data to encode, let alone measure accurately. But reducing the data to a simple 1D number renders the data almost useless.
No website will be able to achieve good results if the dynamic color scheme is based on a single number.
That's also why the WebUSB spec is exciting. I don't have to wait for this spec to be drafted, or for browsers to support it, or to live with any shortcomings it ships with. I'm free to create.
There is an opportunity here, but to understand this space, you have to dive into it. There are some excellent books on the subject of colorimetery, but a quick bootstrapped understanding might look like:
1. Your eyes are designed to fool you.
2. How your eyes fool you is determined entirely by the photons that enter it.
3. Each of these photons has a wavelength. The more of them at a given wavelength, the more your perception shifts.
4. What you perceive as color is a combination of wavelengths. But -- critically -- these combinations affect each other. It is not true to say that the more photons that arrive at a given wavelength, the more intensely you perceive that wavelength. It causes a shift in your perception, but this shift is not necessarily a simple increase in brightness.
These are first principles, and it's a very brief sketch of the problem. But everything else follows from this. What ambient light sensors currently do, how APIs are designed, etc is all secondary. The problem is both as simple and as difficult as outlined above.
Now, you can say that this isn't worth tackling, or that the current systems are good enough, and so on. But you'd be missing out on quite an experience. Seeing the type of results you can get from a perfectly calibrated environment is really mindblowing. And the interesting part is, it's impossible for me to describe these results in text, or by showing you a photo, or a video, for the same reason you can't describe an Oculus experience. You have to be there.
Personally, I find colorimetry one of the most intellectually fun and gratifying areas of science.
I feel like something along those lines must already exist for a number of uses.
The trouble is, "whether or not it looks good" is also determined by your environment. Some people have crappy monitors, some people have perfect monitors, sometimes it's nighttime, sometimes your room is being lit by the early morning sun. When you look at a screen, all of these factors combine, and leaves you with the impression that something looks good or looks bad.
It gets worse. When you look at a monitor, what's behind your monitor is usually the most important thing. I.e. is the wall in front of you white, or green? Is it dark, or lit by the sun? That's going to affect how you see what's on the monitor. What's behind you is irrelevant, because you can't see it! It doesn't matter at all if the wall behind you is white or black, except insofar as it affects the colors of the wall in front of you. So not only do you need to account for all of the factors outlined above, but the damn thing needs to be aimed properly. I'm pretty sure that the right answer will look something like a sensor that mounts to the back of a laptop screen. But it also needs a sensor pointed at your face, and another sensor pointed straight at your monitor. Only at that point do you begin to have enough information to start writing a program that can make correct decisions.
Fiendishly difficult, no? Quite fun in any case.
Simple. Deliver a native application with your device sensor that the user has to install (maybe it could even be automatically installed through PnP). This application would provide a webserver on localhost which exposes the lighting information to interested websites. And in contrast to the WebUSB thing it would mediate the access to the USB device (lots of browser windows and processes can get the information instead of only a single one) and it would guarantee that only the relevant information is forwarded and not arbitrary data on an USB channel.
I'm a big fan of native apps over web app. But web apps have a huge practically that's hard to ignore.
And you still have the question on how the web app comes to the user: Through a dedicated intranet site? Makes sense if more than one user requires it, but the effort seems similar as packaging a native application and rolling it out automatically through the ITs deployment system. If only very few users (maybe only a single one) requires that hardware both approaches have a high overhead and supporting the device will be most likely rejected.
Getting this web app directly from a third party site will be mostly out of question for the companies you are talking about. Besides the security implications then we also talk about reliability problems ("I can't use my USB device because internet is down...")
If you look at the spec it doesn't directly access hardware and it even acknowledges doing so could be a big security issue. You interface with an abstraction that sits above the hardware that won't give you direct access but, instead, access to a subset of options that pass through the abstraction.
> Through a dedicated intranet site? Makes sense if more than one user requires it, but the effort seems similar as packaging a native application and rolling it out automatically through the ITs deployment system.
I'm not sure how you can compare the rollout of a native application to all user computers versus publishing within an intranet. They are not even in the same league in terms of deployment. Intranet is far, far easier. The native application has to be pushed out, installed and verified. A web app simply has to have its link emailed to users. Hell you could even push out a bookmark over many IT management systems (which is far easier than dealing with pushing out an application).
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?
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...
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.
Hell people are still complaining about full screen permissions pop-ups and no browser has gotten rid of them yet because they know the problems that could come from it.
If anything there is a push to go the other direction, making previously "enabled by default" things behind permissions.
https://news.ycombinator.com/item?id=7677898
https://news.ycombinator.com/item?id=5968237
You're right that they're (ostensibly) placing emphasis on permissions at the moment, but I don't see that staying the same if websites start adopting and using these features in any quantity.
Well, WebRTC is enabled by default. Exposes your real IP, and allows anyone to portscan your whole LAN.
And that was actually the feature I had in mind in my last paragraph. There is a pretty big push to put it behind a permissions window (at least for local network access).
If such a big mistake is made – releasing info about devices in the LAN, de-anonymizing people, and releasing location data – then what mistakes will be made with WebUSB or WebFilesystemAccess?
I seriously don’t want anything to ever have access to anything unless I grant it.
There’s a reason UNIX has no execute permissions by default for files, and a reason why I use SELinux.
This whole browser shit destroys the whole security model.
I could ask you why SELinux is necessary in the first place, but the fact is that mistakes are made and learned from, and additional software is made to fill in the gaps.
If you want that amount of control, there are plugins that grant it, and using a plugin is much like using SELinux to fill in gaps or mistakes in the platform.
Software will never be bug free, and that's not an excuse to never write anymore software.
The whole act of downloading and installing?
For desktop apps, you have to do that.
For webapps, you just have to visit a page (or even not, thanks to XSS).
And while we install 2-5 or maybe 20 apps per year (at most, some don't install anything after they get their PCs), we visit 100s of pages each day, and 1000s each month.
Also, while we can realistically restrict our app downloads to legitimate sources (the App Store, the product's webpage etc), we read stuff from all over the place -- that's what links are there for.
Fun conversation: I asked someone involved with WebRTC for a real, non-video example, and they honestly suggested "maybe your browser wants to talk to your fridge and would benefit from data channel encryption". So far out of touch with reality.
Wouldn't surprise me in the least if, for instance, this ends up allowing enumeration by default or something else.
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)
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.
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.
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.
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.
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.
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.
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"
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.
Then the FBI asks/orders Yubico (or others) to help bypassing USB dongles remotely?
I think I won't trust such a thing...
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.
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.
Alternatively Servo would be modular enough that I could build a custom version without many features.
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.
The unethical job-security concious part of me is pleading "yes yes yes!! Add more devices to the internet!".
It's already been played with in Chrome a bit: https://developer.chrome.com/apps/app_usb
Would be lots of fun.
* Chromebots - http://www.iceddev.com/blog/chromebots-lowering-the-barrier-... (for controlling arduino via JS using 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/ 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/ 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.
Being able to interface USB with the net is a natural step in the internet of things.
Although I'd imagine latency might be an issue.
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.
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.
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.
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.
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.
People whose computers already do useful things, for free, will obviously think that moving everything into the browser is stupid. But if you look at it from the perspective of the profit-driven companies and people pushing for it, the motivation is reasonable, if evil.
Its big limitation is hardware access, so things like WebUSB, WebRTC, etc are great in my book.
That said, your point is fully valid. The web is a wild untamed place, and without gatekeepers there is no one to impose rules that help people like you.
I think we will overcome that with upcoming toolkits, particularly conversational UI toolkits, but... Well, point taken. :)
Nah, the browser is a graphical terminal akin to X11's original usage.
The OS is out there in the clouds...
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!