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?
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?