Using Web Bluetooth to Communicate with Bluetooth Devices
balena.io
balena.io
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?
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.
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-c...).
- 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-intel... [1]: https://itsfoss.com/fact-intel-minix-case/
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.
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.
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?
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-...
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?
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.
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?
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.
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?
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’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!
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.
WebDRM: subvert control of the machine from the user.
WebUSB: allow browser-based attacks on physically connected hardware.
WebBLE: allow browser-based attacks on wirelessly connected gadgets too!
What’s next? WebDMA? WebFdisk?
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.
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.
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.
And we never get these things right at launch.
* 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.
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.
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.
That's great for one-off things that you only interact with once.
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.
PWA or bust.
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.
(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)
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.
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.
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.
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!
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.
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.
It’s not a security thing, I don’t trust the business people to avoid changing things in a breaking way.
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?
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)
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.
Clearly nobody cares about the security of the user anymore anyway.
This article from 2016 goes into some of the security of Web Bluetooth:
https://medium.com/@jyasskin/the-web-bluetooth-security-mode...
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 just broke my mind. Could you explain how/why this infinity mirror contraption was built?
The app is mostly just a (safari) webview, but with hooks to satisfy the web bluetooth api, by using native code.
I want to understand the industry support behind this protocol/standard and the what they hope to gain from it.
Was this previously impossible or something ?
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.
Does anyone actually use progressive web apps?
Yes, is the correct but perhaps overly terse answer.
A more useful answer depends on exactly what you mean by PWA, as there are several common interpretations of the term.
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.
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.
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".
On my laptop, yes I use some of the others. Mostly gmail and github, of those.
Its like if you needed to download a new web browser for every website you visit, absolutely ridiculous.
You say it like it's a bad thing.
>Its like if you needed to download a new web browser for every website you visit, absolutely ridiculous.
I really do hope websites do not try and enumerate Bluetooth on their right own. I know I'd never enable access to Bluetooth to a browser.
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.
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.
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.
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.
Yeah there is, it’s called screen.