5 ms·

WebUSB was an obviously bad idea right from the start, just like Web Bluetooth was, both of which I believe were proposed by Google. It all comes from this nons

by mtgx 8y ago

WebUSB was an obviously bad idea right from the start, just like Web Bluetooth was, both of which I believe were proposed by Google. It all comes from this nonsense idea from Google that "all devices should be directly connected to the internet" (and thus owned by botnets). Mozilla team, if you're reading, please reject implementing or at least enabling such APIs with extremely high-risk to the user by default in your browser - "sandbox" or not.

baybal2 8y ago
I'm seconding that with demand to sanitize all useless, bug prone APIs google introduced solely for own use.
anfedorov 8y ago
Why is it an obviously bad idea? In light of the work on NaCL, is there still no way you can imagine it could ever work?
- pjc50 8y ago
  What does NaCL have to do with this, it's a cryptography library? The issue is that 99.99% of USB devices aren't designed with the possibility of hostile payloads coming from the host, so the security rests entirely on the webusb permission dialog. Which should be presented as "grant this website administrative access to your computer" but isn't.
  - rrix2 8y ago
    > What does NaCL have to do with this, it's a cryptography library? The other NaCl https://developer.chrome.com/native-client https://developer.chrome.com/native-client
  - anfedorov 8y ago
    Could the browser create a tight whitelist of payloads that are definitely not hostile, then expand it slowly to add functionality?
- myWindoonn 8y ago
  Native Client had layered sandboxes and was still exploited. I suspect that sandboxing, in general, is not right; we must find safety and correctness by construction, not by ad-hoc rules or policy or permissions.
  - baybal2 8y ago
    This is a million dollar question, but it was answered long time ago: there is no substitute for a programmer who knows what he is doing. This is something most companies can't do. Small co., can pull it out that for some times, but as companies grow, the temptation to "simply make money" overwhelms even most principled person.
    - cwyers 8y ago
      The problem is that even when a programmer knows what they're doing, it does not then follow that I want them doing it.
      - digi_owl 8y ago
        "We were so preoccupied with whether we could, that we didn't stop to question if we should"?
taf2 8y ago
How can you build applications on the web that use Bluetooth or USB devices without these APIs? Here there is a lot of hate for web based applications but I think this is because the web unlike native apps has a huge amount of transparency that means we can have solid debate about the approaches and solutions taken. In your closed source native app who knows what you chose for security, tracking and anything else about your app is not transparent. I always prefer web based applications over native. Native means I have far less trust in the application. Is it even using tls for network requests? So many things we can’t see in a native app.
- michaelt 8y ago
  How can you build applications on the web that use Bluetooth or USB devices without these APIs? Same way you use mice, keyboards, sound cards, printers, webcams and so on: a generic, secure interface supported by all device makers, OSes and browsers. The whole benefit of web apps is they demand less trust because they're better sandboxed. Poking holes in the sandbox (like WebUSB) makes web apps worse, not better.
  - kilburn 8y ago
    Yeah, and if the powers that be (browser vendors) don't implement the generic interface you need (e.g.: signature tablets, cash drawers, NFC readers, memory card readers, etc.) then you: a) Don't do it and pivot your company to doing something else. b) Implement your own solution with companion native apps that build this missing bridge. Out of public scrutiny and with many times less resources, but hey: the browser is secure! ;)
- baybal2 8y ago
  >How can you build applications on the web that use Bluetooth or USB devices without these APIs? You simply don't
  - seba_dos1 8y ago
    This shouldn't be downvoted. Web platform isn't a place for device usage like that, that's a Pandora's box.
digi_owl 8y ago
Keep in mind that the big success of the current Google CEO is ChromeOS. Basically a minimum OS booting straight to a browser. As "everything" is supposed to live inside a browser window, there "naturally" needs to be rich APIs for accessing whatever the user may decide to plug into ports or their wireless equivalents. We are going full circle here, with the web "browser" becoming the new leased line terminal. Keep in mind that at the end of the mainframe era, some "terminals" had local hardware that could rival a micro-computer. This is why the X protocol included support for printing, as the printer would be hooked up to the X "terminal" and not the mainframe (DEC had their own wire protocols for talking either to terminals or printers for doing bitmap and vector graphics). Everything old is new again, and i wonder if i will live long enough to witness some rainbowhaired dev blog (or whatever it will be called at the time) about how they are gleefully ripping out all this cruft from the "soon" to be retired web protocol.

by mtgx 8y ago

baybal2 8y ago

I'm seconding that with demand to sanitize all useless, bug prone APIs google introduced solely for own use.

anfedorov 8y ago

Why is it an obviously bad idea? In light of the work on NaCL, is there still no way you can imagine it could ever work?

pjc50 8y ago
What does NaCL have to do with this, it's a cryptography library? The issue is that 99.99% of USB devices aren't designed with the possibility of hostile payloads coming from the host, so the security rests entirely on the webusb permission dialog. Which should be presented as "grant this website administrative access to your computer" but isn't.
- rrix2 8y ago
  > What does NaCL have to do with this, it's a cryptography library? The other NaCl https://developer.chrome.com/native-client https://developer.chrome.com/native-client
- anfedorov 8y ago
  Could the browser create a tight whitelist of payloads that are definitely not hostile, then expand it slowly to add functionality?
myWindoonn 8y ago
Native Client had layered sandboxes and was still exploited. I suspect that sandboxing, in general, is not right; we must find safety and correctness by construction, not by ad-hoc rules or policy or permissions.
- baybal2 8y ago
  This is a million dollar question, but it was answered long time ago: there is no substitute for a programmer who knows what he is doing. This is something most companies can't do. Small co., can pull it out that for some times, but as companies grow, the temptation to "simply make money" overwhelms even most principled person.
  - cwyers 8y ago
    The problem is that even when a programmer knows what they're doing, it does not then follow that I want them doing it.
    - digi_owl 8y ago
      "We were so preoccupied with whether we could, that we didn't stop to question if we should"?

taf2 8y ago

How can you build applications on the web that use Bluetooth or USB devices without these APIs? Here there is a lot of hate for web based applications but I think this is because the web unlike native apps has a huge amount of transparency that means we can have solid debate about the approaches and solutions taken. In your closed source native app who knows what you chose for security, tracking and anything else about your app is not transparent. I always prefer web based applications over native. Native means I have far less trust in the application. Is it even using tls for network requests? So many things we can’t see in a native app.

michaelt 8y ago
How can you build applications on the web that use Bluetooth or USB devices without these APIs? Same way you use mice, keyboards, sound cards, printers, webcams and so on: a generic, secure interface supported by all device makers, OSes and browsers. The whole benefit of web apps is they demand less trust because they're better sandboxed. Poking holes in the sandbox (like WebUSB) makes web apps worse, not better.
- kilburn 8y ago
  Yeah, and if the powers that be (browser vendors) don't implement the generic interface you need (e.g.: signature tablets, cash drawers, NFC readers, memory card readers, etc.) then you: a) Don't do it and pivot your company to doing something else. b) Implement your own solution with companion native apps that build this missing bridge. Out of public scrutiny and with many times less resources, but hey: the browser is secure! ;)
baybal2 8y ago
>How can you build applications on the web that use Bluetooth or USB devices without these APIs? You simply don't
- seba_dos1 8y ago
  This shouldn't be downvoted. Web platform isn't a place for device usage like that, that's a Pandora's box.

digi_owl 8y ago

Keep in mind that the big success of the current Google CEO is ChromeOS. Basically a minimum OS booting straight to a browser. As "everything" is supposed to live inside a browser window, there "naturally" needs to be rich APIs for accessing whatever the user may decide to plug into ports or their wireless equivalents. We are going full circle here, with the web "browser" becoming the new leased line terminal. Keep in mind that at the end of the mainframe era, some "terminals" had local hardware that could rival a micro-computer. This is why the X protocol included support for printing, as the printer would be hooked up to the X "terminal" and not the mainframe (DEC had their own wire protocols for talking either to terminals or printers for doing bitmap and vector graphics). Everything old is new again, and i wonder if i will live long enough to witness some rainbowhaired dev blog (or whatever it will be called at the time) about how they are gleefully ripping out all this cruft from the "soon" to be retired web protocol.