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?
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.
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.
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.
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.
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.
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.
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).
XML is like violence. If it doesn't solve the problem, use more.
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.
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...
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...
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.
Can you site a source to validate this claim?
> 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.