radio.ea1iti.es
What are the other APIs to have USB access?
Let the "Safari not Supported" era begin!
Nice use of web components!
https://html.spec.whatwg.org/multipage/introduction.html#his...
Anyone who is worried, including corporations, can disable it.
That is an argument against any feature whatsoever beyond maybe a JS-free links/lynx browser. The worse browser bug is a sandbox escape that can obtain root privileges. This has been done by exploiting many different JS features. USB communication is not more of a hazard than webgl or setTimeout().
It is though. setTimeout is very limited. WebGL does lots custom allocations which are ripe for exploits (like the native arrays in JS). USB has all that + the scope of every device plugged in which may come with its own issues.
It's not that this can't be done, it's that this is changing the rules that existing security is built on.
I would try to make it work with whitelists and/or restricting the functionality to browser add-ons rather than plain websites. Both add extra checkpoints where some security can be added back in, or rather perform this "weakening" of the previous security boundary in a more controlled manner.
To put it another way, why is it ok to trust Arduino.exe but not Arduino.com?
Arguably the browser is far more secure. A hypothetical "Arduino.exe" can access anything, not actually select the USB device the user selected due to a bug.
The browser is far more secure because everything it allows access to is tightly controlled, in most cases by scoping it to the website. Even if you grant persistent camera/microphone access, it remains scoped temporally: you need to have the website opened up.
An USB device fundamentally does not support this security model. Code that can interact with an USB device can put persistent state on it without any checks enforced upon it. That USB device may later interact with other (bug-laden) code on the same system, or even worse, be moved to a different host entirely, with a different OS stack there, and trigger interactions there.
Yes, the browser is far more secure — because it has very few (anti-)features like this. I'm incredibly happy that WebUSB is not particularly commonplace to use. Having secure browsers is more important to me than the convenience of USB access from websites.
On the other hand, you don't accidentally install an app.
- most OSes expect a digital signature on "Arduino.exe" these days
- there's a whole ecosystem of protection and antivirus software that attempts to detect malicious use
- depending on your OS, an "Arduino.exe" can't even access USB devices without an additional signed driver and/or further administrative privileges
- a code injection attack against "Arduino.exe" is much harder; unlike "Arduino.com" which can load entirely different on each visit, you need to exploit an (easier to protect) auto-update mechanism. (Depending on the use case, an application can also be just fine without an update mechanism.)
- "Arduino.exe" isn't built on an ecosystem that routinely loads 3rd party code from outside sources
And to repeat, I don't think WebUSB in general is a bad idea. I'm arguing the security model should be more restrictive; that's why I suggested:
> I would try to make it work with whitelists and/or restricting the functionality to browser add-ons rather than plain websites.
The browser add-on ecosystem is IMHO a better framework to build something like WebUSB in, but to be fair I haven't spent thought on a more in-depth evaluation of this. Also note that there's good precedence for whitelist systems, e.g. in WinUSB the USB device itself can already do some signalling. (But that doesn't work for older USB devices and has its own can of worms…)
Which OS are you thinking of? WebUSB doesn't need any additional drivers, so if the browser can do it I assume any app can do it.
[Ed.:] https://github.com/webusb/awesome lists applications using this API. It's 11≈14 depending on how you count. Most of them are pretty fringe, except arguably the 3 update/flash tools and maybe the Android mirror.
I'm not sure I'd expect to have seen a case of abuse here yet.
Or are you thinking only about attacks where the attackers have a genuine reason to ask for USB access? Because IMO that is going to pretty rare, and also not very interesting because in those cases the alternative is you download an executable with unlimited permissions.
But in any case it makes no difference. If the API has been available to 75% of users for 7 years, it's downright idiotic to think making it available to 77% of users will make a difference.
- a large part of privacy issues only exist under legitimate use cases
- a comparatively smaller but still relevant part of security issues would involve attacking (e.g. code injection) a legitimate web application (which the user may already trust) as a first step, and progressing from there
- the fact that such few genuine use cases exist makes users much less likely to accept any illegitimate use, since it will be a permission request box that they have never seen before and haven't been desensitized to
Looking forward to a local webusb+rtlsdr based Flightradar.
If it is indeed not one of them, I'd be interested in getting one to test on, so I'd like to know where you got it from. Can you email me? My address is trivial to find or figure out knowing my website is https://jacobo.tarrio.org :-)
And you can always star it on GitHub: https://github.com/jtarrio/radioreceiver
It is really amazing how flawless it work. You should do a blog post describing how you did it.