Slashdot Mirror
Google Developers Create API For Direct USB Access Via Web Pages (softpedia.com)
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...
Remember when Pale Moon devs wrote:
This API is for ChromeOS 100%
How long until the "security" is bypassed and websites can arbitrarily access any and all USB devices on the system?
It's just JavaScript. What could go wrong?
You might as well make a Web API that silently installs a kernel driver at this point.
Keep your dirty JavaScript off my USB devices.
Did all the Active X developers end up at Google?
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.
Socialism: a lie told by totalitarians and believed by fools.
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
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.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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.
Chrome could talk to HID devices for a while. That is how Fido USB keys worked.
I hate Javascript....
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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; only the server would need to be cracked! And the trustiness would just pass right through to the user.
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.
XML is like violence. If it doesn't solve the problem, use more.
Is there a possibility that this new standard can get my PIN number to my ATM machine card from accessing the USB bus?
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.
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 you willing to pay more for all USB devices so that they can come with drivers for Windows, OS X, and GNU/Linux?
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 invasive reach of IoT.
Web browsers have no legitimate reason to ever access USB devices. It's bad enough that they already support accessing microphones and webcams. But arbitrary USB devices? There really is no reason for that!
Web browsers accessing arbitrary USB devices is just another step in the IoT being used to watch and data mine your most private and intimate moments.
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?
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?
It must have been something you assimilated. . . .
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
I don't know the meaning of the word 'don't' - J
Well put.
You are welcome on my lawn.
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.
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.
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.
XML is like violence. If it doesn't solve the problem, use more.
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...
I must be missing something. I'll go dig for technical details to try and figure out what.
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, specific use cases should be evaluated and given a mechanism for use with clear capability to have specific security controls if it has widely perceived value.
However, nothing should be enabling the browser to be an open-ended execution environment, as it makes it pretty much impossible for a standard user to understand the possibilities they just granted a remote site.
XML is like violence. If it doesn't solve the problem, use more.
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.
Just cruising through this digital world at 33 1/3 rpm...
Seems like the major virtualization vendors (VMware, Citrix, Microsoft) should have been all over this already with their end-user computing portfolios.
The design of USB was for connecting trusted peripherals semi-permanently to a machine. In that capacity, it works really well. The original design did not account for attaching things that don't trust each other. Whether it's a USB stick you pick up off the street and connect to your machine or one of those "USB charging" plugs in the airport, it's not a situation for which USB was envisioned which means we're going to be seeing security holes in this area for years even as the devices and OSes get better. The starting point is just so poor.
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!
Just cruising through this digital world at 33 1/3 rpm...
Seems perfectly safe to me... https://www.youtube.com/watch?...
How about going the whole hog and proving web API for PCI bus, interrupt handling and DMA? Think about it - drivers written in glorious JavaScript! It will be great.
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 recipe!!
Just cruising through this digital world at 33 1/3 rpm...
Wait. What?!? This is for real?
Shit!
Sounds Interesting - like being able to have a USB appliance without the need of running an OS on it; piggyback on the standards compliant Host OS which would have a browser for accessing and controlling the appliance.
Comment removed based on user account deletion
Comment removed based on user account deletion
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...
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.
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/ 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.
Is this something new? I've plugged things in using USB, and got software updates from webpages before.
Did someone say remote controlled chainsaw?
https://www.youtube.com/watch?...
I see that literally no one read the spec (yes, I realize this is Slashdot). To the creator's credit, they have thought about security from the point of malicious Javascript accessing USB. They spec makes that highly unlikely as the USB device has complete control over who can talk to it. The problem is that as far as I can tell, they have given a malicious USB device yet another way to talk to a command-and-control server and get code execution (albeit in a sandboxed browser, using Javascript). Of course I can already do that by emulating a keyboard, but why add to the list of ways a USB device can screw you?
"USB" by itself is ambiguous - there are USB devices, USB controllers, USB hubs, and, yes, the USB bus itself.
Socialism: a lie told by totalitarians and believed by fools.
Can you site a source to validate this claim?
And by 'site' I mean 'cite'. :)
Would you care to share a few of those (ab)use cases?
> 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.
WebSystemd, you know its coming !!!!
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.
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 JavaScript logic, reading sensors or sending commands with the endpoints defined by the USB device.
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.
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.
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.
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 Applets, Flash, etc... For your standard browsing and such apps will have a limit on what OS they will run on or have different upgrade scheduled.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
A fairly trivial cgi can already do this with the user-space USB API.
"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?
Assorted stuff I do sometimes: Lemuria.org
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.
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 updated. Windows nowadays automatically downloads and installs a 3 GB update every few months. This 3 GB update is far larger and more frequent than that of (say) Ubuntu LTS, which this hurts people who are stuck on satellite or fixed cellular at home because they can't get FTTH, DOCSIS, or DSL service.
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.
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.
I don't know the meaning of the word 'don't' - J
Your penerdantry is interfering with your daily life.
Socialism: a lie told by totalitarians and believed by fools.
Pretty sure I don't have a "penerdantry", so, no, it isn't.