Intent to Implement: Web Bluetooth

[Jeffrey Yasskin]

Contact emails

jyas...@chromium.org, sch...@chromium.org

Spec

https://webbluetoothcg.github.io/web-bluetooth/ (Note: This is very likely to change before we ship.)

Summary

Allow websites to connect to user-chosen Bluetooth devices over the GATT profile.

Motivation

We are working on building out a Web Bluetooth specification with the standards group; we want to implement this API so that potential users can experiment and help us iterate on the spec.

This API will allow device developers to build websites instead of native apps to communicate with their devices.

We have a list of use cases at http://webbluetoothcg.github.io/web-bluetooth/use-cases.html, although not all will be supported by at least the first version of this API.

Compatibility Risk

We expect the specification and behind-a-flag API to change repeatedly in response to feedback before we ship it.

Firefox: Public support

Internet Explorer: No public signals

Safari: No public signals

Web developers: No signals

Ongoing technical constraints

Blink embedders will need OS permission to use Bluetooth in order to support this feature. On Android, auto-update does not happen when a new permission is requested, which makes this an issue there, but likely not on other platforms.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes. The implementation will use the chrome.bluetooth API implementation, which is currently only fully implemented on ChromeOS and recent Linux/BlueZ, but which has Windows support in progress. We expect to finish them before shipping this web API.

Shipping on Android may lag depending on when we want to take the upgrade hit of requesting a new permission.

OWP launch tracking bug?

None yet.

Link to entry on the feature dashboard

http://www.chromestatus.com/features/5264933985976320

Requesting approval to ship?

No.

[Yoav Weiss]

Very cool! :) Sounds like a great feature that can reduce the gap between Web and native.

Is there an open bug for this feature for Firefox? Do they have any near-future plans to implement/experiment with this feature?

[Elliott Sprehn]

This is exciting! We definitely need Bluetooth on the web. Some of this spec seems kind of weird though, like the gatt.characteristic_extended_properties properties, how do they work with dots in them?

I would suggest picking a small subset of the API and shipping an MVP first and getting feedback early instead of trying to implement the whole thing as well.

[Jeffrey Yasskin]

On Thu, Aug 28, 2014 at 11:03 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Very cool! :) Sounds like a great feature that can reduce the gap between Web and native.

Is there an open bug for this feature for Firefox? Do they have any near-future plans to implement/experiment with this feature?

Firefox's most recent progress was announced at https://groups.google.com/forum/#!topic/mozilla.dev.webapi/Tc30FKg6hvI. They're focused on privileged apps first, so they don't have the requestDevice() function for discovery, but their communication API has the same shape. I don't know of an open bug tracking their effort.

[Jeffrey Yasskin]

On Thu, Aug 28, 2014 at 11:26 AM, Elliott Sprehn <esp...@chromium.org> wrote:

This is exciting! We definitely need Bluetooth on the web. Some of this spec seems kind of weird though, like the gatt.characteristic_extended_properties properties, how do they work with dots in them?

The idea is to mirror the list of constants at https://developer.bluetooth.org/gatt/descriptors/Pages/DescriptorsHomePage.aspx inside navigator.bluetooth.uuids.descriptor. As mentioned, the spec isn't finished yet, so it's likely I've gotten some of the syntax wrong.

I would suggest picking a small subset of the API and shipping an MVP first and getting feedback early instead of trying to implement the whole thing as well.

Most of the pieces of the spec'ed API are either necessary to communicate with devices (requestDevice->services->characteristics->read/write/notify values) or easily polyfillable (variants on service/characteristic/descriptor lookup, list of constants). We might be able to skip the events and maybe descriptors in the first implementation.

We're definitely going to be chasing feedback as soon as possible. We're likely to do a polyfill around the chrome.bluetooth API in parallel with the blink implementation so that we can get even faster feedback, especially on the requestDevice() UI.

[Chris Palmer]

I'm pretty sure this is a feature that should only be available to
secure origins. For example, I wouldn't want any old network attacker
to update my SpiffyCo Bluetooth Gadget, and I would want even the true
SpiffyCo web site to send or receive the Bluetooth Gadget's data in
the clear.

Thoughts?

[Jeffrey Yasskin]

Absolutely, and it's already in the spec: http://webbluetoothcg.github.io/web-bluetooth/#device-access-is-powerful and https://webbluetoothcg.github.io/web-bluetooth/#device-discovery. Let us know if we could improve anything about the wording.

[Chris Palmer]

On Fri, Sep 19, 2014 at 12:23 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

> Absolutely, and it's already in the spec:
> http://webbluetoothcg.github.io/web-bluetooth/#device-access-is-powerful and
> https://webbluetoothcg.github.io/web-bluetooth/#device-discovery. Let us
> know if we could improve anything about the wording.

Excellent!