Status

()

Core
General
6 years ago
9 months ago

People

(Reporter: cjones, Unassigned)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

Trunk
dev-doc-needed
Points:
---
Dependency tree / graph
Bug Flags:
sec-review +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

I'm not familiar with the Bluetooth protocol, but the goals are the same as for WebUSB (674718), just for Bluetooth.  Hopefully a lot of code can be shared, especially the permission model.  Can crib off of existing APIs.
OS: Linux → All
Hardware: x86_64 → All
Some time ago in BONDI initiative a WebAPI for Bluetooth was drafted [1]. 

As you may see the main editor was Jim O'Leary from rococo software [2], which is a company that developed a Java Bluetooth API (JSR-82) shipped on millions of phones. Due to that I think it may be a good starting point (at least from a functional point of view). If I remember properly I think Aplix Web Runtime implemented (at least partially) this API.

[1] http://bondi.omtp.org/1.5/pwd-2/bluetooth.htm
[2] http://www.rococosoft.com/

Comment 2

6 years ago
Bluetooth is a quite complex stack of various protocols and profiles which allow you to do a wide variety of things, some of which are actually useful in practice and many which aren't. I'd therefore start off by creating a fairly minimal list of important use-cases the API needs to enable and then start drafting the API based on that.

If we take as an example a web application or game that wants to talk over Bluetooth to other remote instances of its kind the following set of API features could be useful:

- Remote Device discovery

- Pairing

- Service discovery (in some stacks, like the Linux BlueZ this part is automatically performed after pairing, so you don't necessarily need a separate API for it). The minimum thing it should provide to the application is a list of profile UUIDs that a remote device supports.

- Iterating through a list of remote devices the user has configured into use. This isn't necessarily a list of paired devices since not all devices will require pairing (e.g. this is optional for Bluetooth mice and it's likely that many upcoming single mode Bluetooth Low Energy devices wont have security).

- Initiating connections as a client, both for RFCOMM and L2CAP. In its simplest form the only input parameters that should be needed are the remote address and the UUID of the profile that should be connected to. The stack should be able to handle the rest. It's a bit worrying that the bondi spec mentioned in the previous comment focuses mostly on RFCOMM support since RFCOMM is essentially a deprecated protocol (e.g. the Bluetooth SIG wont be coming out with any new RFCOMM based profiles anymore but are actively updating specs to use the new enhance L2CAP features. 

- Accepting incoming connections as server, both for RFCOMM and L2CAP. Here also the simplest API would be just a single UUID and whether this is a RFCOMM or L2CAP service. The stack should then be able to allocate the next free RFCOMM channel or PSM as well as construct a local SDP service record with the relevant UUIDs as well as the selected PSM or RFCOMM channel. There should also be the ability to set a security level for the service as well as whether the service requires authorization of incoming connections.

Comment 3

6 years ago
Don't forget pairing using NFC
Blocks: 711601

Comment 4

6 years ago
This is an initial API sketch. Discussion very welcome.

navigator.bluetooth.adaptor => currently selected default adaptor object

adaptor object:

adaptor.address

var request = adaptor.queryAdaptorState();
request.onresult = function(state) {
    state.name, state.enabled, state.discovering (boolean), state.scanMode, state.bondedDevices (array of devices)
}
request.onerror = function(error)

adaptor.setName() // sets the friendly name
adaptor.startDiscovery() // trigger a new discovery
adaptor.ondiscovery
adaptor.ondiscoveryfinished
adaptor.ondevicefound = function(device) {
}
adaptor.onerror = function(error) {
}

adaptor.listen(name, uuid, { insecure: true })
adaptor.onconnect = function(socket) {
  // no data is received until this event has fired, so we can attach the right receive handler in here
}

device object:

device.address
device.majorDeviceClass (string)
device.deviceClass (string)
device.services (object with a property of value 'true' for each service supported)

var request = device.queryDeviceState();
request.onresult = function(state) {
  state.name, state.bonded, state.uuids (object with property of value 'true' for each uuid)
}
request.onerror = function(error)

device.startServiceDiscovery(); // trigger a new service discovery
device.onservicediscovery
device.onservicediscoveryfinished
device.onservicefound = function(uuid) {
}
device.onerror = function(error) {
}

device.connect(uuid)
device.onconnect = function(socket) {
  // no data is received until this event has fired, so we can attach the right receive handler in here
}

socket object:

socket.device: remote device (object)
socket.onreceive = function(arraybuffer) {
}
socket.send(arraybuffer, offset[=0], bytes[=all])
socket.close()
socket.onerror = function(error) {
}
(In reply to Andreas Gal :gal from comment #4)
> var request = adaptor.queryAdaptorState();
> request.onresult = function(state) {
>     state.name, state.enabled, state.discovering (boolean), state.scanMode,
> state.bondedDevices (array of devices)
> }
> request.onerror = function(error)

> var request = device.queryDeviceState();
> request.onresult = function(state) {
>   state.name, state.bonded, state.uuids (object with property of value
> 'true' for each uuid)
> }
> request.onerror = function(error)

Nit:
Requests object usually have a onsuccess function (and 'success' event), not onresult/result.
In addition, there is an event object passed to the method, not a state object. This event object can contain a state object. But what seems to be more usual is that request has a result attribute that is a state object.
So, we should have:
var request = adaptor.queryAdaptorState();
request.onsuccess = function() {
  var state = request.result;
  state.name, state.enabled, state.discovering (boolean), state.scanMode, state.bondedDevices (array of devices)
}

I unfortunately can't really give any more interesting feedback on the API: I know nothing about Bluetooth.

Oh, btw, it might be interesting to add that draft to the wiki.

Comment 6

6 years ago
#5 sounds good. Once Kyle had a chance to give some feedback (he knows bluetooth) we will put this on the wiki and mail it to dev-webapi.
From what I know of bluetooth (My knowledge of bluetooth now stretches back a full week :P ), this looks sane for doing the low level device enum work. It seems to be missing any way to actually bond with the device (passing secret keys, etc...), but I'm not exactly sure what the flow of that looks like quite yet, I've mostly been figuring out how to get the services started on gonk. 

I'm guessing we'll probably specialize more on top of this once we get into services (HID, headsets, etc...) but I think we can get through device enumeration with this.

Comment 8

6 years ago
Yeah, I left out some binding stuff and also high-level service abstractions (most bluetooth stacks directly support stuff like "headset" so you don't have to pipe audio data back and forth). Lets get started with this, I will spec out the rest as well.
No longer blocks: 711601
Blocks: 727618
Keywords: dev-doc-needed

Updated

6 years ago
Whiteboard: 661877

Updated

6 years ago
Whiteboard: 661877
Keywords: sec-review-needed
assinged to me for sec action to schedule a meeting
Whiteboard: [secr:curtisk]
Depends on: 749362
Whiteboard: [secr:curtisk] → [sec-assigned:curtisk:749362]
No longer blocks: 727618
Depends on: 727618
Alias: webbluetooth
Flags: sec-review?(curtisk)
Depends on: 767598
Depends on: 790106
Depends on: 793977
Depends on: 806547
Depends on: 807758
Flags: sec-review?(curtisk) → sec-review+
Whiteboard: [sec-assigned:curtisk:749362]
See Also: → bug 926253

Comment 10

2 years ago
Wondering if this bug now should be resolved in favor of https://bugzilla.mozilla.org/show_bug.cgi?id=1053673
Is this the bug we should be tracking for WebBluetooth [1] APIs across Gecko? Can we get a status update? 

Bluetooth is going to be a critical API for us if web-apps are going to play in the connected-devices space. Chrome is shipping (behind a flag) and is already evangelising its use.

[1] https://webbluetoothcg.github.io/web-bluetooth/
Flags: needinfo?(tlee)
Flags: needinfo?(kyle)
Ben Tian would know better.
Flags: needinfo?(tlee) → needinfo?(btian)

Comment 13

a year ago
(In reply to Wilson Page [:wilsonpage] from comment #11)
> Is this the bug we should be tracking for WebBluetooth [1] APIs across
> Gecko? Can we get a status update? 

Wilson,

WebBluetooth API implementation in Gecko is suspended now, since Platform team regards the API 1) has security problem [1] and 2) is low priority. You may use the non-standard API [2] in Gecko already.

[1] https://github.com/WebBluetoothCG/web-bluetooth/issues/46
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/API/Bluetooth_API#Gatt_interfaces
Flags: needinfo?(btian)

Updated

a year ago
See Also: → bug 1204396
Flags: needinfo?(kyle)
(In reply to Ben Tian [:btian] from comment #13)
> You may use the non-standard API [2] in Gecko already.

This looks like it's only available for fxos devices. Sounds like Mozilla should be working with Google to iron out these issues. Is that happening?

I'm concerned if work on this is halted with no indication of moving forward. Without this API connected-devices teams will have to build many experiences as native apps.

Ben, can we re-open the discussion here with the relevant people?
Flags: needinfo?(btian)

Comment 15

a year ago
@Ben: Has the Platform team validated the concerns in https://github.com/WebBluetoothCG/web-bluetooth/issues/46, or is it just that we don't know, and they don't think it's worth investing the resources to find out?

Comment 16

a year ago
(In reply to Jeffrey Yasskin from comment #15)
> @Ben: Has the Platform team validated the concerns in
> https://github.com/WebBluetoothCG/web-bluetooth/issues/46, or is it just
> that we don't know, and they don't think it's worth investing the resources
> to find out?

Jeffrey,

AFAIK, :ekr from Mozilla has discussed the security concern with you but he's not convinced. Also I don't know the rationale behind the low priority decision. ni? :ekr to recap discussion.

:ekr, can you help recap your discussion with Jeffrey and maybe answer his question above?
Flags: needinfo?(ekr)

Comment 17

a year ago
(In reply to Wilson Page [:wilsonpage] from comment #14)
> This looks like it's only available for fxos devices. Sounds like Mozilla
> should be working with Google to iron out these issues. Is that happening?

Please see comment 16.

> I'm concerned if work on this is halted with no indication of moving
> forward. Without this API connected-devices teams will have to build many
> experiences as native apps.
>
> Ben, can we re-open the discussion here with the relevant people?

I've ni?d ekr and Jeffrey from Google is here.
Flags: needinfo?(btian)

Comment 18

a year ago
Ah, ok. I do owe ekr@ an essay about the tradeoffs we're facing here between forcing people onto native apps vs accepting imperfect security in web apps. None of the concerns he mentioned to me were related to the keyboard threat in https://github.com/WebBluetoothCG/web-bluetooth/issues/46.
The prioritization decision comes from platform management. Given that, we're backburnering the security analysis.
Flags: needinfo?(ekr)

Updated

10 months ago
A post by Lukasz Olejnik around the privacy issues related to this API:
https://blog.lukaszolejnik.com/w3c-web-bluetooth-api-privacy/

Might be good to read over the above if we reconsider working on this API in the future.

Updated

10 months ago
You need to log in before you can comment on or make changes to this bug.