Chrome 56 adds Web Bluetooth API | Hacker News Reader

Chrome 56 adds Web Bluetooth API

theregister.co.uk

61 pointshuntermeyer27 comments

This article is poorly researched. The Web Bluetooth API does not allow a webpage to request a list of all Bluetooth devices that your browser can see.

The API allows a webpage to ask for access to a device in response to a user action only. At this point the user has to give the page permission to access Bluetooth devices. The browser then prompts the user to choose a device from a list of available devices, and the webpage is granted access to whichever device the user picks. That's all. There's no "list every Bluetooth device in the area" API (at least not yet), unless I'm missing something.

More reading: https://medium.com/@jyasskin/the-web-bluetooth-security-mode...

And also: https://medium.com/@urish/is-now-a-good-time-to-start-using-...

And also also: https://developers.google.com/web/updates/2015/07/interact-w...

It's a shame many people would make their opinions about Bluetooth API on such poor journalism as The Register offers. Zero credibility!

Given it's the intersection of two such perennially dismal technologies, I'd say pessimism is justified.

Got it - hear you loud and clear. The article wasn't worded correctly. We've corrected the explanation and linked to the APIs directly (which we should have done from the start).

Yeah, we're a tabloid and, yes, we're rude. But at The Reg, we do take accuracy extremely seriously. We want to be right. If you spot anything wrong, corrections@theregister.co.uk goes straight to our editors: it's a great way to get things fixed fast. Thanks.

Thank you for fixing the error :)

...that the user has to opt into by selecting a device in the popup, and not hitting cancel.

You'd prefer that any website had full access to the Bluetooth stack and could see all your nearby devices?!

I think parent comment replied when the title on HN matched the article title (which called it "Bluetooth snitch API")

Oh! Thanks!

sure, like plugins

oh wait, where did my plugins configuration go? why cant I disable plugins I dont want?

This is annoying security-wise. Looks like a single click/touch/keydown event will allow javascript to start scanning for devices. Remember what happened the last time Chrome added support for odd hardware APIs? https://googleprojectzero.blogspot.no/2016/02/racing-midi-me...

JavaScript doesn't scan. It opens a native modal for selecting a device. JS can provide filters, which are simply strings, they don't get any information about devices.

But the native modal obviously runs a whole lot of native code including calling into the bluetooth stack and starting the radio etc. Even just exposing a way to "start scan" could be enough to shake out 0days in the native OS bluetooth stack. I'd much rather have a way to disable chrome.app from even as much as loading the corebluetooth dylib.

Also, is scanning for devices a 100% passive receive-only operation, or would it be possible to design a custom beacon device that identifies hosts that try to scan the beacon?

Chrome 87 will add the ability to control your hearth implant from the web. Because it then can order new batteries when you are browsing on amazon, and lets be honest what could possibly go wrong?

Now don't worry, it will be opt out. Your browser will loose the ability to download files altogether if you disable this but such is the price of being a tinfoil-hatter.

Can you abuse this API? Maybe! It needs to be researched before making bombastic claims. From what I can tell the API is opt-in only and there is no way to enumerate all devices.

EDIT: One way to abuse the API (keep in mind that this is a documented risk in the spec) is in case of XSS accessing devices which are already granted permissions for. For example, if your health app has access to your heart rate monitor, an XSS vector will potentially have the power to pull this information straight from the device or abuse it in some other way if the device suffers from input validation problems. The former is not such a big deal because in case of XSS it is assumed that access to private information is granted. The later is slightly more interesting but you need scale to pull an interesting exploitation. It can be done but it is limited at present IMHO.

Related discussions:

https://news.ycombinator.com/item?id=13153104 (34 comments)

https://news.ycombinator.com/item?id=13136111 (149 comments)

This was actually possible before using origin trials. I've used it and it works quite well. The security implications are more or less non-existent (despite what everyone claims).

The only problem is BLE on Android is still a hilariously buggy mess. Maybe they can rewrite the stack again...

Why do we keep trying to make web sites into a UI toolkit?!

:( my face about the current state of computing and the whole 'app' re(de?)volution.

[!] You have a perfectly good computer running in front of you, with powerful hardware, geometry translation and audio rendering devices ready to be bent to your will.

[!] You have excellent (paid and free) tools and the Internet provides documentation on everything....

[?] Why shove more and more functionality into the browser, which can't even be considered a single proper 'platform' or 'target', since you have to account for several cross-browser/os combinations... In the end, we need frameworks which must patch and shoehorn lots of stuff in our actual code just to deal with cross-browser/os .

[..] In the end, we achieve better and better performance per cycle on one side and waste it more and more on the other. Of course, power efficiency and other important metrics on our increasingly mobile world go out of the window as well.

[.] We could be improving our tooling and languages to enable programmers to achieve good cross-compilation performance everywhere, and making most interfaces properly standard (opengl, communication stack) would make all this accessible and easy.

I leave you with two questions:

positive mindset: is this about lowering the entry bar to 'app' development?

negative (realist?) mindset: is this about vendor lock-in, hardware sales and consumerism?

The browser is just easier. Accessing an app is as simple as entering a URL. The browser is more secure.

because 20 year old 'developers' grew up with 3GHz laptop CPUs. Fast computers make stupid ideas, like python or ruby, sound ok for production.

Obviously this can be used in a malicious manner, but is that not a problem of ui and not "let's not have the browser talk to Bluetooth devices at"?

Allowing every site access to quietly scan for devices would be pretty horrible, but that's not the case from my understanding.

tl;dr: click-bait title. The ability to access Bluetooth peripherals is opt-in and requires an explicit user interaction.

Why is it click-bait? It just says that support for the Bluetooth API was added. Why would anyone extract from that that there were no safeguards in place against abuse?!

Will admit my first thought was web fingerprinting opportunity…

The article title:

  Chrome 56 quietly added Bluetooth snitch API
  Trust us, says Google, we understand privacy

I agree the fact that an explicit user interaction is required doesn't necessarily constitute a safeguard. How many times has my Android phone updated an app, which inexplicably now requires additional permissions. Formerly it only needed access to my media. Now it needs access to my phone logs, GPS, address book, etc. etc. Confirm? [Yes] [Cancel]. Like most users, I update the app every time. So when this Bluetooth system says "This web app needs access to your Bluetooth Home Thermostat system. [Accept] [Stop using App] people will more than likely press accept, and away we go.

Reply on news.ycombinator.com