Web Bluetooth Use Cases

Draft Community Group Report,

More details about this document
This version:
Issue Tracking:
Inline In Spec
See contributors on GitHub
Join the W3C Community Group
Fix the text through GitHub
public-web-bluetooth@w3.org (archives)
IRC: #web-bluetooth on W3C’s IRC


This specification provides a collection of use cases for Bluetooth in the web platform.

Status of this document

This specification was published by the Web Bluetooth Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

Changes to this document may be tracked at https://github.com/WebBluetoothCG/web-bluetooth/commits/gh-pages.

If you wish to make comments regarding this document, please send them to public-web-bluetooth@w3.org (subscribe, archives).

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. 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.

4.2.4. Scans must either enable the Bluetooth privacy feature or must use passive scanning until the user has indicated interest in information from the active scan.


Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.


Normative References

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119

Informative References

BLUETOOTH SPECIFICATION Version 4.2. 2 December 2014. URL: https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=286439
Luc Yriarte; Samuel Ortiz; Don Coleman. Web NFC API. 16 June 2015. NOTE. URL: https://www.w3.org/TR/nfc/
Dean Jackson; Jeff Gilbert. WebGL 2.0 Specification. 12 August 2017. URL: https://www.khronos.org/registry/webgl/specs/latest/2.0/

Issues Index

See § 4 Privacy considerations section. [Issue #575]
Give a more detailed description here involving specific devices.
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.