+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 ask about users' Bluetooth devices and harvest information from them through the browser. That's more a pitch to developers, as is clear in this YouTube video from Pete LePage of the Chrome Developers team:
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.”
In other words, the API lets websites ask your browser “what Bluetooth devices can you see,” find out what your fridge, and so on, is capable of, and interact with it.
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 grant a website access to your Bluetooth gadgets before anything happens.
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. 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
We consider it perfectly reasonable to consider the API as another means for sites 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.
Merely scanning for nearby devices is a marketer's dream: instead of merely knowing that a visitor to your site is using Firefox 56 running on Mac OS version 10.11.6, you can also find out what phone/s are in the house (if Bluetooth is turned on), whether they're using Philips or Osram smart lights, their TV and so on; and if they use their own name for device names, that's hoovered up and sent upstream as well.
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 implementation looks 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:
@ChromiumDev Right, so first thing: How do I turn this off, for security purposes?
— Stuart Young (@cefiar) February 2, 2017
@cefiar@ChromiumDev And second thing, as an admin, how do I block this for all my users?
— Dave (@daveidfx) February 4, 2017
@ChromiumDev🤦♂️ wtf moron had the white board when this decision was made?
— HorrificBookCurses (@0x2be3) February 4, 2017
Most other browsers don't make mention of the API yet, but we note Mozilla's attitude to it is “do not use it on production sites facing the web.”
We agree with that stance and hope the Bluetooth Web API goes the way of the snitching W3C Battery API. ®