674737 - (webbluetooth) Introduce WebBluetooth support

Status: RESOLVED WONTFIX

(Core :: DOM: Device Interfaces, enhancement, P3)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 1

[Daniel Coloma:dcoloma]

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

[Johan Hedberg]

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

[Lars Gunther]

Don't forget pairing using NFC

Comment 4

[Andreas Gal :gal]

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) {
}

Comment 5

[Mounir Lamouri (:mounir)]

(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

[Andreas Gal :gal]

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

Comment 7

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

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

[Andreas Gal :gal]

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.

Comment 9

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

assinged to me for sec action to schedule a meeting

Comment 10

[Michael[tm] Smith [:sideshowbarker]]

Wondering if this bug now should be resolved in favor of https://bugzilla.mozilla.org/show_bug.cgi?id=1053673

Comment 11

[Wilson Page [:wilsonpage]]

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/

Comment 12

[Thinker Li [:sinker]]

Ben Tian would know better.

Comment 13

[Ben Tian (inactive)]

(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

Comment 14

[Wilson Page [:wilsonpage]]

(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?

Comment 15

[Jeffrey Yasskin]

@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

[Ben Tian (inactive)]

(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?

Comment 17

[Ben Tian (inactive)]

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

Comment 18

[Jeffrey Yasskin]

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.

Comment 19

[Eric Rescorla (:ekr)]

The prioritization decision comes from platform management. Given that, we're backburnering the security analysis.

Comment 20

[Marcos Caceres [:marcosc]]

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.

Comment 21

[Martin Woolley]

Hello, I work for the Bluetooth SIG. 

I'm interested in the potential which a W3C standard Bluetooth LE API for browsers offers, though I not also some of the concerns raised by others. I'd welcome seeing work actively underway between the various parties to see if issues can be satisfactorily addressed. Bluetooth LE APIs are in most other platforms, including the various smartphone platforms. Bluetooth is going to be used increasingly in enterprise computing scenarios and as such, cloud technology with web applications rather than native desktop applications is likely to be the preferred architecture.

Aside from expressing our support, is there anything more tangible which the Bluetooth SIG might be able to contribute? I'd be happy to discuss by phone or face to face.

Thanks

Martin

Comment 23

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

We are currently evaluating feasibility of WebBluetooth, and will update both our platform position (https://github.com/mozilla/standards-positions) and this bug once that is finished. Due to resource constraints, this evaluation make some time, so we ask for your patience while this work happens.

Comment 24

[Martin Woolley]

Thanks, Kyle. I would love to have the opportunity to talk to the team about this, if possible.

Martin
Bluetooth SIG

Comment 25

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

I pretty much am the team, so feel free to throw me an email at [e-mail].

Comment 26

[brentkimmel]

I'm not from a SIG or anything, but as a good citizen of the "Open Web" I want to second Martin's sentiment regarding how important this standard is to the Web. I believe that like Service Worker, the Mozilla team is the most important catalyst in the conversion of this from "One-off experiment" to "responsibly implemented feature of the web".

Comment 27

[eeisaman]

As a teacher of IoT and CS, I find many students wanting to integrate their BLE devices into their web applications.  I strongly feel this standard should be implemented soon.

Comment 28

[Jordan Austin]

Just wondering what the status is on this discussion. It appears that maybe the security concerns have been somewhat satisfied? Has any development work been done to implement Web Bluetooth in Firefox?

Comment 29

[rhills]

What is the current status of WebBluetooth in Firefox? Has it stalled?

Comment 30

[Martin Woolley]

My impression is that work on Web Bluetooth never started. I work for the Bluetooth SIG and would like to repeat an offer I made in the past. If there's anything I can do to help address whatever issues are preventing this feature being implemented in Firefox, please let me know. I can't help with resourcing but I can certainly help people get up to date with the Bluetooth Low Energy of today. Over to you :-)

Comment 31

[Dietrich Ayala (:dietrich)]

The current Mozilla position on this API according to their Standards Positions page is that it is harmful:

1. Public dashboard summary: https://mozilla.github.io/standards-positions/#web-bluetooth

2. More detailed discussion: https://github.com/mozilla/standards-positions/issues/95#issuecomment-644962468

Comment 32

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 12 votes and 75 CCs.
:cmartin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 33

[Chris Martin [:cmartin]]

Closing this bug as WONTFIX.

It is possible that Mozilla's position on this API will change in the future, and if such a thing happens then we can either re-open this bug or create another one to track that work, but this bug is explicitly no-priority right now given that our official position is that we think implementing it is harmful to the web.