1. Introduction
We intend to define an API that uses Bluetooth to discover and communicate with devices. This document collects use cases for such an API.
2. Use-Cases and Requirements
2.1. Use-Cases
These are potential use cases for Bluetooth in general, but they may not all be supported in the initial versions of the Web Bluetooth API.
2.1.1. Designer of a new device writes a web page to control that device
A group making a product like Fitbit, a heart rate monitor, or a singing lightbulb can write a web site that users can navigate to and control their device.
Other devices include:
2.1.2. Third party writes a web page to control a device
Not only original manufacturers should be able to interact with devices. It should be possible to write a single page that can pull your heart rate data from lots of different heart rate monitors.
2.1.3. Bluetooth LE scale begins advertising after the user has opened its web page.
A user opens their BTLE scale’s website before they step onto their scale. They may also be in range of several unrelated Bluetooth devices when they first open the website. Stepping onto the scale turns on the Bluetooth transmitter, at which point the website begins pulling data from the scale.
2.1.4. Device advertised URL opened by user.
As described in Physical Web, devices may advertise a URL for the convenience of users who wish to interact. Launching an advertised URL loads a website with the device already paired and available for communication.
E.G. a user approaches a parking meter and wishes to make a payment. They look at their mobile’s user interface for nearby device discovery provided by the operating system, browser, or app. Upon selecting the parking meter the web browser is launched with the URL provided by the parking meter. The website is then able to communicate with the parking meter without requiring further pairing user interface.
2.1.5. NFC Handover.
Likely unsupported initially because of the immaturity of [nfc].
A website may already have established a Near Field Communication (NFC) channel with a device via [nfc] and then initiate a Bluetooth connection. As security for communication with the device has already been established in the NFC channel the transition to Bluetooth communication may proceed without interrupting the user for pairing with the device.
E.G. a set of two users wish to play a game together. They both load a given website which prompts to pair using NFC by tapping devices together. Upon tapping the devices handover the connection from NFC to Bluetooth, enabling playing while sitting in the same room.
2.1.6. Beacons
Likely unsupported initially because of the privacy risks of granting access to a class of devices.
Bluetooth beacons can allow a web page to get precise indoor location or to detect distance to interesting physical objects. iBeacon and PayPal Beacons are particularly famous examples.
2.1.7. Audio control
The process of playing audio to a Bluetooth speaker or
recording from a Bluetooth microphone should be handled by a combination of the navigator.mediaDevices and WebAudio APIs.
Websites shouldn’t need to deal with the Bluetooth audio protocol
in order to simply play or record sound.
However, speakers and microphones can also expose a metadata channel,
for example to control hardware volume, balance,
or even report the position of the user’s head.
A user should be able to pair a device to a site in a single interaction, rather than needing separate actions for each API the site wants to use. The site should be able to associate representations of the same device across multiple APIs.
2.2. Requirements
2.2.1. The Bluetooth API must allow websites to request access to devices they know how to interact with.
2.2.2. The Bluetooth API must allow websites to watch for new devices.
2.2.3. The Bluetooth API should be able to pair a site with a device based on previous user action linking the two.
For example, an OS chooser in which the user selects a particular web site or a previously-consented NFC connection should be sufficient. These may only be sufficient to pair for the duration of the session, rather than permanently.
3. Security considerations
See § 4 Privacy considerations section. [Issue #575]
4. Privacy considerations
4.1. Risks
4.1.1. Exposes a larger kernel attack surface
Bluetooth drivers are complex. Unless a very narrow, well-defined API is exposed to websites through Web Bluetooth, this has the potential to expose a large kernel attack surface to users. For sandboxed user agents, this attack surface would essentially be exposed to the untrusted content, as arbitrary bytes would be controllable by the renderer, unless a very narrow and well defined API is used and can be audited carefully.
For example, compared to the WebAudio API, Bluetooth drivers are probably handle data in a much more complex way and with more complicated abstractions. This leads to a much larger kernel surface area for attackers.
4.1.2. XSS and CSRF attacks on a device
Even if a user only exposes a device to the correct origin, if that origin is not correctly protected, they are exposing the device to XSS and CSRF attacks, where an attacker could modify, delete, or read data from the device, not just the origin. Expressing these risks to users will be a difficult task. This potentially could be mitigated by requiring a user interaction for any explicit code to be executed, so in that way it couldn’t at least happen silently.
Currently, the Same Origin Policy basically makes it so even if a site is compromised, the damage is limited to that origin (that is to say, your local browsing instance and the server you’re communicating with). With the addition of Bluetooth or similar permissions, all of a sudden, an XSS or CSRF potentially affects devices as well. In some ways, you can think of this as an entirely new and privileged domain. Or, alternatively, you could view the device as being added to the origin. In either case, communicating that to the user in a meaningful way is going to be tough/impossible. This changes the promise user agents have been making to users.
4.1.3. A malicious website could exploit a vulnerable device
Like with [WebGL], we should expect that many Bluetooth devices were designed to be accessed only by trusted code. Exposing them to the web will expose many more vulnerabilities which could result in anything from persistent misbehavior to complete reprogramming of the device’s Bluetooth controller. A reprogrammed Bluetooth controller could potentially turn around and attack the user’s computer, for example by pretending to be a Bluetooth keyboard.
4.1.4. A website the user didn’t expect gets access to personal data
A user visits a news website and is shown articles based on data pulled from their diabetes monitor.
4.1.5. A website learns the user’s location by accessing devices that don’t require pairing
Some Bluetooth devices don’t need to be paired in order for a computer to use them, often because they don’t control any information that needs to be private from devices near them. Without pairing between the website and the otherwise non-pairing device, casual surfing may leak private data about the user such as location identifying information from non-paired devices.
Give a more detailed description here involving specific devices.
4.1.6. A website tracks the user’s location by pairing to and accessing an entire class of devices
A store might offer details about an item using a Bluetooth device attached to a particular display. If the site asks for access to this entire class of devices rather than the individual device, and members of the device class are scattered around the environment, the site is likely to be able to discover the user’s location in most cases that the site is opened.
Giving access in the background (in a Service Worker) would give the site the user’s location even when it was closed.
4.1.7. A website tracks a user across cookie reset using Bluetooth device IDs
When a website with access to any Bluetooth device finds its cookies reset, it can connect the user back to their previous server data using the immutable, unique Bluetooth device ID.
4.1.8. Certain active scan requests allow tracking a device’s location
When a BTLE Central or Observer device is scanning for advertising packets and receives one from a Peripheral or Broadcaster, it can send a "scan request" (SCAN_REQ) to the Peripheral in order to receive more data. ([BLUETOOTH42] 6.B.2.3.2.1)
The scan request may contain a persistent ID for the Central device, which would allow a malicious Peripheral to report the location of the Central device.
If a website causes enough active scanning and enough malicious Peripherals are scattered around the environment, this could allow tracking a device’s location.
The "privacy feature" ([BLUETOOTH42] 3.C.10.7)) makes it more difficult to track devices by rotating their address every TGAP(private_addr_int) minutes (recommended to be 15 minutes: ([BLUETOOTH42] 3.C.17))).
4.2. Security and Privacy Requirements
4.2.1. The Bluetooth API must only expose those parts of the general Bluetooth protocol that present an acceptable risk of exploit.
The spec should provide guidance to implementers on ways to mitigate exploits further. For example, a mechanism similar to the GPU Blacklist may be appropriate.
4.2.2. Users must explicitly grant particular websites access to particular devices, even if the device does not intrinsically require pairing.
4.2.3. The website-visible ID for any particular device must change when that website’s cookies are reset.
This doesn’t completely mitigate the risk, since a malicious device can embed a unique ID in any other piece of the protocol it speaks. Check with privacy folks if there’s anything better we can do.