6 ms·

I'm super interested in unpacking the reasons why folks think WebUSB and Web Bluetooth "can't end well" as one user here put it. Would folks mind listing their

I'm super interested in unpacking the reasons why folks think WebUSB and Web Bluetooth "can't end well" as one user here put it. Would folks mind listing their reasons? This is assuming there is some way to install a native app with access to these APIs... But if you are in the camp of "no bluetooth ever" and "no USB ever" that would be totally interesting to know as well :).

snagglegaggle 7y ago
Would you download random native programs and give them hardware access? Really? The issue is exploitation of the USB devices being turned around and used to exploit the OS, or remain persistent in the device. Bluetooth has similar problems but also more.
- staticvar 7y ago
  Aha, yes, we do end up on a lot of random websites. For argument sake, I'm going to assume your objection is not that folks visit random websites, but that there is something dangerous about how we give random websites access to Bluetooth/USB. Here are the ways in which "random websites" can gain access to USB/Bluetooth: 1) Prompt the user to download a native app. 2) Prompt the user to follow a link to an app store for their OS. 3) Prompt the user to allow the website access to the Web USB / Web Bluetooth APIs. My follow up question then is how is option #3 less good than #1 and #2, and "less good" in what ways?
  - xxs 7y ago
    >s how is option #3 less good than.. Going to the app-store allows for reading opinions (i.e. somewhat independent) compared to just clicking, go-on. It shows some download/usage statistics and the like. Also removal of the app guarantees removal, removal of web-works, etc. is significantly more cumbersome. Personally, I have very little trust in browsers (with their constant updates, sort of rushed) and have set deletion of all cookies/storage/etc. on exit - hence convenience is not there. Overall web browsers make for a poor man OS w/o any specific hardware support (unless you count virtualization to a degree) for privileged layer access.
    - Vendan 7y ago
      >Also removal of the app guarantees removal My experience with malware would strongly disagree. Heck, even non-malicious programs have been known to stick around after uninstall (https://apple.stackexchange.com/questions/358651/unable-to-completely-uninstall-zoom-meeting-app https://apple.stackexchange.com/questions/358651/unable-to-c...).
      - xxs 7y ago
        I have no experience with macs, yet I looks like either: - OS issue, not being enable to remove applications (or an exploit) - a chrome one(!), actually chrome installs it on demand as it remembers doing it earlier - likely an url protocol handler. There are worse things with poor solutions including being able to survive OS reinstall... The infamous Minix - "Are you scared yet"[0][1] [0]: https://tech.slashdot.org/story/17/11/07/1041236/minix-intels-hidden-in-chip-operating-system https://tech.slashdot.org/story/17/11/07/1041236/minix-intel... [1]: https://itsfoss.com/fact-intel-minix-case/ https://itsfoss.com/fact-intel-minix-case/
        Vendan 7y ago
        Most common malware is on windows (think IE browser bars and such). As far as the zoom issue, that's just one specific instance that came to mind. Yes, with a proper package manager (like aptitude) that's managing all the files, you are much less likely to have these kinds of things, so yay linux. On the flip side, most consumer OS's (windows/mac) don't go in for that kind of package management, usually relying on the app to be in a single place or have a packaged "uninstall". As far as the specifics of the zoom problem, it's definitely not a chrome issue, as it's a standalone web server running locally, not a url protocol handler. And it's not quite an OS issue, other than that the OS allowed it.
    - staticvar 7y ago
      > Going to the app-store allows for reading opinions (i.e. somewhat independent) compared to just clicking, go-on. It shows some download/usage statistics and the like. That's a great point! Browsers could perhaps start to include metrics like these for website permissions. For example, when the Web Browser prompts for USB access, show metrics like how many people have granted permission to Bluetooth for this website, perhaps even room for comments and ratings. Chrome is afterall trying to be your next app store.
  - user9836 7y ago
    What good prompting the user does if the prompt says: "Would you help to make your beloved app even better?" or "Give permission to use Bluetooth?" We as developers know the technology is not safe. We know users can't know what we know. But we still push it to users. We are not protecting users. We are just transferring responsibility to users and we know that's know "gonna end well" but we're doing it anyway because of what? Because we can? Profit? Chromeos? Why?
    - Ajedi32 7y ago
      > What good prompting the user does if the prompt says: "Would you help to make your beloved app even better?" The prompt doesn't say that though. The prompt text is controlled by the user's browser, not the website. Example of a prompt in Chrome: https://developers.google.com/web/updates/images/2015-07-22-interact-with-ble-devices-on-the-web/bluetooth-device-chooser.webm https://developers.google.com/web/updates/images/2015-07-22-...
      - fredrik-j 7y ago
        Thanks for the example video! I note that the example skipped one crucial step, to scan for available devices. Scanning and enumerating available devices, and selecting a device, is a step where potentially sensitive information is exposed. Will scanning for and getting a list of all available devices be something that a websites can do through the api? Or will the api delegate scanning to the browser, much like the file selector api, where the browser is only exposes the final user selection, the selected file, rather than letting the webapp have access to the entire file system? I.e in this case a list of all available bluetooth devices?
        Ajedi32 7y ago
        No, as you can see in the video the browser lists available devices and the user then selects from that list. The website only ever sees the device the user selects (if any); it can't read the list itself. IIRC there _is_ a separate standard that allows websites to scan for nearby Bluetooth devices but it's via a completely different API with its own separate permissions system.
  - josteink 7y ago
    > 1) Prompt the user to download a native app. 2) Prompt the user to follow a link to an app store for their OS. 3) Prompt the user to allow the website access to the Web USB / Web Bluetooth APIs. 99.9999999999999999% of the websites out there doesn’t or shouldn’t need HW-access. 100% of the malicious websites out there will use this the second it lands. That’s one line of code to land seriously serious exploits. Before their only option was your 1, 2, 3 steps above. Clearly this is a quantum leap forward, for malicious sites first and foremost. The rest of the web isn’t going to give a fuck. So why are we investing in this?
    - staticvar 7y ago
      > 99.9999999999999999% of the websites out there doesn’t or shouldn’t need HW-access. 100% of the malicious websites out there will use this the second it lands. That’s one line of code to land seriously serious exploits. The same can be said for native apps. Are you in the "no Bluetooth/no USB ever" camp? That's totally fair if you are.
- Ajedi32 7y ago
  > Would you download random native programs and give them hardware access? No. But I wouldn't grant a "random" website hardware access either. A reputable native program with a legitimate reason for requesting hardware access though? Sure. Why shouldn't I be able to do the same for a reputable website?
  - nexuist 7y ago
    The case for a reputable website is even stronger given that you can literally inspect the source code as it runs. While a native program might require disassembly and de-obfuscation, a website can only deliver JavaScript that can just be copy-pasted into a text editor. The one exception I can think of might be WebAssembly, but to date most native features (like location, filesystem access, even manipulating the DOM) require interop with JS to be used by wasm.
    - toast0 7y ago
      Plenty of websites minify their javascript, which is on the train to obfuscation. Javascript is definitely obfuscatable if desired.
  - josteink 7y ago
    > No. But I wouldn't grant a "random" website hardware access either. We’ve trained people unskilled in IT that’s apps are dangerous and websites are safer. They’ve finally gotten it. So let’s make websites unsafe, only one click away (which we know users will click)! What a great idea!
    - Ajedi32 7y ago
      Sounds like your only objection is over how scary-looking the prompt is? Running a downloaded executable is already "one click away", and connecting a website to a Bluetooth device isn't nearly as dangerous as running an executable. The difference in levels of access and size of the exposed attack surface is huge.
      - 7y ago
smacktoward 7y ago
From a security perspective, you want to add features only when they're seriously needed, not just because you can. Even if the new feature seems completely safe, there may be some potential way to compromise it you're not seeing, or some interaction it will have with other features that isn't obvious until the two are shipping together. The smallest attack surface is no attack surface at all.
- jancsika 7y ago
  Flip side-- just keep adding features until your userbase is large enough to justify a security team that a) assumes the API is a giant dumpster fire and b) redesigns the system so that it continues to work even when lots of things are burning.
- clinta 7y ago
  From a security perspective you should consider what users are already doing and if introducing a feature can be better security than that. Users are already installing local applications from untrustworthy hardware vendors just to interact with bluetooth devices. I think a web bluetooth standard is an improvement on that.
- hinkley 7y ago
  Commonly known as The Principle of Least Power.
AlexandrB 7y ago
For one thing, I don't want my browser to have low-level access to USB/Bluetooth to begin with. Browsers are already doing too much (see Chrome's built-in malware scanner), and with complexity come additional security issues. Plus, what are the chance that this won't be used for tracking somehow?
- staticvar 7y ago
  > Browsers are already doing too much (see Chrome's built-in malware scanner), and with complexity come additional security issues. That does seem like a common feeling people have. Do you feel your OS is also doing too much as well? > what are the chance that this won't be used for tracking somehow? Are you referring to Browser vendors tracking people or Websites? Surely there will be Websites using this for tracking, they use everything they can. The same is true for apps in App Stores, such a shame.
mgazzer 7y ago
Well, we do know that the best intentions around the browsers technology have paved the way to hell. Some of the other issues that crop up are: * Sites "adding" increased security mentions to their customers by profiling their connected bluetooth devices * Is the browser only able to see connected devices and not the master list of devices? * Bluetooth devices come in such a wide array of formats that I wouldn't want to ever offer the browser access to these tech (it's clunky enough through the OS most of the time) Last time I let this site access my devices and now it's watching me * All those other options you listed below in another reply, are all high susceptible to a man in the middle attack, and all the sudden your headphones have been turned into a weapon, all because you clicked a link. * Getting your laptop's battery drained even more because of some nefarious website preventing your devices from sleeping I feel like we need to build a pretty big moat around USB devices and Bluetooth devices, as they're often the easiest points of entry that can lead to further system compromise.
- clinta 7y ago
  Notice the prompt to select a device: https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web#request_bluetooth_devices https://developers.google.com/web/updates/2015/07/interact-w... I think this mitigates these security concerns and improves security around Bluetooth devices generally. Today if I want to do use the advanced configuration features of for my headphones I need to download a local application and install it. A local app from has way more unwanted permissions and tracking ability than a website. In the future it could be as simple as visiting their website and clicking allow when the site requests bluetooth access.
lern_too_spel 7y ago
It is sour grapes from iOS users who are unable to install a browser that can use this API. As the blog post shows, it is quite useful.
weaksauce 7y ago
mainly because the s in IoT stands for security.
hinkley 7y ago
There’s no security in depth with these devices. Exposing them puts all the security onus into this new layer, which is a tough row to hoe. And we never get these things right at launch.

snagglegaggle 7y ago

Would you download random native programs and give them hardware access? Really? The issue is exploitation of the USB devices being turned around and used to exploit the OS, or remain persistent in the device. Bluetooth has similar problems but also more.

staticvar 7y ago
Aha, yes, we do end up on a lot of random websites. For argument sake, I'm going to assume your objection is not that folks visit random websites, but that there is something dangerous about how we give random websites access to Bluetooth/USB. Here are the ways in which "random websites" can gain access to USB/Bluetooth: 1) Prompt the user to download a native app. 2) Prompt the user to follow a link to an app store for their OS. 3) Prompt the user to allow the website access to the Web USB / Web Bluetooth APIs. My follow up question then is how is option #3 less good than #1 and #2, and "less good" in what ways?
- xxs 7y ago
  >s how is option #3 less good than.. Going to the app-store allows for reading opinions (i.e. somewhat independent) compared to just clicking, go-on. It shows some download/usage statistics and the like. Also removal of the app guarantees removal, removal of web-works, etc. is significantly more cumbersome. Personally, I have very little trust in browsers (with their constant updates, sort of rushed) and have set deletion of all cookies/storage/etc. on exit - hence convenience is not there. Overall web browsers make for a poor man OS w/o any specific hardware support (unless you count virtualization to a degree) for privileged layer access.
  - Vendan 7y ago
    >Also removal of the app guarantees removal My experience with malware would strongly disagree. Heck, even non-malicious programs have been known to stick around after uninstall (https://apple.stackexchange.com/questions/358651/unable-to-completely-uninstall-zoom-meeting-app https://apple.stackexchange.com/questions/358651/unable-to-c...).
    - xxs 7y ago
      I have no experience with macs, yet I looks like either: - OS issue, not being enable to remove applications (or an exploit) - a chrome one(!), actually chrome installs it on demand as it remembers doing it earlier - likely an url protocol handler. There are worse things with poor solutions including being able to survive OS reinstall... The infamous Minix - "Are you scared yet"[0][1] [0]: https://tech.slashdot.org/story/17/11/07/1041236/minix-intels-hidden-in-chip-operating-system https://tech.slashdot.org/story/17/11/07/1041236/minix-intel... [1]: https://itsfoss.com/fact-intel-minix-case/ https://itsfoss.com/fact-intel-minix-case/
      - Vendan 7y ago
        Most common malware is on windows (think IE browser bars and such). As far as the zoom issue, that's just one specific instance that came to mind. Yes, with a proper package manager (like aptitude) that's managing all the files, you are much less likely to have these kinds of things, so yay linux. On the flip side, most consumer OS's (windows/mac) don't go in for that kind of package management, usually relying on the app to be in a single place or have a packaged "uninstall". As far as the specifics of the zoom problem, it's definitely not a chrome issue, as it's a standalone web server running locally, not a url protocol handler. And it's not quite an OS issue, other than that the OS allowed it.
  - staticvar 7y ago
    > Going to the app-store allows for reading opinions (i.e. somewhat independent) compared to just clicking, go-on. It shows some download/usage statistics and the like. That's a great point! Browsers could perhaps start to include metrics like these for website permissions. For example, when the Web Browser prompts for USB access, show metrics like how many people have granted permission to Bluetooth for this website, perhaps even room for comments and ratings. Chrome is afterall trying to be your next app store.
- user9836 7y ago
  What good prompting the user does if the prompt says: "Would you help to make your beloved app even better?" or "Give permission to use Bluetooth?" We as developers know the technology is not safe. We know users can't know what we know. But we still push it to users. We are not protecting users. We are just transferring responsibility to users and we know that's know "gonna end well" but we're doing it anyway because of what? Because we can? Profit? Chromeos? Why?
  - Ajedi32 7y ago
    > What good prompting the user does if the prompt says: "Would you help to make your beloved app even better?" The prompt doesn't say that though. The prompt text is controlled by the user's browser, not the website. Example of a prompt in Chrome: https://developers.google.com/web/updates/images/2015-07-22-interact-with-ble-devices-on-the-web/bluetooth-device-chooser.webm https://developers.google.com/web/updates/images/2015-07-22-...
    - fredrik-j 7y ago
      Thanks for the example video! I note that the example skipped one crucial step, to scan for available devices. Scanning and enumerating available devices, and selecting a device, is a step where potentially sensitive information is exposed. Will scanning for and getting a list of all available devices be something that a websites can do through the api? Or will the api delegate scanning to the browser, much like the file selector api, where the browser is only exposes the final user selection, the selected file, rather than letting the webapp have access to the entire file system? I.e in this case a list of all available bluetooth devices?
      - Ajedi32 7y ago
        No, as you can see in the video the browser lists available devices and the user then selects from that list. The website only ever sees the device the user selects (if any); it can't read the list itself. IIRC there _is_ a separate standard that allows websites to scan for nearby Bluetooth devices but it's via a completely different API with its own separate permissions system.
- josteink 7y ago
  > 1) Prompt the user to download a native app. 2) Prompt the user to follow a link to an app store for their OS. 3) Prompt the user to allow the website access to the Web USB / Web Bluetooth APIs. 99.9999999999999999% of the websites out there doesn’t or shouldn’t need HW-access. 100% of the malicious websites out there will use this the second it lands. That’s one line of code to land seriously serious exploits. Before their only option was your 1, 2, 3 steps above. Clearly this is a quantum leap forward, for malicious sites first and foremost. The rest of the web isn’t going to give a fuck. So why are we investing in this?
  - staticvar 7y ago
    > 99.9999999999999999% of the websites out there doesn’t or shouldn’t need HW-access. 100% of the malicious websites out there will use this the second it lands. That’s one line of code to land seriously serious exploits. The same can be said for native apps. Are you in the "no Bluetooth/no USB ever" camp? That's totally fair if you are.
Ajedi32 7y ago
> Would you download random native programs and give them hardware access? No. But I wouldn't grant a "random" website hardware access either. A reputable native program with a legitimate reason for requesting hardware access though? Sure. Why shouldn't I be able to do the same for a reputable website?
- nexuist 7y ago
  The case for a reputable website is even stronger given that you can literally inspect the source code as it runs. While a native program might require disassembly and de-obfuscation, a website can only deliver JavaScript that can just be copy-pasted into a text editor. The one exception I can think of might be WebAssembly, but to date most native features (like location, filesystem access, even manipulating the DOM) require interop with JS to be used by wasm.
  - toast0 7y ago
    Plenty of websites minify their javascript, which is on the train to obfuscation. Javascript is definitely obfuscatable if desired.
- josteink 7y ago
  > No. But I wouldn't grant a "random" website hardware access either. We’ve trained people unskilled in IT that’s apps are dangerous and websites are safer. They’ve finally gotten it. So let’s make websites unsafe, only one click away (which we know users will click)! What a great idea!
  - Ajedi32 7y ago
    Sounds like your only objection is over how scary-looking the prompt is? Running a downloaded executable is already "one click away", and connecting a website to a Bluetooth device isn't nearly as dangerous as running an executable. The difference in levels of access and size of the exposed attack surface is huge.
    - 7y ago

smacktoward 7y ago

From a security perspective, you want to add features only when they're seriously needed, not just because you can. Even if the new feature seems completely safe, there may be some potential way to compromise it you're not seeing, or some interaction it will have with other features that isn't obvious until the two are shipping together. The smallest attack surface is no attack surface at all.

jancsika 7y ago
Flip side-- just keep adding features until your userbase is large enough to justify a security team that a) assumes the API is a giant dumpster fire and b) redesigns the system so that it continues to work even when lots of things are burning.
clinta 7y ago
From a security perspective you should consider what users are already doing and if introducing a feature can be better security than that. Users are already installing local applications from untrustworthy hardware vendors just to interact with bluetooth devices. I think a web bluetooth standard is an improvement on that.
hinkley 7y ago
Commonly known as The Principle of Least Power.

AlexandrB 7y ago

For one thing, I don't want my browser to have low-level access to USB/Bluetooth to begin with. Browsers are already doing too much (see Chrome's built-in malware scanner), and with complexity come additional security issues. Plus, what are the chance that this won't be used for tracking somehow?

staticvar 7y ago
> Browsers are already doing too much (see Chrome's built-in malware scanner), and with complexity come additional security issues. That does seem like a common feeling people have. Do you feel your OS is also doing too much as well? > what are the chance that this won't be used for tracking somehow? Are you referring to Browser vendors tracking people or Websites? Surely there will be Websites using this for tracking, they use everything they can. The same is true for apps in App Stores, such a shame.

mgazzer 7y ago

Well, we do know that the best intentions around the browsers technology have paved the way to hell. Some of the other issues that crop up are: * Sites "adding" increased security mentions to their customers by profiling their connected bluetooth devices * Is the browser only able to see connected devices and not the master list of devices? * Bluetooth devices come in such a wide array of formats that I wouldn't want to ever offer the browser access to these tech (it's clunky enough through the OS most of the time) Last time I let this site access my devices and now it's watching me * All those other options you listed below in another reply, are all high susceptible to a man in the middle attack, and all the sudden your headphones have been turned into a weapon, all because you clicked a link. * Getting your laptop's battery drained even more because of some nefarious website preventing your devices from sleeping I feel like we need to build a pretty big moat around USB devices and Bluetooth devices, as they're often the easiest points of entry that can lead to further system compromise.

clinta 7y ago
Notice the prompt to select a device: https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web#request_bluetooth_devices https://developers.google.com/web/updates/2015/07/interact-w... I think this mitigates these security concerns and improves security around Bluetooth devices generally. Today if I want to do use the advanced configuration features of for my headphones I need to download a local application and install it. A local app from has way more unwanted permissions and tracking ability than a website. In the future it could be as simple as visiting their website and clicking allow when the site requests bluetooth access.

lern_too_spel 7y ago

It is sour grapes from iOS users who are unable to install a browser that can use this API. As the blog post shows, it is quite useful.

weaksauce 7y ago

mainly because the s in IoT stands for security.

hinkley 7y ago

There’s no security in depth with these devices. Exposing them puts all the security onus into this new layer, which is a tough row to hoe. And we never get these things right at launch.