Open
Bug 674737
(webbluetooth)
Opened 10 years ago
Updated 9 months ago
Introduce WebBluetooth support
Categories
(Core :: DOM: Device Interfaces, defect, P3)
Core
DOM: Device Interfaces
Tracking
()
NEW
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•10 years ago
|
OS: Linux → All
Hardware: x86_64 → All
Comment 1•10 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•10 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•10 years ago
|
||
Don't forget pairing using NFC
Comment 4•9 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•9 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•9 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•9 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•9 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•9 years ago
|
Blocks: b2g-bluetooth
Updated•9 years ago
|
Keywords: dev-doc-needed
Updated•9 years ago
|
Whiteboard: 661877
Updated•9 years ago
|
Whiteboard: 661877
Updated•9 years ago
|
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]
Updated•9 years ago
|
No longer blocks: b2g-bluetooth
Depends on: b2g-bluetooth
Updated•9 years ago
|
Alias: webbluetooth
Updated•9 years ago
|
Flags: sec-review?(curtisk)
Updated•8 years ago
|
Depends on: b2g-bluetooth-a2dp
Flags: sec-review?(curtisk) → sec-review+
Whiteboard: [sec-assigned:curtisk:749362]
Comment 10•6 years ago
|
||
Wondering if this bug now should be resolved in favor of https://bugzilla.mozilla.org/show_bug.cgi?id=1053673
Comment 11•5 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/
Flags: needinfo?(tlee)
Flags: needinfo?(kyle)
Comment 13•5 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
Flags: needinfo?(btian)
Updated•5 years ago
|
Flags: needinfo?(kyle)
Comment 14•5 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?
Flags: needinfo?(btian)
Comment 15•5 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•5 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?
Flags: needinfo?(ekr)
Comment 17•5 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.
Flags: needinfo?(btian)
Comment 18•5 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•5 years ago
|
||
The prioritization decision comes from platform management. Given that, we're backburnering the security analysis.
Flags: needinfo?(ekr)
Updated•4 years ago
|
Comment 20•4 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•4 years ago
|
Comment 21•3 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•3 years ago
|
Assignee: nobody → kyle
Updated•3 years ago
|
Component: General → DOM: Device Interfaces
Priority: -- → P3
Comment 23•3 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•3 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•3 years ago
|
||
I pretty much am the team, so feel free to throw me an email at qdot@mozilla.com.
Comment 26•3 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•3 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•3 years ago
|
Summary: WebBluetooth → Introduce WebBluetooth support
Comment 28•2 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•2 years ago
|
Assignee: kyle → nobody
Updated•9 months ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•