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.
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/
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.
Don't forget pairing using NFC
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.
#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.
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.
assinged to me for sec action to schedule a meeting
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/
Ben Tian would know better.
(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
(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?
@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?
(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?
(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.
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.
or
