Introduce WebBluetooth support
Categories
(Core :: DOM: Device Interfaces, enhancement, P3)
Tracking
()
People
(Reporter: cjones, Unassigned)
References
()
Details
(Keywords: dev-doc-needed)
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.
Updated•12 years ago
|
Comment 1•12 years ago
|
||
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•12 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•12 years ago
|
||
Don't forget pairing using NFC
Comment 4•12 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) { }
Comment 5•12 years ago
|
||
(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•12 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.
Comment 7•12 years ago
|
||
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•12 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.
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
Updated•12 years ago
|
assinged to me for sec action to schedule a meeting
![]() |
||
Updated•12 years ago
|
Updated•11 years ago
|
Updated•11 years ago
|
Updated•11 years ago
|
Updated•11 years ago
|
![]() |
||
Updated•11 years ago
|
Comment 10•9 years ago
|
||
Wondering if this bug now should be resolved in favor of https://bugzilla.mozilla.org/show_bug.cgi?id=1053673
Comment 11•8 years ago
|
||
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 13•8 years 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
Updated•8 years ago
|
Comment 14•8 years ago
|
||
(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•8 years 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•8 years 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?
Comment 17•8 years 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.
Comment 18•8 years 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.
Comment 19•8 years ago
|
||
The prioritization decision comes from platform management. Given that, we're backburnering the security analysis.
Updated•7 years ago
|
Comment 20•7 years 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•7 years ago
|
Comment 21•6 years ago
|
||
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
Updated•6 years ago
|
Updated•6 years ago
|
Comment 23•6 years ago
|
||
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•6 years ago
|
||
Thanks, Kyle. I would love to have the opportunity to talk to the team about this, if possible. Martin Bluetooth SIG
Comment 25•6 years ago
|
||
I pretty much am the team, so feel free to throw me an email at qdot@mozilla.com.
Comment 26•6 years ago
|
||
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•6 years ago
|
||
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.
Updated•5 years ago
|
Comment 28•5 years ago
|
||
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?
Updated•5 years ago
|
Updated•3 years ago
|
![]() |
||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 29•2 years ago
|
||
What is the current status of WebBluetooth in Firefox? Has it stalled?
Comment 30•2 years ago
|
||
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•2 years ago
|
||
The current Mozilla position on this API according to their Standards Positions page is that it is harmful:
-
Public dashboard summary: https://mozilla.github.io/standards-positions/#web-bluetooth
-
More detailed discussion: https://github.com/mozilla/standards-positions/issues/95#issuecomment-644962468
Updated•1 year ago
|
Comment 32•1 year ago
|
||
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•1 year ago
|
||
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.
Updated•1 year ago
|
Description
•