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