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 :).
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.
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.
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.
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.
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.
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?
> 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.
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.
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?
> 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?
We are actively using Web Bluetooth within our hardware debugging ecosystem (https://www.aidlab.com/developer/debug) for our wearable. It plays great role, as:
* It's multiplatform.
* You can rapidly upload the changes (it's web)
* Bluetooth 4.0+ is faster than semihosting (and Bluetooth 5 even more).
* You don't have to use wires.
but what worries me is that there is a visible slowdown in the development of Web Bluetooth (at least when we compare it to the rapid growth in 2015-2017). Is it going to be a dead technology soon? Because it is way behind being a mature tech.
Webkit is missing a _lot_ of useful features. Safari not implementing something doesn't have to mean its dead. It just means iOS users will be forced to download a separate app to interact with Bluetooth devices via the web.
Oh, this is neat :). I was recently thinking about how to configure something on an ESP8266 from my phone - with the ESP potentially being out of range of the WiFi; so HTTP or attaching the ESP to my MQTT server will not be a reliable option.
I was afraid I had to write an Android App to connect to the device via Bluetooth, which sucks because I am neither an app nor a java dev. With the web BT functionality I can now put a simple interface somewhere on the web, open it on my device and control the ESP (I am not a web dev either, but simple JS toy stuff is easy enough).
Of course this might require swapping the ESP8266 for an ESP32 if BLE is strictly necessary (the former doesn't support BLE, afaict).
I have a few ESP8266 projects and WiFiManager [0] makes this a breeze.
Configure a default AP/hotspot, Android and iOS will connect and follow their respective flows for captive-portals. This allows you to grab config from the user and save it. It's a very configurable framework.
Ah, you're right, thanks - I had that mixed up anyway because until now I wasn't interested in using BT in my hobby projects at all. So that's a nice excuse to order an ESP32 or two or three.
You could use the 'chromecast' flow. Where it creates a WiFi network the user has to connect to with another device. And then serving a webpage with configuration.
HTTPS is good but it's not good enough for web api context because it only protects client-server communications.
Prompting the user is good but it's not good enough for web api context because users can't be fully informed by a one line prompt.
I was asked to help my mother in law with her PC. When I looked at the screen it was half covered by W10 notifications from web sites. I asked her, how do you use this. And she sad, I don't know how that happened and I don't know how to stop it. Of course she gave permission but she could not understand how bad web sites would abuse notifications so she couldn't make a fully informed decision . It was sad. I turned all off.
Now, developers will say that it's impossible to fully inform a user but when that's the case should we really push that anyway to the user?
Hmm, at least it's easy for someone else (you) to help her fix it?
This is a bit of a tangent, but as tech support workers soon learn, it's unrealistic to expect everyone in a large pool of users to be independent of tech support. We have a myth of competent independence that works for some but it's not reality.
This goes double when your business includes retirees. As people age, many businesses have to figure out how to handle cognitive decline and death of their customers gracefully. (I'm thinking financial institutions in particular.)
Browsers try to make the open web safe for everyone, but it seems to be based on the median user and many users are well below average.
I have recently tried communicating via BLE on an ESP32 using the Web Bluetooth API on a hackathon. The experience was mediocre at best. Enabling an experimental flag on the desktop version of Chrome 77 was reqired, we had to use some hacks to overcome the 20 byte limit for writing into a characteristic. Additionaly after 10 hours of constantly connecting and disconnecting the device, it refused to work with any device except with one laptop. I don't know if it was caused by the web api or the ESP32 but it was quite an unpleasant superise.
I had a similar experience with ESP32 + Web Bluetooth. Ran into very weird issues, code that previously worked and then stopped working, even after restarting the device. Eventually figured out that the issue was on my laptop side (somewhere between the hardware, Ubuntu and Chrome), and it worked perfectly from my Chromebook and Android phone. For a long time I never even considered that the issue could be on the laptop, since I expected it to be the ESP32 that's buggy.
What I did find is that it can give a very good UX when it's working: connect directly from the browser to the ESP32, without requiring any WiFi setup or other hack to find and pair the device.
Maybe I'm an Apple fan boy, but the list of features WebKit mark as "Not considering" [0] are indeed features I can see become awful security / usability problems. Like WebUSB, that just can't end well...
If an app really needs the feature it will have to distribute a native binary (like you have/had with some web video/screenshare) so do you prefer to have some applications that each one has to offer a Windows and Mac binary (no Linux or mobile) ?
IMO this API should be off by default. Then you would get a native popup when an application is trying to access them for an user to approve it, like this was something Falsh did many years back when you attempted to access the webcam or microphone. Speaking of Flash there were pages that had to use an invisible Flash player(or Java apple) to work around missing features of browsers. So personally I would like if it would be possible to have a browser based, cross platform wideo chat, screen sharing or other cool application as long is using free standards(I mean real ones not Chrome/Google wants it so is a standard now ) . Sorry for the long response.
> If an app really needs the feature it will have to distribute a native binary (like you have/had with some web video/screenshare) so do you prefer to have some applications that each one has to offer a Windows and Mac binary (no Linux or mobile) ?
Yes. 100%. And I say that as a Linux-user.
If someone needs access to low level system and platform specific stuff, I would like to have that confined and isolated in an app 100% separate from my browser, which is already having a hard time staying secure.
That will also make such apps harder to make, so people will not make the decision to require such APIs lightly, or “just” to profile a user.
This is the same position I have on WebDRM, and the way WebDRM has gone only solidifies my stance.
IMO interfacing with hardware is a decent reason to write a small TCL/python app.
Hardware manufacturers suck SO badly at the web and software in general, the idea of having to use their website to configure something makes me feel nauseous.
Another nice blog post/mini-project from Balena.
Even though there are other similar solutions, the ease of use and instructions posted, make it very easy to create your own project :-)
I'm excited about BLE for the browser. I'm not sure what multiplatform (mobile & desktop) alternatives there are except for Qt, and even Qt has bugs and open issues you have to work around.
For instance, only Qt 5.13+ has support for discovering and connecting BLE devices on Windows without pairing first -- if you are stuck on an LTS version (5.12), BLE is awkward in use.
Readit News
The smallest attack surface is no attack surface at all.
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.
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.
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.
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.
And we never get these things right at launch.
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.
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?
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?
Dead Comment
* It's multiplatform.
* You can rapidly upload the changes (it's web)
* Bluetooth 4.0+ is faster than semihosting (and Bluetooth 5 even more).
* You don't have to use wires.
but what worries me is that there is a visible slowdown in the development of Web Bluetooth (at least when we compare it to the rapid growth in 2015-2017). Is it going to be a dead technology soon? Because it is way behind being a mature tech.
I was afraid I had to write an Android App to connect to the device via Bluetooth, which sucks because I am neither an app nor a java dev. With the web BT functionality I can now put a simple interface somewhere on the web, open it on my device and control the ESP (I am not a web dev either, but simple JS toy stuff is easy enough).
Of course this might require swapping the ESP8266 for an ESP32 if BLE is strictly necessary (the former doesn't support BLE, afaict).
Configure a default AP/hotspot, Android and iOS will connect and follow their respective flows for captive-portals. This allows you to grab config from the user and save it. It's a very configurable framework.
0. https://github.com/tzapu/WiFiManager
Prompting the user is good but it's not good enough for web api context because users can't be fully informed by a one line prompt.
I was asked to help my mother in law with her PC. When I looked at the screen it was half covered by W10 notifications from web sites. I asked her, how do you use this. And she sad, I don't know how that happened and I don't know how to stop it. Of course she gave permission but she could not understand how bad web sites would abuse notifications so she couldn't make a fully informed decision . It was sad. I turned all off.
Now, developers will say that it's impossible to fully inform a user but when that's the case should we really push that anyway to the user?
This is a bit of a tangent, but as tech support workers soon learn, it's unrealistic to expect everyone in a large pool of users to be independent of tech support. We have a myth of competent independence that works for some but it's not reality.
This goes double when your business includes retirees. As people age, many businesses have to figure out how to handle cognitive decline and death of their customers gracefully. (I'm thinking financial institutions in particular.)
Browsers try to make the open web safe for everyone, but it seems to be based on the median user and many users are well below average.
What I did find is that it can give a very good UX when it's working: connect directly from the browser to the ESP32, without requiring any WiFi setup or other hack to find and pair the device.
[0]: https://webkit.org/status/#?status=not%20considering
IMO this API should be off by default. Then you would get a native popup when an application is trying to access them for an user to approve it, like this was something Falsh did many years back when you attempted to access the webcam or microphone. Speaking of Flash there were pages that had to use an invisible Flash player(or Java apple) to work around missing features of browsers. So personally I would like if it would be possible to have a browser based, cross platform wideo chat, screen sharing or other cool application as long is using free standards(I mean real ones not Chrome/Google wants it so is a standard now ) . Sorry for the long response.
Yes. 100%. And I say that as a Linux-user.
If someone needs access to low level system and platform specific stuff, I would like to have that confined and isolated in an app 100% separate from my browser, which is already having a hard time staying secure.
That will also make such apps harder to make, so people will not make the decision to require such APIs lightly, or “just” to profile a user.
This is the same position I have on WebDRM, and the way WebDRM has gone only solidifies my stance.
Hardware manufacturers suck SO badly at the web and software in general, the idea of having to use their website to configure something makes me feel nauseous.
Make a real native app all the other decent people if you need this. Let the user assess the risk that way, and see how the market votes.
For instance, only Qt 5.13+ has support for discovering and connecting BLE devices on Windows without pairing first -- if you are stuck on an LTS version (5.12), BLE is awkward in use.