Web devs want to make the Internet of S**t worse. Much worse
The W3C wants to hook your bluetooth s**t to websites, because shiny
Vendors including Google have spent a few years crafting an API they hope to push into browsers that will make this month's Internet of Things conflagrations pale by comparison.
There's not been much noise about the Web Bluetooth API, and thankfully it's not yet accepted as a standard.
Olejnik isn't against the idea, but he sounds the kinds of warnings that El Reg reckons should send the Web Bluetooth API community back to square one.
First, the API itself. You can read Google's 2015 developer intro here, or take the summary from Olejnik:
“It will enable a web browser to contact the user's connected devices such as smartphones, kettles, toasters, TVs, thermostats, heart rate monitors, and so on. Imagine a world where every web site can connect to devices near you – or on you.”
Surely, given the dire state of IoT security, that paragraph alone should be sufficient, but Olejnik is thorough, so there's much, much more.
His first issue is the simple question of permission: the boffins driving the API believe users will know the difference between pairing two devices and pairing a device with a Web site; Olenjik isn't so sanguine.
He adds that the API will be dealing with personally-identifiable information, including users' locations and movements. So there's plenty of reason to expect the API to be very strict when it comes to security.
- Information leaks: it's obvious, really, that people tend to default to using their own names with Bluetooth devices (“Richard Chirgwin's Galaxy S5”, for example) – and those names will get sent up to the Web server.
- The spec allows Websites to send queries about device status, meaning again “the data accessible to web sites will often be of a very sensitive nature”.
- Uberveillance: As Olejnik points out, “Using Web Bluetooth API, web sites will be able to monitor users' movements and location changes in real-time. This will be possible thanks to the rssi property reflecting the power at which the advertisement was received, measured in dBm. In simple words, it reports the signal strength”.
Such is the extent of the API's collection capabilities, Olejnik suggests the Web site owner could be subject to laws like Europe's General Data Protection Regulation.
And then there's hacking: the API “will decrease the entry barrier” for attackers, he writes, and if an attacker hijacks a user's browser, “might even become channels for attacks directed by someone else.”
+Comment: As we noted at the top, we agree with Olejnik.
The Register has for years been documenting the crushing awfulness of the software that the Internet of Things depends on.
At the moment, the only useful protection most devices have against attack is to keep them away from the Internet.
Back in June, CrowdStrike's Michael Sentonas reminded The Register that a lot of IoT devices have neither the CPU nor the memory to run decent – or often, any – security.
And as the Dyn attack reminded us, there's a lot of dodgy kit in the world that ships with hard-coded unchangeable “admin:admin” credentials exposed to the outside world.
Bluetooth devices aren't designed with Internet-borne threats in mind.
We'd also point out that there's already an excess of bone-headed design decisions in the Internet of Things – a thermostat that refuses to let a user change the temperature if there's a DNS outage, for example.
It's almost inevitable that the same bone-heads will craft Web Bluetooth API connections, to make sure that people can only use their IoT rubbish if it can see its Web server.
And the use-case that Google loves so much, the heart-rate monitor reporting tied to a Website?
It sounds like a good idea: tell your doctor if your heart stops beating.
But as Olejnik illustrates, it would be trivial for an attacker to trigger a false alarm over the same connection.
Instead of making the Internet of S**t worse, the geniuses pushing ideas like this could spend their time fixing the mess they've already helped to create. ®
*Updated: Originally the author associated Olejnik with INRIA, but at his request, we have corrected his affiliation. He's worth watching in terms of the interactions between standards and privacy. ®