forked from WebBluetoothCG/web-bluetooth
/
use-cases.html
347 lines (279 loc) · 18.6 KB
/
use-cases.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
<!DOCTYPE html>
<html lang=en>
<head>
<title>Web Bluetooth Use Cases</title>
<meta charset='utf-8'>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
async class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "CG-DRAFT",
shortName: "web-bluetooth",
editors: [
{ name: "See contributors on GitHub",
url: "https://github.com/WebBluetoothCG/web-bluetooth/graphs/contributors"
},
],
edDraftURI: "http://webbluetoothcg.github.io/web-bluetooth/use-cases.html",
wg: "Web Bluetooth Community Group",
wgURI: "https://www.w3.org/community/web-bluetooth/",
wgPublicList: "public-web-bluetooth",
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/72794/status",
otherLinks: [{
key: "Participate",
data: [
{ value: "Join the W3C Community Group",
href: "http://www.w3.org/community/web-bluetooth/",
},
{ value: "File bugs and feature requests",
href: "https://github.com/WebBluetoothCG/web-bluetooth/issues",
},
{ value: "Fix the text through GitHub",
href: "https://github.com/WebBluetoothCG/web-bluetooth",
},
{ value: "IRC: #web-bluetooth on W3C's IRC",
href: "irc://irc.w3.org:6665/#web-bluetooth",
},
{ value: "Public Mailing List",
href: "http://lists.w3.org/Archives/Public/public-web-bluetooth/",
},
],
}],
maxTocLevel: 2,
localBiblio: {
"BLUETOOTH41": {
href: "https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=282159",
title: "BLUETOOTH SPECIFICATION Version 4.1",
publisher: "Bluetooth SIG",
date: "3 December 2013",
},
},
};
</script>
</head>
<body>
<section id="abstract">
<p>This specification provides a collection of use cases for Bluetooth in the web platform.
</section>
<section id="sotd">
<p>Comments on the document should be filed as issues at <a href="https://github.com/WebBluetoothCG/web-bluetooth/issues">https://github.com/WebBluetoothCG/web-bluetooth/issues</a>.</p>
</section>
<section class="informative">
<h2>Introduction</h2>
<p>We intend to define an API that uses <a href="https://developer.bluetooth.org/">Bluetooth</a> to discover and communicate with devices.
This document collects use cases for such an API.
</section>
<section id="usecases">
<h2>Use-Cases and Requirements</h2>
<section id="usecases_section">
<h2>Use-Cases</h2>
<p>
These are potential use cases for Bluetooth in general,
but they may not all be supported in
the initial versions of the <a href="index.html">Web Bluetooth API</a>.
<section id="usecase_new_device_vendor_site">
<h2>Designer of a new device writes a web page to control that device</h2>
<p>A group making a product like <a href="https://www.fitbit.com/">Fitbit</a>, a <a href="https://www.sportchalet.com/product/302090_3192991.do">heart rate monitor</a>, or a <a href="https://www.walmart.com/ip/37650811">singing lightbulb</a>
can write a web site that users can navigate to and control their device.
<p>Other devices include:
<ul>
<li>
<a href="http://amzn.com/B007HOGNLW">Bicycle cadence sensor</a>
(<a href="https://developer.bluetooth.org/gatt/profiles/Pages/ProfileViewer.aspx?u=org.bluetooth.profile.cycling_speed_and_cadence.xml">standard profile</a>)
<li><a href="http://www.barcodegiant.com/unitech/part-ms840-subbgc-sg.htm">Barcode scanner</a>
<li><a href="http://www.bhphotovideo.com/bnh/controller/home?sku=1024990&Q=&is=REG&A=details">BT security tags</a>
<li><a href="http://www.mobilefun.com/44028-parrot-flower-power-bluetooth-indooroutdoor-plant-sensor-green.htm">BT plant sensors</a>
<li>
<a href="http://www.bhphotovideo.com/bnh/controller/home?O=&sku=1014794&Q=&is=REG&A=details">Camera shutter remote</a>
(this may be a <a href="https://developer.bluetooth.org/gatt/profiles/Pages/ProfileViewer.aspx?u=org.bluetooth.profile.hid_over_gatt.xml">HID device</a>)
<li><a href="http://www.weatherconnection.com/product.asp?itmky=148800">BT weather station</a>
<li><a href="http://www.escali.com/smartconnect-kitchen-scale">BT kitchen scale</a>
<li><a href="http://www.houseofscuba.com/computers/com113.html">BT enabled dive logger</a>
<li><a href="http://www.thinkgeek.com/product/1898/">Robotic car</a>
</ul>
</section>
<section id="usecase_third_party_site">
<h2>Third party writes a web page to control a device</h2>
<p>
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
<a href="https://www.sportchalet.com/product/302090_3192991.do">lots</a>
<a href="http://www.heartratemonitorsusa.com/polar-h7-transmitter.html">of</a>
<a href="http://www.amazon.com/Jarv-Premium-Bluetooth%C2%AE-Monitor-Motorola/dp/B00GWSQFPS">different</a>
<a href="http://www.cellphoneshop.net/heartmonitor.html">heart</a>
<a href="http://www.wtek-usa.com/hs2bt_strapless_bluetooth_heart_rate_sensor.php">rate</a>
<a href="http://www.amazon.com/Wahoo-Heart-Monitor-iPhone-Android/dp/B006NZH0TU">monitors</a>.
</section>
<section id="usecase_lazy_scale">
<h2>Bluetooth <abbr title="Low Energy">LE</abbr> scale begins advertising after the user has opened its web page.</h2>
<p>A user opens their <a href="https://www.amazon.com/WiTscale-S1-Bluetooth-Bathroom-Technology/dp/B009RGD6I6"><abbr title="Bluetooth Low Energy">BTLE</abbr> scale</a>'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.
</section>
<section id="usecase_device_url">
<h2>Device advertised URL opened by user.</h2>
<p>As described in <a href="https://github.com/scottjenson/physical-web">Physical Web</a>, 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.</p>
<p>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.
</section>
<section id="usecase_nfc_handover">
<h2>NFC Handover.</h2>
<p>
<em>Likely unsupported initially because of the immaturity of [[nfc]].</em>
<p>A website may already have established a <a href="https://en.wikipedia.org/wiki/Near_field_communication">Near Field Communication</a> (<abbr title="Near Field Communication">NFC</abbr>) 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.</p>
<p>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.
</section>
<section id="usecase_beacon">
<h2>Beacons</h2>
<p>
<em>Likely unsupported initially because of
the <a href="#risk_class_pairing_data_leak">privacy risks</a>
of granting access to a class of devices.</em>
<p>
Bluetooth beacons can allow a web page to get precise indoor location or to detect distance to interesting physical objects.
<a href="http://en.wikipedia.org/wiki/IBeacon">iBeacon</a> and <a href="https://www.paypal.com/webapps/mpp/beacon">PayPal Beacons</a>
are particularly famous examples.
</section>
<section id="usecase_audio_control">
<h2>Audio control</h2>
<p>
The process of playing audio to a Bluetooth speaker or
recording from a Bluetooth microphone should be handled by a combination of the
<code><a href="http://dev.w3.org/2011/webrtc/editor/getusermedia.html#enumerating-devices">navigator.mediaDevices</a></code> and
<a href="http://webaudio.github.io/web-audio-api/#AudioDestinationNode">WebAudio</a> 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.
<p>
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.
</section>
</section>
<section id="requirements_section">
<h2>Requirements</h2>
<section id="req_request">
<h2>The Bluetooth API must allow websites to request access to devices they know how to interact with.</h2>
</section>
<section id="req_watch">
<h2>The Bluetooth API must allow websites to watch for new devices.</h2>
</section>
<section>
<h2>The Bluetooth API should be able to pair a site with a device based on previous user action linking the two.</h2>
<p>
For example, an <abbr title="Operating System">OS</abbr> 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.
</section>
</section>
</section>
<section id="security_privacy">
<h2>Security and Privacy Considerations</h2>
<section id="risks">
<h2>Risks</h2>
<section id="kernel_attack_surface">
<h2>Exposes a larger kernel attack surface</h2>
<p>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.</p>
<p>For example, compared to the
<a href="http://webaudio.github.io/web-audio-api/#AudioDestinationNode">WebAudio</a>
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.</p>
</section>
<section id="device_management_attacks">
<h2>XSS and CSRF attacks on a device</h2>
<p>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.</p>
<p>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.</p>
</section>
<section id="risk_vulnerable_device">
<h2>A malicious website could exploit a vulnerable device</h2>
<p>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.
</section>
<section id="risk_unexpected_use">
<h2>A website the user didn't expect gets access to personal data</h2>
<p>A user visits a news website and is shown articles based on data pulled from their diabetes monitor.
</section>
<section id="risk_unpaired_data_leak">
<h2>A website learns the user's location by accessing devices that don't require pairing</h2>
<p>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.
<p class="issue">Give a more detailed description here involving specific devices.
</section>
<section id="risk_class_pairing_data_leak">
<h2>A website tracks the user's location by pairing to and accessing an entire class of devices</h2>
<p>
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.
<p>
Giving access in the background (in a <a href="https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html">Service Worker</a>)
would give the site the user's location even when it was closed.
</section>
<section id="risk_tracking">
<h2>A website tracks a user across cookie reset using Bluetooth device IDs</h2>
<p>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.
</section>
<section>
<h2>Certain active scan requests allow tracking a device's location</h2>
<p>
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" (<code>SCAN_REQ</code>) to the Peripheral in order to receive more data. ([[BLUETOOTH41]] 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" ([[BLUETOOTH41]] 3.C.10.7)) makes it more difficult to track devices by rotating their address every <code>T<sub>GAP</sub>(private_addr_int)</code> minutes (recommended to be 15 minutes: ([[BLUETOOTH41]] 3.C.17))).
</section>
</section>
<section id="secpriv_requirements">
<h2>Security and Privacy Requirements</h2>
<section id="secprvreq_protocol_restriction">
<h2>The Bluetooth API must only expose those parts of the general Bluetooth protocol that present an acceptable risk of exploit.</h2>
<p>The spec should provide guidance to implementers on ways to mitigate exploits further. For example, a mechanism similar to the <a href="https://www.khronos.org/webgl/wiki/BlacklistsAndWhitelists">GPU Blacklist</a> may be appropriate.
</section>
<section id="secprvreq_pairing">
<h2>Users must explicitly grant particular websites access to particular devices, even if the device does not intrinsically require pairing.</h2>
</section>
<section id="secprvreq_tracking">
<h2>The website-visible ID for any particular device must change when that website's cookies are reset.</h2>
<p class="issue">
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.
</section>
<section>
<h2>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.</h2>
</section>
</section>
</section>
<section id="acknowledgments" class="informative">
<h2>Acknowledgments</h2>
<p>[A bunch of names go here]
</section>
</body>
</html>