[Infowarrior] - Chrome 56 quietly added Bluetooth snitch API

[Richard Forno]

Chrome 56 quietly added Bluetooth snitch API

Trust us, says Google, we understand privacy

5 Feb 2017 at 21:41, Richard Chirgwin

https://www.theregister.co.uk/2017/02/05/chrome_56_quietly_added_bluetooth_snitch_api/

+Comment When Google popped out Chrome 56 at the end of January it was keen to remind us it's making the web safer by flagging non-HTTPS sites.

But Google made little effort to publicise another feature that's decidedly less friendly to privacy, because it lets websites connect to Bluetooth devices and harvest information from them through the browser. Here's Pete LePage of the Chrome Developers team describing the feature:

LePage, in the video, says: “Until now, the ability to communicate with Bluetooth devices has been possible only for native apps. With Chrome 56, your Web app can communicate with nearby Bluetooth devices in a private and secure manner, using the Web Bluetooth API.

“The Web Bluetooth API uses the GATT [Generic Attribute Profile – ed.] protocol, which enables your app to connect to devices such as light bulbs, toys, heart-rate monitors, LED displays and more, with just a few lines of JavaScript.”

Let's start with LePage's security-and-privacy claims: what Google means is that the server-to-browser connection is over TLS, and users have to allow connection with a touch or a mouse click. To reiterate: as a user, you have to explicitly grant the remote web app access to your Bluetooth gadgets before anything happens. Then you select a device to pair with the webpage, and away you go. The webpage can filter for devices, so for example, a health site can ask to be paired with gadgets that have a heart rate sensor. The site can't see any devices until it is paired.

The programming interface for this is described here and here.

As pointed out to The Register last year by privacy researcher Lukasz Olejnik, the API makes it possible for site owners like Google to gather a huge amount of privacy-intrusive information from your nearby electronics. The Bluetooth Web API community would have trouble denying this, since its first example code is for retrieving data from a heart rate monitor.

Reg comment

It's perfectly reasonable to consider this API as another means for webpages to gather and aggregate information about users; and if challenged the industry will use familiar weasel-words about how users can experience wonderful new services users will get if they just hand over a little more private data.

It basically invites the user to gradually cough up the contents of their homes and offices – from the keyboards and mice to the smart bulbs and wearables. There's nothing in the Bluetooth Web API to stipulate how all that data is stored by the site owner, so we also suppose Troy Hunt will soon need to add new fields to haveibeenpwned.com.

In 2016, the Internet of s**t Things taught us that most firmware implementations look like 4:30pm-Friday-afternoon work by the last developer not to go to the pub. A vendor's canned SDK is lifted wholesale, complete with example code and default credentials and shipped. There's no reason to think this won't happen in Bluetooth Web API development.

The reaction on Twitter was even harsher than ours: ...

https://www.theregister.co.uk/2017/02/05/chrome_56_quietly_added_bluetooth_snitch_api/