Google Developers Create API For Direct USB Access Via Web Pages (softpedia.com) 131
An anonymous reader writes: Two Google developers have uploaded an unofficial (for now) draft to the World Wide Web Consortium's Web Incubator Community Group (W3C WICG) that describes a method of interconnecting USB-capable devices to Web pages. The API, called WebUSB, allows device manufacturers to provide special "registry and landing pages" where they can host JavaScript SDKs for their USB-capable devices. Site owners can load these SDKs as iframes inside their websites, and allow a site to access and relay commands (via the iframe to the browser's WebUSB API) to the actual device. To protect privacy and security, the WebUSB API also comes with a CORS-like system that prompts users for access to their devices to avoid abuse and Web-based fingerprinting. The system is also backward compatible with devices created before the standard's approval (if it gets approved).
That doesn't sound like it could ever be abused... (Score:5, Funny)
That doesn't sound like it could ever be abused...
Re: That doesn't sound like it could ever be abuse (Score:5, Funny)
It's just JavaScript. What could go wrong?
Re: (Score:1)
Indeed. But what other technology would be good for something server side to interact with something on the user's local machine via web browser?
Assuming the security bugaboos can be worked out, I can see this being good for things like authentication
Re: That doesn't sound like it could ever be abuse (Score:5, Insightful)
Yes, give remote code the ability to talk directly to a DMA capable device. No problems there. This and webGL could literal be a disaster if someone slips up.
Re: That doesn't sound like it could ever be abuse (Score:5, Insightful)
Not if; when. I can see this code being used as a vector to flash rogue firmware to devices. DMA access? We already have a problem with hardware slurping keys out of RAM with DMA... now imagine websites that can get this ability. I can see ransomware using this ability to bypass many different things to ensure a computer is unusable, perhaps even firmware flashes so the computer's BIOS runs the ransomware on that level.
Re: That doesn't sound like it could ever be abuse (Score:4, Funny)
Assuming the security bugaboos can be worked out,
Okay, I admit- that made me laugh. I mean, how hard could it be to work out all the security bugaboos? I see no problem with this plan, none whatsoever, especially based on the phenomenally secure state of the interweb right now. Why, I can hardly wait to plug some of these goodies into my PC to see what happens!
I read the spec. USB device controls (cookies) (Score:5, Informative)
I just read the spec. It might be more accurate to say this API allows USB devices to offer data of their choosing to whitelisted web scripts. The USB device decides what data it gives to whom; web sites can't do anything with random USB devices that don't explicitly offer web endpoints. At the end of the day, it actually doesn't effect security in a fundamental way at all - USB devices can ALREADY send arbitrary data to web pages, just in an ad-hoc way rather than a well-defined , standardized way.
In a way, it's a lot like first- party cookies , with the data on the usb device rather than on the hard drive.
The USB device defines:
https://login.ebay.com/ [ebay.com] may ask me for "username".
No other web site can get anything from the USB device, and the whitelisted URL can only request the specified data item.
Security considerations are of course important. At the same time, JavaScript can ALREADY read your most important USB devices - it can see your keyboard presses and mouse movements. If a USB device wants to send data to a web page, it can already declare itself to be a keyboard and start sending keypresses. (Credit card readers have done exactly this for decades, pretending to be keyboards .) This API defines a standardized way for the USB device to send data in a more secure way than by pretending to be a keyboard.
Yes, one should consider security. With this, primary the security of the USB device- it's one other way for a malicious USB device to do bad things. But USB devices can ALREADY pretend to be a keyboard, use a hotkey sequence to fire up cmd.exe, and run any commands they want. Malicious USB devices are really bad with or without this new API, so the API doesn't increase risk by much.
Re: (Score:1)
JavaScript can't be used to implement a logger... unless you give it access to USB. If this "protocol" is really the way you describe it, then it have absolutely nothing to do with USB. If it's actually allowing JavaScript to access the USB protocol, then it will be a horrible nightmare.
Nothing to see here. Yet.
XMLHttpRequest.send(logmsg) (Score:3)
> JavaScript can't be used to implement a logger.
It can already log anything to a remote server via:
XMLHttpRequest.send(logmsg)
It can already store logs locally:
Document.Cookie('logline1', logmsg);
Now, if and only if a USB device offers to store the log, JavaScript can provide for storage there.
Re: (Score:1)
Intended for cross-platform drivers (html/JS app) (Score:2)
The proposed benefit is cross-platform drivers. Given a USB device that isn't one of the device types with generic drivers built into the OS, a JavaScript driver could be provided that will run on any OS - Windows, Linux, Mac, FreeBSD, Android - anything with a web browser.
Consider as an example a USB-connected sensor board or relay board . The USB device declares that it will accept input only locally stored JavaScript, from file:// URLs. The software can then be an html file with an html GUI and JavaScr
Re: (Score:2)
It does seem as if the intended usage of this protocol is to bring back dongles: want to use the website? You need a "key" to plug in to your USB port. Hooking up a dongled speaker will grant you access to exclusive content, and so on. It seems the proposed protocol intends to make this easier than it now is, getting rid of the workarounds you mentioned.
In a way, it is a return to physical security, locking the key into hardware. But it also runs counter to what Apple and Google are also pushing for, namely
Re: (Score:2)
it actually doesn't effect security in a fundamental way at all
Famous last words.
This API defines a standardized way for the USB device to send data in a more secure way than by pretending to be a keyboard.
Pretending to be a keyboard has the advantage of having a very small exposed section. Most importantly, the part that interacts with the browser has gone through the whole OS stack and it is highly unlikely that the browser can do anything with it that is outside the "receive a key code" area.
Re: (Score:2)
Assuming the security bugaboos can be worked out
You can "work out the security bugaboos" by not allowing fscking remote access to your USB devices (this has to be one of the most braindamaged ideas since ActiveX). This means removing WebUSB, which is a bit of a catch-22.
Re: (Score:3, Funny)
Indeed. Now you can plug in a USB drive you found in the parking lot and infect the entire web with Cryptolocker.
This could be the most productive thing to happen to humanity since evolving the ability to make tools.
Re: (Score:1)
Re: That doesn't sound like it could ever be abuse (Score:5, Insightful)
It's just JavaScript. What could go wrong?
Nothing. Nothing could possibly go wrong with this idea.
As we've seen, the Internet Of Random Things has had a unblemished, stellar record of security and privacy practices. This is because the developers and manufacturers that make Random Things Connected To The Internet are experienced, careful, and spare no expense when it comes to securing these wonderful, life-enhancing gadgets. Your privacy and safety are their first concerns.
Re:That doesn't sound like it could ever be abused (Score:5, Insightful)
That doesn't sound like it could ever be abused...
There have been some eye-opening kernel exploits found using the USB bus, but if that's limited to direct physical access it sound less scary. With this change? Eesh.
This is like a remote control for a chainsaw: it sounds handy, but you know it will end in tears.
Re: (Score:2)
Is there a possibility that this new standard can get my PIN number to my ATM machine card from accessing the USB bus?
Re: (Score:2)
"USB" by itself is ambiguous - there are USB devices, USB controllers, USB hubs, and, yes, the USB bus itself.
Re: (Score:2)
Except it isn't ambiguous when you're talking about the bus. "Universal Serial Bus bus" is just retarded, and I'm surprised you're trying to defend using it.
Re: (Score:2)
Your penerdantry is interfering with your daily life.
Re: (Score:2)
Pretty sure I don't have a "penerdantry", so, no, it isn't.
Re: (Score:3)
Well put.
Re: (Score:1)
Re: (Score:1)
Did someone say remote controlled chainsaw?
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
That doesn't sound like it could ever be abused...
I'll install it right before I fire myself out a cannon without any safety equipment.
My goodness, this is hilariously awful as a use case concept.
If I trust software enough to let it talk to USB, I want to also trust that it is under its own control. Here, even if you thought you could trust it before, it can be changed server-side without notification, so you wouldn't be able to continue trusting it while using it. You wouldn't need to get infected with a virus or malware to lose control of your USB device
Re: (Score:2)
That doesn't sound like it could ever be abused...
I'll install it right before I fire myself out a cannon without any safety equipment.
A USB connected cannon?
Re: (Score:2)
That doesn't sound like it could ever be abused...
I'll install it right before I fire myself out a cannon without any safety equipment.
A USB connected cannon?
On the internet, just ask and you shall receive [amazon.com]...
Re: (Score:1)
Re: That doesn't sound like it could ever be abuse (Score:1)
Re: (Score:2)
Yes it could be abused. However Google tried to put in safeguards in their specs that is a bit more useful then Microsoft did with activeX which is still the bane of Internet security.
However the web is no longer a content delivery engine but a cross system application platform. Sure you may not like it, but it turned out it be that.
But as an application platform it will need to grow and change with the times. If not then you will get less planned out 3rd party crap again on your browser like ActiveX, Java
W3C API for Google products (Score:5, Insightful)
Remember when Pale Moon devs wrote:
This API is for ChromeOS 100%
Re: (Score:2)
Spelling and grammar issues aside, the AC's post is more salient than one might think. More often than not, in this area, standards are made from things that have demonstrated value and have been incorporated already. They just formalize what exists.
It's a reminder about the dangers of the IoT. (Score:2, Informative)
It's a reminder to us all about how invasive the IoT is and will be. It reminds us that even the most mundane activities, the ones we do even without really thinking about doing, will be monitored by IoT devices. This information will be collected and sent to various corporations for them to analyze and mine as they see fit.
It isn't mundane activities that will be tracked, either. Activities that one wishes to remain private will be tracked, too. Even urination and defecation won't be spared from the invasi
Re: (Score:1)
Who says anybody has to use this IOT? Just don't buy things that are IOT enabled. May be difficult to avoid, or not. I guess we will find out.
Re: Reasons why I don't like the Internet of Thing (Score:1)
Almost all TVs are IoT now. It won't be long until the same is true about smoke detectors, light bulbs, toasters, washers, driers, surround sound systems, doorbells, door locks, garage door openers, toilets, and computers in general.
Re: (Score:2)
42) Internet of Things devices could let advertisers use the data unsuspectingly collected about me while I bake cake.
THIS is the one that really rustles mah jimmies. Those thievin'' bastards from Sarah Lee would sell me down the river in a heartbeat to get their dirty, secret-stealin' hands on mah special Chocolate Praline Cheesecake [royalrecipes.com] recipe!!
What could possibly go wrong? (Score:2, Interesting)
How long until the "security" is bypassed and websites can arbitrarily access any and all USB devices on the system?
Re: (Score:3, Insightful)
Re: (Score:2)
Wow, you're optimistic. I figured about 3 minutes.
What could POSSIBLY go wrong? (Score:1)
You might as well make a Web API that silently installs a kernel driver at this point.
Re: (Score:1)
If it's a sandboxed kernel that doesn't sound so bad except for the silent part.
Web APIs are the future. I only do GPU coding in WebGL because it is the most cross-platform, and I only bother writing applications in Javascript for the same reason.
Um. Hell No. (Score:2)
If the driver doesn't exist for your PC's OS (Score:2)
Say you have been given a particular USB device as a gift, but the program to make the USB device work is available only for Windows, and your computer runs GNU/LInux. Would you prefer to buy and install a copy of Windows or refuse the gift?
Or if you happen to be a Windows user, I will reword:
Say you have been given a particular USB device as a gift, but the program to make the USB device work is available only for OS X, and your computer runs Windows. Would you prefer to buy a Mac or refuse the gift?
Or are
Re:If the driver doesn't exist for your PC's OS (Score:4, Insightful)
I'd rather not bind USB devices to only work under a web browser.
It's the job of the OS to manage the hardware. To codify a bypass to let a particular application do whatever it wants seems unreasonable.
Note for USB devices, this is relatively more rare, as the USB forum codifies standards so that different vendors of common devices all look the same. A usb mass storage device has the same abstraction regardless of underlying technology. A usb network device is implementing one of a handful of network protocols (there have been some revisions on that setup). A usb camera looks the same regardless of vendor.
So if you have some wacky precious snowflake of a device that is so cutting edge that no driver model has been established for it, this lets a hypothetical web app skip a few months of hand wringing waiting for a standard. In exchange for this modest benefit, you are discouraging pursuit of standards, empowering javascript to do more insidious things, and discouraging device support for non-browser access (there are more applications on a system than a web browser, and encouraging device vendors to target the browser *instead* of the OS driver model is just nasty).
Re: If the driver doesn't exist for your PC's OS (Score:2)
Re: (Score:2)
You need to buy Windows to virtualize Windows (Score:2)
99% of USB devices work with completely generic drivers.
True only because keyboards, mice, and flash drives are produced in mass quantities. I was referring to more specialized devices that do not "use[] completely standard protocols", such as printers, webcams, and fitness trackers.
Plus there's USB passthrough for virtualization anyway, so worst case you can jus fire up a Windows VM.
Virtualizing Windows requires purchasing and installing a genuine copy of sufficiently recent Windows for a given machine.
In addition, running a second OS alongside your primary one also requires purchasing data transfer allowance from your Internet service provider to keep that OS u
Re: (Score:2)
Take your stinking javascript off my USB devices, you damned dirty Google! - George Taylor
Re: (Score:2)
I don't care if it is javascript or some other language, the problem is the part where it runs in a web browser, which is capable (designed primarily for, even) loading code provided by the server.
People talk about using it for authentication, but that can already be done with existing authentication protocols. Sure, it needs a client-side helper app, but places that are too strict to have the auth helper are going to be disabling any USB ports if this is going to be enabled in the browser; and maybe preemp
ActiveX again? (Score:5, Funny)
Did all the Active X developers end up at Google?
Re: (Score:1)
Difference between ActiveX and web APIs (Score:2)
The key difference is that ActiveX controls ran as native code with full permissions to everything in your user profile, while these web APIs run as managed code with finer-grained permissions. How common are JavaScript sandbox escapes lately?
Re: (Score:2)
But how much do you put within reach of the sandbox? Given the open ended nature of the beast, what are the hopes that a browser can competently present a user with a specific enough warning about what's about to happen to allow them to make an informed decision?
Re: (Score:2)
Well-known use-after-free bugs in webkit hacked the 3DS and PS4.
Intentionally leaving a game console unpatched (Score:2)
But there's a big difference between video game consoles and PCs in this respect. The owner of a PC is more likely to allow these defects to be automatically patched as they are discovered and fixed because the user has a legitimate way to install homemade software. On a console, on the other hand, the user is more likely to leave them unpatched because they are the only way that a user can run homemade (that is, unapproved) software.
Just wait for the ad's to abuse this / DMCA bs (Score:2)
Just wait for the ad's to abuse this or even some DMCA bs.
No you can't run our app in a VM as that VM let's you bypass our usb dongle
config gui held random (Score:2, Insightful)
If this is widely supported, vendors will use it to build configuration GUIs for their USB devices.
No internet connection? Device doesn't work.
Vendor's website down? Device doesn't work.
Vendor out of business? Device doesn't work.
Vendor sold to EvilCorp? Pay $10/mo for a support contract to EvilCorp so your device that worked fine for years will continue to work.
Re: (Score:2)
I don't see how this is any different than driver packages today. If you have no internet or the company goes out of business then you can't download the drivers. If you have drivers on a CD then they still work. The configuration webpage/app that uses these JavaScript APIs on that CD will still work too.
Re: (Score:2)
The point the GP is trying to make is that this opens the door to vendors requiring an active internet connection to their servers just to be able to configure (or possibly even just use) your widget. If anything happens to that company, you could lose meaningful use of said widget.
We already have stuff like this. Look at the Logitech Harmony Remote. You have to connect to their online service to be able to configure your remote. If their service ever died, you lose the ability to configure your remote.
Not all that new. (Score:2)
Chrome could talk to HID devices for a while. That is how Fido USB keys worked.
I hate Javascript....
Re: (Score:3, Informative)
On linux, Google Chrome requires you to enable the ability in your kernel that permits arbitrary processes to read the memory of other processes.
Originally intended for debuggers, apparently Google's web-browser won't run unless it can spy on any process in the system.
Nice work Google. Change your motto to "Do evil", please
Re:We all know this is unwise. (Score:4, Interesting)
Can you site a source to validate this claim?
Re: (Score:2)
And by 'site' I mean 'cite'. :)
Re: (Score:2)
Only myself.
I'm running Gentoo and I remember a few years ago, when installing Chrome, it required that I enable a config option in my kernel that would give it the access I mentioned.
At the time I thought "? Why would a web browser need that?"
My memory is a bit cloudy on the details, I admit.
It may have been in relation to the V8 thingie that Chrome apparently needs, I believe that may have been the module in question.
Re: (Score:1)
Yeah, that's not true. There was a zero-day about 2 years ago which allowed RCE, but that was patched quickly.
To get U2F to work requires some additions to udev rules, but that's about it.
Skeptical... (Score:4, Interesting)
It seems the goal is to empower developers to skip the pesky wait for actually standardizing around 'novel' device types by giving the browser pretty open ended access to USB devices...
As a rule, I do not believe OSes themselves allow open ended access to any device by an unprivileged user process (e.g. a browser process), USB or otherwise. So it would seem the OS model for hardware would be in the way. Incidentally, this problem should be taken as a huge red flag as why this may be an ill-conceived idea.
I would worry that should this strategy be encouraged, we would see devices that *only* are usable within a web browser. This is the first time I can recall any managed runtime environment trying to implement an independent driver model of the underlying OS. This strikes me as particularly bad form.
In general, Javascript can't even access arbitrary files owned by the user. This is a good thing. This is flying pretty firmly in the face of Javascript in browser being a domain specific language that has *some* security by virtue of explicitly not being allowed to do everything to a system.
Re: (Score:2)
Actually, allowing unprivileged code to control most USB devices has actually been the norm for the better part of two decades. For example, OS X requires code to be privileged if it wan
Re: (Score:2)
I just skimmed the article, so I'm not sure who is in control over the lists or whatever—just that a list would exist. :-)
Demand more from the vendors... (Score:2)
When the vendors are doing such lazy crappy things, trying to enable them is not the answer.
Those vendors doing sloppy things lead to very unstable and insecure things. These vendors are actually largely to blame for the poor security/reliability of Windows ecosystem in practice, despite MS actually having done an adequate job of making a decently sound security infrastructure. If you avoid the shovelware, Windows tends to run OK. This would enable OS destabilizing/security problems from a browser.
So, kinda libusb for JavaScript? (Score:2)
My first thought was that they were basically doing libusb bindings for JavaScript (and then exposing those bindings within a web browser).
But, no, those bindings already existed: https://github.com/schakko/nod... [github.com]
I must be missing something. I'll go dig for technical details to try and figure out what.
Re: (Score:2)
Bindings for nodejs doesn't mean those bindings are in the browser.
I am not sure what the purpose of binding libusb if you can run your own code on the computer. Just run native code.
Virtualization EUC (Score:2)
USB designed for semi-permanent peripherals (Score:2)
Re: (Score:2)
On the upside, traditional USB is so simple that it can be made reasonably secure, if anyone cares to do so. Devices can't really initiate anything, they can just wait for the host computer to get around to listening to them or assert a flag that they need servicing, hoping that the host computer cares. It is also slow enough that you can play microkernel and sandbox the USB device drivers, preventing them from messing up too badly. Once that is done, you "just" have to audit your USB host controller driver
Not far enough (Score:2)
April 1st was two weeks ago (Score:2)
Shit!
Cheap Hardware Appliance, No OS Required (Score:2)
Is this something new? (Score:2)
Nobody read the spec (Score:2)
W3C to next approve WebSystemd (Score:2)
What Could Go Wrong? (Score:2, Insightful)
How the bloody hell did these two morons (this idea really confirms this) get a job as Google developers? There is no such thing as perfect software. It is virtually guaranteed this will be exploited. This "idea" is why JavaScript isn't supposed to have access to anything outside the browser. And the internet is so much safer now then when JavaScript was developed. And also it isn't like i-frames haven't been abused in the past. Yep, perfectly safe.
point of sale hardware (Score:2)
This enables you to write a till or cash register screen and get it to talk to an attached ESC/POS receipt printer and cash drawer and chip and pin terminal and have that run in a browser process with no locally installed proxy process to get access to it. It isn't for your mouse and webcam.
What's the big deal ? (Score:2)
what ? (Score:2)
"What could possibly go wrong?" was rarely written in such big and bright letters.
You're already (IMHO) grossly negligent if your browser doesn't run in a sandbox. But sure, give it USB access. That's only where your keyboard and mouse are also connected. And maybe your external harddrive. The one with the backups.
And for what? Solution looking for a problem?
Re: (Score:2)
I'd probably say something a little less severe. A browser environment should be able to do more, but it should be presumed *not* to be able to do any particular new thing until carefully considered and planned.
For example, I'm all fine with a browser being able to access a camera, with browser requiring a very clear and specific prompt for allowing that site to use a camera. It's something handy and specific enough that a user can make an informed decision based on pretty simply wording.
Basically, specif