Web Bluetooth API Privacy
Web Bluetooth - a web API under development, and will be one of the core components of Web of Things, the application layer of Internet of Things. It will enable sensors, beacons and user devices to communicate with each other. But at first: 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.
It's imperative to design this layer with security and privacy in mind. We currently experience some of the cheers related to widely distributed Internet of Things devices used as massive attack tools.
First, let's start on this Google's Web developer page says:
What if I told you websites could communicate with nearby Bluetooth devices in a secure and privacy-preserving way?
I would tell answer: buzz-wording aside, but please be more elaborate. Perhaps accidentally, but security and privacy is only present in the first sentence of that tutorial.
I was asked to have a look at proposed Web Bluetooth API. I am very happy to provide my input. Web Bluetooth specification is long, complex, and should be analyzed thoroughly. The Web Bluetooth specification provides a telling example:
To discover and retrieve data from a standard heart rate monitor, a website would use code like the following (...)
Really? This immediately highlights the main concern. Can we realistically assume that average users will be able to understand the qualitative difference between pairing two local devices, and pairing a local device with a remote web server? No, we can't.
Let's put some of the key points of this note upfront:
-
Web Bluetooth API will deal with personally-identifiable information
-
Web Bluetooth API will be providing detailed information about user's motion, position and movement
This is meant only as a general overview note, not getting into all the details of Web Bluetooth security and privacy. The specification is considerably large, introducing a very powerful feature, and it would require many qualified eyes looking at it. While elements of Web Bluetooth API's threat model are addressed by Google's Jeffrey Yasskin, I believe it is necessary to review the privacy side of the API even more thoroughly, I would be happy to receive more feedback (e.g. via e-mail: lukasz.w3c at gmail.com).
Web Bluetooth
Web Bluetooth API allows web sites to communicate (read, write) with external devices in the user's surrounding.
An example code to connect with all nearby iPhones or devices with their device names starting with 'i' could look as follows:
navigator.bluetooth.requestDevice({
filters: [{
namePrefix: 'i'
}],
optionalServices: ['battery_service']
})
.then(device => {console.log('ok'); Q = device })
.catch(error => { console.log(error); });
This code will result with a prompt where the user will see a list of bluetooth-enabled devices - perhaps smartphones, TVs, toasters, toothbrushes, heart monitors or implants. This of course applies to all devices in the vicinity - whether they belong to the user (privacy analysis is in the next section) or to someone else (I'm writing about offensive capabilities later on).
Web Bluetooth API can also search for specific services (list is here) or names.
I set up a small demonstration of Web Bluetooth API on my site.
So first of all, when a site wants to access Web Bluetooth, a pairing prompt pops out:
The user can then choose whatever device is in range, for example, your neighbour’s Smart TV. Then, some basic information are accessible:
Afterwards, a connection attempt may be made, perhaps resulting with reading and writing capabilities.
The examples are tested on Chrome 54 browsers. If you're having issues, perhaps turn on the experimental Web Bluetooth API feature in Chrome flags.
That said, I had a mixed experience in using Chrome's Web Bluetooth API under my OS. I also did not find the time to play with enough Bluetooth devices.
Chrome requires user's gesture to perform Bluetooth-related operations. I chose mouse movements for this task. Mouse movement causes a web script to connect and disconnect to/from device.
Privacy analysis of Web Bluetooth
Web Bluetooth API is a powerful API. It's important to be aware of the related privacy aspects.
First things first. Access to Web Bluetooth API will be subject to permissions and it will only work in secure contexts. To simplify, this means that aside working only on HTTPS sites. Additionally, it’s not that, like every web site on the internet will be able to interact with user's devices without user consent or awareness.
However, just introducing permissions is not addressing all of the security and privacy issues when an API is sensitive. The use of Web Bluetooth API touches multiple sensitive areas and users, web developers and web owners must be aware of them.
I would argue that the sole introduction of Web Bluetooth API should be clearly advertised to users. How many users are aware that browsers are capable of using Bluetooth? How many users expect this?
One approach could simple. The browser could literary track that the API has been used for the first time, in general (i.e. first time after a browser is installed or updated to a version supporting Web Bluetooth API), and then inform the user about the existence of this feature and explaining its nature. Explaining the nature of Web Bluetooth API is another thing.
Let's ask upfront. Can we realistically assume that users in general will know the distinction between pairing a local smartphone/kettle/beacon with a local laptop, and pairing a smartphone/kettle/beacon/toothbrush with a remote site? I don't think so. Don't take me wrong. But most of the people don't even get the true nature of cloud computing/storage.
This is an invitation to unexpected. surprises.
Information leaks
If a user grants a web site access to Bluetooth devices, and later grants another web site access to Bluetooth devices, user could become subject to cross-site tracking via device identifiers or device names. Let's imagine a user naming his kettle "John Smith's kettle". A web site with permissions to access Bluetooth device will be to learn this name. I emphasize again: pairing user's computer with user's device happens locally. We can say that identifiers or unique names stay close to the user.
However, pairing user's device with a remote web site is something qualitatively different. Now you could blame the users for using similar naming conventions, but if it’s their habit, technology should not expect users to change. Recall how Mirai Internet of Things botnet was formed. Users did not change the default passwords, because, well, they did not. They acquired a product, turned it on, that’s it. Discussing whether it was their fault misses a point, because the design was bad.
Behavioral monitoring
Web sites could potentially query for certain types of services, with requests such as "return all devices capable of doing reporting battery level" (or "heart rate monitorin level", etc.). This means that the data accessible to web sites will often be of very sensitive nature. This data will allow to profile the users, detect their lifestyles, genders, etc. Web site designers, developers and owners must be aware of this. It's not difficult to imagine scenarios where this can result in unexpected surprises.
Motion monitoring, distance tracking
Using Web Bluetooth API, web sites will be able to monitor user's 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. This property can be directly used to detect the user location from a device, to detect user movement. Just use this relationship between the distance and signal's strength. The more devices, the more precise readout is achievable. So, web sites will be able to monitor user movement at home, or beyond. This particular feature is not exactly advertised at the moment.
One approach is to remove rssi or txPower, or both - from the specification and implementations. Currently there are no viable use cases for those parameters existence.
Profiling potential
The last point tells a lot about profiling potential. Patterns of movement analysis is possible. Additionally, web sites might discover the type and models of certain beacons and possibly indirectly reason about the user's financial situation and interests.
Legal aspects of Web Bluetooth API
Now it's get non-standard. Remember the last time when you named your device based on your real names? I also didn't. But many people do. So you can find "John Smith's Kettle" or similar. Those are personally-identifiable information. And due to the fact that pairing of a device is made with a remote web site, this web site will then obtain this personally-identifiable information. In Europe and many other places, it will make the web system a data controller. This data will need to be protected properly. For example, under EU's General Data Protection Regulation, an organization might receive a fine up to 20 million euros. So let's hope that organizations will be aware of this.
Web Bluetooth in Web Application Hacker's Toolset
Another interesting issue is also apparent.
I expect that a framework making it easy to test, tamper or penetration testing of Bluetooth/IoT/WoT devices will become reality, sooner or later. In fact, I would be very open for participation in making such a project (please reach out if you're interested).
One side consequence is also that Web Bluetooth API will decrease the entry barrier for people with malicious intentions, who so happens aren't very technically versed. Soon, everyone with a web browser will be able to potentially become an attacker targeting Internet of Things and Web of Things devices.
Finally, if user's browser is hijacked in some way, they might even become channels for attacks directed by someone else.
A basic example of using the API is also displayed on my site.
Summary
It's necessary to think whether Web Permissions for Web Bluetooth are enough.
Web Bluetooth API will open new possibilities of tracking and profiling users, their behaviour, as well as their movement, location data. It will become one of the most sensitive APIs. It will have to be subjected to significant scrutiny at W3C, once it transitions from its current development phase.
I am expecting it can also open a number of unexpected problems. Sole use of permissions is not enough.
Every system wanting to use the Web Bluetooth API should undergo a rigorous web risk privacy assessment - privacy impact assessment. This especially applies to systems and sites based in EU, or ones dealing with users based in EU, a consequence of the General Data Protection Regulation.