Web USB
-
Access USB Devices on the Web | Capabilities | Chrome for Developers
The WebUSB API makes USB safer and easier to use by bringing it to the Web.
The WebUSB API lets you interact with the all USB transfer/endpoint types:
- CONTROL transfers, used to send or receive configuration or command parameters to a USB device are handled with controlTransferIn(setup, length) and controlTransferOut(setup, data).
- INTERRUPT transfers, used for a small amount of time sensitive data are handled with the same methods as BULK transfers with transferIn(endpointNumber, length) and transferOut(endpointNumber, data).
- ISOCHRONOUS transfers, used for streams of data like video and sound are handled with isochronousTransferIn(endpointNumber, packetLengths) and isochronousTransferOut(endpointNumber, data, packetLengths).
- BULK transfers, used to transfer a large amount of non-time-sensitive data in a reliable way are handled with transferIn(endpointNumber, length) and transferOut(endpointNumber, data).
This specification defines a way for the device to provide the UA with a set of static data structures defining a set of origins that are allowed to connect to it.
The methods above are the ways [TN: none really] in which this specification attempts to mitigate this attack vector for once the device is under the control of an attacker (for example, by uploading a malicious firmware image) there is nothing that can be done by the UA to prevent further damage.
This specification recommends device manufacturers practice defense in depth by designing their devices to only accept signed firmware updates and/or require physical access to the device in order to apply some configuration changes.
BUT YOU NEEDED PHYSICAL ACCESS TO SEND USB PACKETS BEFORE ANDROID NEEDS ROOT ACCESS FOR IT NOW YOU LET ANYONE WITH A WEBSITE SEND LOW LEVEL CONTROL TO ALL MY PERIPHERALS WHY
-
https://what.thedailywtf.com/uploads/system/site-logo.png
The emoji form is too damn small to indicate the levels of wrong here.
So not only is there a major
in 'why u let internet have control over hardware it has no fucking business having control over', they're then expecting the hardware manufacturers to practice defence-in-depth. It's not their fucking responsibility to protect against this kind of shit.
-
From the linked page:
this will make USB safer and easier to use by bringing it to the Web.
u serious ???
Someone there has extremely strange notions of "safe" and "easy to use"...Also this:
@Arantor said in Web USB:The emoji form is too damn small to indicate the levels of wrong here.
-
This specification recommends device manufacturers practice defense in depth by designing their devices to only accept signed firmware updates and/or require physical access to the device in order to apply some configuration changes.
We're boned. How boned?
@accalia said in Firefox 41-50 is well and truly fucked:
surgical steel anal beads
-
It's not their fucking responsibility to protect against this kind of shit.
Actually, it is, but not because of shit like this... Or at least, it shouldn't be because of shit like this.
It is their responsibility because of other nasty things that can happen to USB things out in the wild, from plugging your phone in to a random USB charger to getting your keyboard's firmware remapped or something by a virus-laden PC.
But really, guys, did we need to make it worse?
-
This specification defines a way for the device to provide the UA with a set of static data structures defining a set of origins that are allowed to connect to it.
If by default this set is "none", then it might not be a catastrophe.
If by default it's "all"... Well, enjoy your remote keyloggers, mouse manipulators, keyboard manipulators, printers printing meatspin in a loop, and all the assorted goodness.
-
@Maciejasjmj said in Web USB:
This specification defines a way for the device to provide the UA with a set of static data structures defining a set of origins that are allowed to connect to it.
If by default this set is "none", then it might not be a catastrophe.
If by default it's "all"... Well, enjoy your remote keyloggers, mouse manipulators, keyboard manipulators, printers printing meatspin in a loop, and all the assorted goodness.
It looks like it's none?
said:
The WebUSB API does not even try to provide a way for a web page to connect to arbitrary USB devices. There are plenty of published attacks against USB devices that makes it unsafe to allow this.
For this reason, a USB device can define a set of origins that are allowed to connect to it. This is similar to the CORS mechanism in HTTP. In other words, WebUSB devices are associated with a web origin and can only be accessed from a page from the same origin.
Hardware manufacturers will have to update the firmware in their USB devices in order to enable WebUSB access to their device via the Platform Capability descriptor. Later a Public Device Registry will be created so that hardware manufacturers can support WebUSB on existing devices.
-
@sloosecannon said in Web USB:
Hardware manufacturers will have to update the firmware in their USB devices in order to enable WebUSB access to their device via the Platform Capability descriptor.
Well, then we're only fucked with regard to developers enabling it and then misimplementing it.
So still pretty fucked, but maybe not doomsday-fucked.
-
- No devices right now support this webusb thing, ergo 'legacy' behavior will be what will happen
2a. If there's a blacklist then 'legacy' devices not mentioned(aka everything not(brand-name AND not EOLed) will be free game
2b. If there's a whitelist then control would be limited to manufacturer's website(which is on no point in time compromised
) and since its application would be so limited else, manufacturer would broaden the URL range to effectively 'anyone with a website'. - 'developers enabling it and then misimplementing it' does not cover the web browser. Just consider in webdev, cross-domain policy is intentionally overlooked for JSONP to work. Do you think there won't be a way to bypass whitelists, due to either bug or design?
Seriously, this is early 00s 'virus scan through browser! yay!' all over again.
You can't expose computer internals to the INTERNET. Not even pretty please a wee bit we won't do harm we promise.
Not exposing internals has been the invariant of the JS environment. That's why only JS remained, out of browser programming platforms.
ok, it's not the actual reason, but it's a reason too
- No devices right now support this webusb thing, ergo 'legacy' behavior will be what will happen
-
The sad part is... I can see the use for this. Now, I don't know how it is in y'all's woods and their necks, but over here we do a lot of banking/government stuff online by using either USB tokens or smart card readers. And it's all browser-based. Which... has ups and downs, but overall it's OK IMHO.
Now, there's a problem. How do you read a token from a website? Currently, there is only one solution: Java. Java, which relies on old plugin system that browsers are now deprecating. Java, which needs constant updates because there's 17 new security holes found daily. Java, which pretty much every sysadmin hates.
See, this web USB stuff would fix that. We'd just have a dandy little standard and everything will be rosy!
Yeah, I know, it's a can of worms and it will probably end in tears.
And as a side note, FF has something like that already:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11/Module_Installation
The sites I was setting it up for still required Java, but hey, it's a start. And if it were done that way, and ONLY that way (meaning - explicit installation that takes actual effort and time, fuck being "simple" here, you better well fucking know what you're doing OR follow instructions from a reliable source), it could work.
Could.
The actual result will probably be popcorn prepared on a nuclear fire. But hey. Popcorn!
-
Yeah, I know, it's a can of worms and it will probably end in tears.
It's a can of worms, with the added twist that in addition to containing worms, the can is made of worms.
And the worms are venomous.
And fire-breathing.
With claws.
And fangs.
And wings.
In short, they aren't worms. They are wyrms.
-
@Steve_The_Cynic said in Web USB:
In short, they aren't worms. They are wyrms.
And there I was, hoping it's a Shai-Hulud
-
over here we do a lot of banking/government stuff online by using either USB tokens or smart card readers
British banks have card readers for certain online transactions, where you insert your Chip & PIN card and enter the challenge code the site gives you, and you get a response code to enter into the website. And all that's needed is plain old HTML.
-
@RaceProUK that's just 2FA, which is all cool for authentication. And is used for personal accounting.
The systems that use the complex stuff is for companies and legal entities. The token or smart card contain a private / public key pair that are used to sign any transaction you approve though.
Is this strictly necessary? Dunno, maybe not, but I'm not qualified to go into legalities behind it.
-
I can see the use for this.
Of course there's a use for this. The use is "circumvent any and all OS security measures designed to protect the integrity of your USB devices because security is annoying and I want my grumpy cat".
-
This specification recommends device manufacturers practice defense in depth by designing their devices to only accept signed firmware updates and/or require physical access to the device in order to apply some configuration changes.
No! You made the bed, it's you that should lie in it! Guess everyone'll need this now:
Then again, people should be using this anyway, since plugging your phone into random USB ports is generally a bad idea.
-
This specification recommends device manufacturers practice defense in depth
Yes, because we can trust the Chinese company producing 5 cent lowest-cost devices to invest time and effort into securing them
-
make USB safer and easier to use by
bringing it to the Webexponentially increasing the size of attack vectors.
-
@Sumireko Oh, that's neat! To bad shipping to Europe makes it quite expensive...
The widget seems relatively large for what it does, does cutting a few cables really require a couple of sq. cm of electronics?
I wonder if they could make it into a USB cable, with a physical switch to turn on/off the data transfer (it has to be physical to be secure given the goal here...), so that you can use the same cable all the time? That would make it usable all the time and without having to think about it.
-
Somewhere around 2010, a bunch of people decided they'd turn HTML+javascript into a full-fledged app platform.
Now, an "execution environment" or "app platform" or whatever you want to call it is essentially composed of two parts:
- A Turing-complete instruction set. In this case, Javascript, but it doesn't really matter since we know every turing-complete machine can ultimately run any code from any other one (with varying degrees of efficiency).
- A set of "system calls" or "APIs" that let the program communicate with the outside world. THAT's the meat of the matter. It defines what the system can do.
At the time, the only thing HTML+javascript was allowed to do was make network requests (with lots of security restrictions) and show stuff on screen. Not like all those other pesky platforms (like the supposedly sandboxed Java), which all had dozens of clearly unnecessary APIs to access hardware and other stuff.
So, those people probably thought they were being very clever by turning HTML into a platform. "Hey, it has perfect security! It can run arbitrary code without compromising the system! Woo!"
But then people actually started using their platform, and they started complaining. "Why can't I get images from the user's webcam?" "Why can't I get the user's physical location?" "Why can't I make full-screen games?" So they started adding an API for this thing, an API for that thing, and an API for that other thing, and soon we'll have an API for low level USB access and an API for bluetooth devices and an API to connect to wifi networks and an API to access fingerprint readers...
In short, they're reinventing the wheel very slowly, and by "wheel" I mean Java.
-
@Sumireko Here's a cheaper option that's currently available and works similarly (I have two, and rarely use it for its namesake of charging a PS Vita over USB):
-
BUT YOU NEEDED PHYSICAL ACCESS TO SEND USB PACKETS BEFORE ANDROID NEEDS ROOT ACCESS FOR IT NOW YOU LET ANYONE WITH A WEBSITE SEND LOW LEVEL CONTROL TO ALL MY PERIPHERALS WHY
I like this issue…
My main issue is what the fuck were these idiots smoking?! Entangling a domain you need to keep secure with a domain you cannot secure? What could possibly go wrong.
I look forward to when some random webpage reprograms everyone's keyboard to spurge in utterances of, say, sexual attraction to farmyard animals into everyone's social media account. Because there's no way that some bored script kiddie won't think of doing something so obvious for laughs.
-
@anonymous234 I can see it. Hell, with Nude.JS JavaScript is already fulfilling a major aspect of what Java was supposed to do in an objectively shittier way. Why not go whole hog?
-
-
@RaceProUK said in Web USB:
British banks have card readers for certain online transactions, where you insert your Chip & PIN card and enter the challenge code the site gives you, and you get a response code to enter into the website. And all that's needed is plain old HTML.
I liked the way some German banks started doing it a few years ago: they use JavaScript to display a flickering pattern that your card reader picks up with a set of five photodiodes. That way the reader can display the transfer amount and the receiver's account number on its internal display and you're sure no malware is showing you different data from what you're actually authorizing—and you don't even have to enter a challenge code.
-
-
@anonymous234 If it works on animated gifs we may need this for article comments
-
@RaceProUK said in Web USB:
This specification recommends device manufacturers practice defense in depth by designing their devices to only accept signed firmware updates and/or require physical access to the device in order to apply some configuration changes.
We're boned. How boned?
@accalia said in Firefox 41-50 is well and truly fucked:
surgical steel anal beads
These are surgical steel anal beads that are also magnetic. So they pinch your colon. And then an external magnet drags them backwards through your digestive system. And then they are also explosive.
-
@anonymous234 said in Web USB:
"Why can't I get images from the user's webcam?" "Why can't I get the user's physical location?" "Why can't I make full-screen games?"
:eye_twitch:
-
@anonymous234 said in Web USB:
an API to connect to wifi networks
Pretty sure Chrome already has this, as I witnessed it fucking my Wi-Fi settings temporarily while I was setting up Chromecast.
-
@Lorne-Kates man, you really are a Luddite for not updating your browser eh
Look at all the fun you're missing out on
-
code on the web can be updated quickly in response to reported vulnerabilities. Very few driver packages are.
..and what if it isn't? The only fallback you have is relying on vendors to temporarily disable this API, like Apple did with Flash a few years ago, when a significant security vulnerability rears it's ugly head. Hardware drivers are fundamentally different from "code on the web", you can't reasonably compare the two unless your only criteria is that they both contain "code". Unlike network requests, the problem is not verifying who sent the request. The problem is arbitrary code execution on a physical device. All this talk of CORS is completely missing the point! They're trying to apply web-centric thinking to hardware. It doesn't make any sense.
Who is this for? Is there even a single use case?
-
Who is this for? Is there even a single use case?
Getting printers working in Linux
-
@bb36e I don't understand how this would help.
-
@bb36e I don't understand how this would help.
We can write the drivers in the cloud, serverlessly
-
We can write the drivers in the cloud
We already have that: Google Cloud Print.
And it works wonderfully
Internet of $@!%: Google API change triggers Epson printer revolt
Printers caught in reboot loop after API change causes firmware fail.
-
Getting printers working in Linux
Linux is saving the environment: stop wasting paper and toner !!!
-
Now, there's a problem. How do you read a token from a website? Currently, there is only one solution: Java. Java, which relies on old plugin system that browsers are now deprecating. Java, which needs constant updates because there's 17 new security holes found daily. Java, which pretty much every sysadmin hates.
See, this web USB stuff would fix that. We'd just have a dandy little standard and everything will be rosy!That's not 100% true, try something like https://my.af.mil (you'll get a cert error if you don't have the DOD roots installed). They do a cert request from the system, and it works with a CAC (smartcard) without having to have any plugins installed.
-
@bb36e I don't understand how this would help.
Well, actually I can think of a use case because I'm trying to do something similar through Hosted Web Apps.
Basically, what a Hosted Web App does is create a WebView of a website you determine in advance (and you have to whitelist all URIs you want the app to have access to). It also injects the WinRT API into the WebView and makes it accessible through Javascript.
Which means that you can publish code to the client inside the WebView from the webserver - which in turn means that you don't need to update the app itself. Just update the code on the server and every client will have the updated code instantly.
An actual application would be a hybrid website for my pupils - say, for example, a set of instructions for a particular experiment. If they're calling the website through a normal browser, they'll only see the instructions. If they're calling the website through the app they'll get an extra instruction to plugin the USB measuring instruments we already have - after which the instruction steps will include the live measuring data. And if they then access the site again without the app, they'll still see the instructions and the measuring data they captured.
With Web USB, the HostedWebApp would be superfluous.
-
The sad part is... I can see the use for this. Now, I don't know how it is in y'all's woods and their necks, but over here we do a lot of banking/government stuff online by using either USB tokens or smart card readers. And it's all browser-based. Which... has ups and downs, but overall it's OK IMHO.
Now, there's a problem. How do you read a token from a website? Currently, there is only one solution: Java. Java, which relies on old plugin system that browsers are now deprecating. Java, which needs constant updates because there's 17 new security holes found daily. Java, which pretty much every sysadmin hates.
See, this web USB stuff would fix that. We'd just have a dandy little standard and everything will be rosy!
Yeah, I know, it's a can of worms and it will probably end in tears.
And as a side note, FF has something like that already:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11/Module_Installation
The sites I was setting it up for still required Java, but hey, it's a start. And if it were done that way, and ONLY that way (meaning - explicit installation that takes actual effort and time, fuck being "simple" here, you better well fucking know what you're doing OR follow instructions from a reliable source), it could work.
Could.
The actual result will probably be popcorn prepared on a nuclear fire. But hey. Popcorn!
Or we could all just use FIDO UDF, but no, must have USB-powered DRM for websites.
-
@pydsigner said in Web USB:
must have USB-powered DRM for websites.
Oh.
No.
NO.
THAT IS NOT THE REASON.NO.
Oh shit. It is, isn't it?
-
@sloosecannon Probably, yeah.
Though to be fair the two use cases (hardware DRM, hardware authentication) are almost identical.
-
@sloosecannon said in Web USB:
That's not 100% true, try something like https://my.af.mil (you'll get a cert error if you don't have the DOD roots installed).
I get a "The server isn't here lol" regardless of whatever certs I may or may not have...
-
@Lorne-Kates Surgical steel would be clean and shiny. These are made out of recycled cast iron, from those failed 1980s GM engine blocks that went all porous and shitty.
-
@Tsaukpaetra Don't worry. They'll be by shortly to say "here we are" - oh and
ON THE GROUND!!!
-
@Tsaukpaetra huuh.
That's weird.
-
@sloosecannon said in Web USB:
@Tsaukpaetra huuh.
That's weird.Not really. Our internet sucks at this place. It's shitty in different ways.
-
@Tsaukpaetra Well it looks like it's broken for me too. So.....
Ooops
-
@sloosecannon said in Web USB:
@Tsaukpaetra Well it looks like it's broken for me too. So.....
Ooops
Fixed it by tacking on an extra www to the beginning of the domain.
Also, apparently they mess with the size of scrollbars on that page...
-
Can anyone tell me why it would be different that a mount point in a unix system?
Amazon.com
Security Risks ahead. · Issue #50 · WICG/webusb
nude.js | Nudity detection with JavaScript and HTMLCanvas
