Web Bluetooth

[autonome]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Bluetooth
• Specification or proposal URL: https://webbluetoothcg.github.io/web-bluetooth/
• Caniuse.com URL (optional): https://caniuse.com/#search=bluetooth
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=674737
• Mozillians who can provide input (optional):
• Webkit bug: https://bugs.webkit.org/show_bug.cgi?id=101034

Other information

Out in the wild, devrel folks get peppered constantly with questions about WebBluetooth support. We are also getting this question from the communities and projects working on distributed/decentralized web recently, due to recent Bluetooth mesh spec release.

It would be really helpful if we had a position statement here on the repo, that we can point people at.

[adamroach]

I believe that this API has the same fundamental problems as WebUSB and WebMIDI, in that it exposes low-level, non-semantic interfaces to the web platform in a way that would allow web content to potentially interact with the underlying operating system in malicious ways. (The classic example of updating the firmware of a device so that it can emulate HID devices would appear to apply here; see WebBluetoothCG/web-bluetooth#46). Unless we know how to prevent these kinds of exploits (and a dialog that simply says https://foo.example.com/ wants to pair with: John's Phone is really insufficient to explain the potential damage), I think our position needs to be that the API is harmful.

[reillyeon]

There is semantic meaning to the interfaces being exposed. GATT characteristics have UUIDs and a subset of these are standardized. The discussion of WebMIDI in #58 points out that providing access to the standardized and semantic functions of a device can be allowed while blocking non-standardized functions (in the WebMIDI case, vendor-specific SysEx messages). There is a similar distinction to be made for Web Bluetooth. This approach would still preserve much of the usefulness of the API.

[adamroach]

@reillyeon -- Thanks for the pointer! Is there some standardized distinction between the semantic and non-standardized functions in the API right now? That is: if a partial implementation that only implemented the "safe" parts of the API were deployed, would web content be able to use normal feature detection techniques to distinguish it from the full API?

[reillyeon]

When validating the arguments to navigator.bluetooth.requestDevice() the specification says to throw a SecurityError if a required service UUID in the device filter is on the block list and remove the service UUID if it is requested optionally. I think this could be used for feature detection if the implementation treated all services as being in the block-list unless explicitly allowed.

[qdot]

I do not believe those that would be responsible for management and implementation of WebBluetooth are ready to discuss the viability and company position of the API in Firefox at the moment.

Before we start public discussion and position statements on this matter, more internal review needs to be done, and we need to create a better informational basis presented to outline the conversation. Bluetooth is a complex technology, even before adding cross platform implementation issues, web trust models, and other complications of web implementations to the fray. Addressing these issues will require in-depth research, as well as time and resources to answer questions and concerns. As far as I am aware, we do not have those time or resources available at the moment.

I ask that this issue be frozen until those responsible for device work in the browser have time to produce and formalize this material, which will hopefully facilitate the conversation when it does happen.

[dbaron]

When we review this, we may want to review Web Bluetooth Scanning at the same time.

[reillyeon]

As an editor I recommend reviewing Web Bluetooth Scanning and GATT Communication (the main section of the the Web Bluetooth specification discussed above) separately as the security and privacy implications are very different.