3 ms·

Mozilla's position is to not implement this API due to security and privacy concerns, and I agree with them on that even though I'd really like to use this API

Mozilla's position is to not implement this API due to security and privacy concerns, and I agree with them on that even though I'd really like to use this API too.

viraptor 2y ago
Yeah... It's an accident waiting to happen with someone's security key. (Yes, I'm aware chrome tries to protect that one... for now) We really need more intentionality around hardware use. There's many SDR apps already packaged for all systems. Stop trying to juggle chainsaws, please!
- teruakohatu 2y ago
  The UI makes it very obvious as you have to select a device. Anyone who is worried, including corporations, can disable it.
  - Etheryte 2y ago
    The problem isn't the UI, the problem is that like all software, browsers have bugs, and a CVE in this part of the code base could have catastrophic consequences. Chromium and its derivatives are highly reviewed code bases, both by good and bad actors, and there's still a considerable list of CVEs every year.
    - teruakohatu 2y ago
      > The problem isn't the UI, the problem is that like all software, browsers have bugs, and a CVE in this part of the code base could have catastrophic consequences. Chromium and its derivatives are highly reviewed code bases, both by good and bad actors, and there's still a considerable list of CVEs every year. 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().
      - viraptor 2y ago
        > 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.
  - eqvinox 2y ago
    The UI also very temptingly looks like all the website can do is use the device for its intended function, because that's how normal users think and how it should work. But most devices were built with an assumption of trust between the driver and hardware, and now suddenly there's a security boundary there. With this there's an untrusted agent interacting with a device that may have vulnerabilities, which can itself then also interact with vulnerabilities the host may have towards USB devices. 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.
    - IshKebab 2y ago
      What's the difference between a website accessing the USB device, and downloading an app that accesses it? (Apart from the website being more convenient and cross platform.) To put it another way, why is it ok to trust Arduino.exe but not Arduino.com?
      - teruakohatu 2y ago
        > What's the difference between a website accessing the USB device, and downloading an app that accesses it? 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.
        eqvinox 2y ago
        > Arguably the browser is far more secure. 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.
IshKebab 2y ago
Given that it's been available in Chrome for 7 years, if there were any security and privacy concerns we should be able to point to at least one abuse of this API right?
- eqvinox 2y ago
  I'd say predicting instances of abuse of this API is tied to usage of the API, not existence of the API. I'd argue it's extremely generous to say we'd see a case of abuse after 10 deployments of this API. Can we point to at least 10 deployments of this API? [Ed.:] https://github.com/webusb/awesome 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.
  - IshKebab 2y ago
    That doesn't make any sense. The API is available for abuse independently of how many legitimate users there are. 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.
    - eqvinox 2y ago
      I'd argue that: - 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
goodpoint 2y ago
Good!

Mozilla's position is to not implement this API due to security and privacy concerns, and I agree with them on that even though I'd really like to use this API too.

viraptor 2y ago

Yeah... It's an accident waiting to happen with someone's security key. (Yes, I'm aware chrome tries to protect that one... for now) We really need more intentionality around hardware use. There's many SDR apps already packaged for all systems. Stop trying to juggle chainsaws, please!

teruakohatu 2y ago
The UI makes it very obvious as you have to select a device. Anyone who is worried, including corporations, can disable it.
- Etheryte 2y ago
  The problem isn't the UI, the problem is that like all software, browsers have bugs, and a CVE in this part of the code base could have catastrophic consequences. Chromium and its derivatives are highly reviewed code bases, both by good and bad actors, and there's still a considerable list of CVEs every year.
  - teruakohatu 2y ago
    > The problem isn't the UI, the problem is that like all software, browsers have bugs, and a CVE in this part of the code base could have catastrophic consequences. Chromium and its derivatives are highly reviewed code bases, both by good and bad actors, and there's still a considerable list of CVEs every year. 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().
    - viraptor 2y ago
      > 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.
- eqvinox 2y ago
  The UI also very temptingly looks like all the website can do is use the device for its intended function, because that's how normal users think and how it should work. But most devices were built with an assumption of trust between the driver and hardware, and now suddenly there's a security boundary there. With this there's an untrusted agent interacting with a device that may have vulnerabilities, which can itself then also interact with vulnerabilities the host may have towards USB devices. 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.
  - IshKebab 2y ago
    What's the difference between a website accessing the USB device, and downloading an app that accesses it? (Apart from the website being more convenient and cross platform.) To put it another way, why is it ok to trust Arduino.exe but not Arduino.com?
    - teruakohatu 2y ago
      > What's the difference between a website accessing the USB device, and downloading an app that accesses it? 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.
      - eqvinox 2y ago
        > Arguably the browser is far more secure. 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.

IshKebab 2y ago

Given that it's been available in Chrome for 7 years, if there were any security and privacy concerns we should be able to point to at least one abuse of this API right?

eqvinox 2y ago
I'd say predicting instances of abuse of this API is tied to usage of the API, not existence of the API. I'd argue it's extremely generous to say we'd see a case of abuse after 10 deployments of this API. Can we point to at least 10 deployments of this API? [Ed.:] https://github.com/webusb/awesome 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.
- IshKebab 2y ago
  That doesn't make any sense. The API is available for abuse independently of how many legitimate users there are. 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.
  - eqvinox 2y ago
    I'd argue that: - 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

goodpoint 2y ago

Good!