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?
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?
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?
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.
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.
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.
> 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.
> 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.
> 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.
> 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?
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.
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.
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.
Do they provide such a low level API to usual mortal developers? This isn't going to be nice and comfy in terms of usability if it happens the way you describe.
I would not say it's likely to die because it's obviously false since on iOS it's the only choice but it's true that when you see the release logs of Safari, it's moving very slowly very far behind Chrome or Firefox.
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.
> 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.
So instead of having all of the security features that browsers have you would prefer to run the application in an environment where code has all of the permissions as the user running it. I'm sure malicious actors are onboard with this proposal!
But this means you have to install 10 different extra plugins, 1 for your webconfrerence progrtam , 1 for screenrecording, other one for the other screen sharing that you need for the other project, other binary for some hobby you have that needs that feature.
The solution is to use a browser you trust and ask for browsers to have this modules off by default, maybe have the option to compile without pdf, webcam support, I am sure there will be people that would compile this browsers with the things they do not like out.
In Linux you could probably sandbox your borwser so it will not even see your real webcam or other hardware. So I prefer installing a full featured open source browser then 10 closed binary executables.
The growing complexity of browsers make security harder. But at the same time - mainstream platforms are also getting more limited in the name of security. It's almost impossible for a power user to fix something themselves. They have to install an app, or root their device. The alternative is not really downloading a random binary, you can no longer do that. The only alternative to get shit done is to go buy a Linux compatible PC and learn some programming. 20 years ago the security was terrible, but you could fix things yourself without being a developer. No matter how much systems are limited, security issues persist. If you are worried that your browser is insecure, switch to a more secure browser that doesn't have those features, or disable the features in the browser you already use.
As a developer I could write detailed instructions on my website how to install Linux, what OS and packages to use, instructions for git clone etc. Or I could just have a button that the user can click on.
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.
Can you be more clear? For example I want to make something like video calls and screen-sharing do I do it in Python(or C proprietary) for all platforms then ask my users to install an extension that let's me connect with my application?
I understand where you are coming from and I would also like Firefox not to force on me the PDF reader and other options, if they could have this extra features as plugins that you could as a power users uninstall and use your preferred thing would be nice.
Can you also make more clear why you don't trust someone making a webpage that calls an hardware related API but you trust them if instead of the page is a binary or a python script.
Firefox or Chrome would have control over that hardware related code not the third party software, the software would ask if you have a microphone or not and a popup would/should appear so you can confirm, an evil developer can't go around this.
I know. I’m concerned the application will get changed in between uses. If it’s complex enough that I couldn’t use just screen or a short script I write myself then that means I’m depending on the behavior of a webpage to remain consistent for some process.
I don’t care about security I care about the application written by the device manufacturer (who I trust from a security standpoint) not changing (which it will, because some business/marketing/“UX” guy always comes along and breaks things and I won’t have a way to get the old version of the application that I needed to drive the hardware)
I mean the idea that webpages will want hardware access is concerning and I’m sure a lot of them will ask for it for some reason and that is a security problem but it’s not at all what I’ve been talking about. Maybe try rereading my other replies?
Sorry if I did not understand your example, are you afraid of companies offering a webpage for configuring your printer/drone/device instead of a stand alone application, Then if the site goes down you can't configure your thing?
If this is the case then you are asking to not allow features for the good developers because bad/lazy developers exists.
I have a Canon printer that works fine on Linux but I do not have the GUI executable like on Windows, so one day it did not work anymore, I had no idea what to do so i installed the driver on a Windows VM , let the VM to access the printer and I got a diagnostic (I forgot to open a tray thing). So for this case if the printer devs could make this diagnostic tool as a webpage or Electron app would have helped me a lot (I was lucky I already had a Windows VM)
Rubbish. There are plenty of really cool use cases for this. For example combined with the physical web you can literally walk up to something, get a notification on your phone that it exists (yes there are spam concerns), tap the notification, and control it directly through your web browser. The device doesn't need internet connectivity and you didn't need to install an app.
That's great for one-off things that you only interact with once.
I wonder if it can improve the setup flow for devices like wireless speakers where there's a whole guided process for powering it on, pairing it, connecting to its wifi network, changing settings, etc.
>Make a real native app all the other decent people if you need this.
Who is going to pay for this? How many ideas will die because nobody can afford to pay for 3+ native developers across Windows/Mac/Linux? How many teams will decide to axe Linux support because it's not worth it?
Why develop natively when you can just hire one JS developer to write once, deploy anywhere?
Native apps failed to democratize the market. We are stuck with platform-specific applications that will remain intertwined with their vendor of choice presumably forever.
Well, I'd suppose if this becomes a web standard, it will come with an eventually stable API. And I wholeheartedly vote for "write a (lovely) webpage that still functions in a decade" over "write an app that might be (breaking) with the next generation of mobile phones (API changes, new OS,...)". Especially if I build any of that myself, and instead have some closed, physical thing I bought which depends on an external controller.
(parent can replace the "" with whatever he likes, but since I find swearing doesn't quite fit HN, I've put some more appropriate terms next to them)
> Make a real native app all the other decent people if you need this.
Eh, I'd much rather just visit a website where I have actual control (ublock, noscript, developer console) than download and install yet another native app black box.
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.
Every time someone posts Web Bluetooth someone brings up security, which is fair, but I don't think it's productive to immediately dismiss it. The Chrome developers behind the spec have thought a lot about the security implications. It's not impossible to make Web Bluetooth more secure than tricking a user into installing a malicious program, which isn't exactly a complex trick right now.
This article from 2016 goes into some of the security of Web Bluetooth:
On the server that was heartbleed under the WebMEM spec. There needs to be a tight feedback loop between the feature people and the security people. Without it, the FP will over-run the SP. The default to ship, ship in public attitude means that all of these "features" get public exposure before the security people have looked at it deeply. Much of the worlds technical architecture needs to get inverted.
While Web Bluetooth seems like a good idea to us making BLE devices, the truth of the matter is that only google adopted it, and only such a small subset that you have to design your device around Web Bluetooth.
I recently had to make a iOS app that embedded a webview that catches web bluetooth calls and implemented them natively, to work around the fact that Web Bluetooth doesn't work on Safari. I think that would be a maintenance nightmare going forward.
This is huge imo. It is exactly a web interface that can use bluetooth. One of the major problems with the BLE protocol is that there is really no standard client for a user to interact with devices. To access on the computer you'd need to download a program, on mobile you would need an app... just to have a meaningful user interface to a BLE device.
Its like if you needed to download a new web browser for every website you visit, absolutely ridiculous.
Actually the web is an OS: it has api for gui, for persistent data, for networking, for all kind of periphericals (gpu, gps, bluetooth) ... The problem you're raising (which i agree with) is that we already have an OS and we'd like to use that one.
Looking at the current chrome documentation it does not appear that web BLE offers the ability to enumerate. The browser pops up a dialog allowing the user to grant access to a specific device.
I think this is actually superior to the security offered by mobile apps on android, which can enumerate bluetooth devices as soon as they have bluetooth permission.
> To access on the computer you'd need to download a program, on mobile you would need an app
Are you suggesting that I don't need to download anything to view a website ? I beg to differ.
If you check the article, namely the photo of the phone you can see there's a browser opened from localhost, so something must have been downloaded on the phone.
You only need to download one browser with the proper support to support a million BLE devices.
As opposed to downloading 1 app per vendor/product, each of which has its own attack surface and special way of doing things that may or may not support your specific hardware implementation.
Seems like a web interface that can use bluetooth.
That's precisely what it is. Accessing bluetooth devices from a progressive web app affords a lot of interesting new functionality for web app developers.
Was this previously impossible or something ?
Web bluetooth has been around since Chrome 42 behind a flag, but it's only recently appeared in other browsers so maybe now is the time to start taking an interest.
look even at the examples: you get endianness and protocol parsing/composition, coupled with "string" based enumerations + promises - no special error handling, etc. It feels such a mess to program with.
I definitely do for something I want to write myself, that behaves like an app, but has zero entry barrier. I am adding PWA best practices to everything I do now "just in case", still not quite sure if it's going anywhere, maybe it is only me. I wanted a "packing reminder" on my phone so I made https://paulypopex.gitlab.io/holiday-reminder/# and it works for me.
The "Embed this on your home screen" aspect is what I was interested in, I guess.
Personally I'm not really interested in routinely circumventing my mobile platform's app store, nor do I really want more clutter. Plus it seems like a lot of the sites that have the capability are just trying to push their brand in the same sort of way they did by having their own apps a few years ago - newspapers and other information sources which are just fine in the browser.
That you can do manually with any web page (that isn't badly designed) as it is essentially just an icon that opens the page when selected. The only real difference IIRC is that it looks like a separate app (in your task list etc.) instead of being a browser tab and having less browser chrome.
Another common use for the features that come under the PWA banner are local storage and running options, which reduce transfers to/from the server(a) and allow offline working. There are a few apps I use that work this way and you don't notice that they are anything other than a simple web app until you find yourself properly disconnected for a time and they still work.
In the first instance, I don't have site bookmarks on my home screen, my browser can store those just fine.
The second instance sounds like something that should be an actual app, installed from a trusted source, if it has access to storage and other device features. Particularly if it can run in the background, issue notifications etc etc.
But many people do. I have a couple of shortcuts to common pages on my phone's home screen (well, a folder there on) just as I have shortcuts to certain files that I regularly interact with on the device instead of going to the app and manually opening them from there.
> sounds like something that should be an actual app, installed from a trusted source
Why, when it isn't doing anything the web app can do anyway. LocalStorage isn't a PWA-only feature, nor is notifications, and both have a least some gates to access (LocalStorage should limit the amount stored, prompting the user as a soft quota is reached as well as having a hard quota, and sandbox sites from each other, notifications asking for permission before they are enabled). I assume other features like bluetooth access are similarly gated, so there is no less protection than found in app store apps.
Why make me install an app on my phone as well as using the site on desktop/laptop, and make the developers write both, when the website based application can perform both roles?
There are sensitive permissions that I wouldn't want to grant a PWA (access to my contacts for instance, access to other apps files) of course, not being able to be globally disabled if found to be malicious as is possible with an app-store based install makes that more dangerous. But with careful control PWAs can be very useful without being any more problematical than any other web app.
If anything a web page is more secure than a native app: they can't even request wider access to the local filesystem (there is the FileSystem API in Chrome, but IIRC that has little traction elsewhere and can only operate on files specifically selected by the user rather than being able to randomly trawl around your everything). Definitely more secure than an app on the desktop, which most of the time runs as you and can do anything to your files that any other app running as you can do.
Bluetooth: I've not looked into it in detail (a quick search finds https://medium.com/@jyasskin/the-web-bluetooth-security-mode... amongst other relevant looking articles, but I don't have time to go through them right now) though I find it hard to imagine this similarly would be any less secure than a native mobile app having access to Bluetooth as the web page is going to have to ask for permission to use the API then you need to pair it with the target device.
Native mobile apps have their permissions and access managed by the system, and are at least minimally inspected and approved on the system app store.
I'm really not sure I want my browser managing a second tier of these permissions, especially as it runs arbitrary code downloaded from the net. Maybe it's an artificial distinction, but I'd rather keep "code I stumble upon without even realising by browsing the web" very separate to "Things I give device access to".
We are within a stone's throw away from America Online or Prodigy, but almost entirely self imposed. It is very interesting how monocultures and winner take all systemics play out.
Sure, but why the big difference between Wifi and Bluetooth? You can reach your Wifi devices from your browser. People do not argue that they want a separate application to do so. They use the same application to reach the internet versus the devices on their LAN.
Indeed, pretty much the 'web'/html has been forced to support any possible connectivity and technology. I wonder if there would be a day where full blown out device enumeration would be provided.
