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 https://github.com/WebBluetoothCG/web-bluetooth/issues/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.

[martinthomson]

I've taken a closer look at the specification and it is in essentially the same state WebUSB was before capability descriptors were added. I'm recommending the "harmful" position that @adamroach first suggested is correct for this API.

[mrquincle]

To make this issue self-contained, this is the position from the commit:

"This API provides access to the Generic Attribute Profile (GATT) of Bluetooth, which is not the lowest level of access that the specifications allow, but its generic nature make it impossible to clearly. Like WebUSB there is significant uncertainty regarding how well prepared devices are to receive requests from arbitrary sites. The generic nature of the API means that this risk is difficult to manage. The Web Bluetooth CG has opted for weaker protections than those in WebUSB, which require active consent to communicate from the device. This proposal uses a blocklist, which will require constant and active maintenance so that vulnerable devices aren't exploited. This model is unsustainable and presents a signficant risk to users and their devices."

[rjcorwin]

a dialog that simply says https://foo.example.com/ wants to pair with: John's Phone is really insufficient to explain the potential damage

@adamroach Isn't that better than most operating systems do with native apps?

[adamroach]

@rjsteinert

@adamroach Isn't that better than most operating systems do with native apps?

The basic answer is that the web platform has always had to do not just better than native apps, but much better, because of the way that users conceptualize "installing apps" versus "browsing the web".

To the extent that the majority of users understand security practices, it's pretty well known that installing a malicious app can have arbitrarily catastrophic results. At the same time, it is our job to make sure that visiting malicious web sites is as safe as we can reasonably make it, because browsing the web cannot become as inherently risky as constantly installing a series of potentially malicious apps from every site you visit.

Importantly, this means that any action that exposes the user to a risk -- say, turning on a microphone -- must be explained in a way so that the user clearly understands the risk and proactively consents to it. With the microphone example, this is pretty obvious: you can convey in just a few words that the website in question will be able to hear you, and users can extrapolate entirely what that means.

For raw device access as envisioned in a number of APIs (Web USB, Web Bluetooth, Web NFC, and Web MIDI), the risks of exposing those APIs to users cannot be reasonably conveyed. This is pretty much an intractable flaw of allowing raw, non-semantic access to devices regardless of the protocol used to do so.

The specific issue is: it's not intuitive that allowing malicious-site.com to access your Bluetooth keyboard might give that site access to your stored passwords, give them the ability to hijack your DNS settings, or allow them to encrypt your hard drive and hold it ransom. And if it's not immediately obvious how those things are possible, that only serves to demonstrate how completely non-intuitive the risks are and how intractable trying to explain them in a permission prompt would be.

[rjcorwin]

Thank you for the thorough reply @adamroach. I'm humbled by the risks you mention and agree they cannot be explained in just a few words. Specifically I'm interested in supporting a standard that would allow P2P in-person messaging between apps, which might use bluetooth under the hood, but to accomplish this does not need the full API of Bluetooth to accomplish it. I'll also continue to ruminate on the users understanding of "installing apps" versus "browsing the web".

[ekr]

@rjsteinert FWIW I think it's at least theoretically possible that you could build some kind of extension to WebRTC to use BT for communication instead of IP. But that's just handwaving, I don't have anything like a detailed design

[chrysn]

The Mozilla position is clear and reasonable, but there is need for something in this direction from applications.

Would a change to the Web Bluetooth proposal, like

• using a whitelist instead of a blacklist,
• adding a "available for web" characteristic to the BLE descriptor in the spirit of the USB Platform Capability Descriptor

suffice to turn this towards a positive standards position?

If so, is there an issue open at the WebBluetoothCG document that outlines the shortcomings (on a brief look I only found https://github.com/WebBluetoothCG/web-bluetooth/issues/46)? That might be a slightly more productive point for people disappointed with this outcome to leave thumbs-up reactions at rather than thumbs-down here.

[mrquincle]

It would be great to close this issue with a reference to a place where people can discuss the position.

Some questions I would have about the process on Mozilla positions:

• Where can I read "who Mozilla" is?
• Where can I read who is defining the position?
• Where can I read about the voting process or the other means with which it is ensured that this is not the position of a few people or developers?
• What happens when those people have moved on?
• Where can I read when positions are reconsidered?

Then, regarding Web Bluetooth itself, I would also expect something like that, detailing the process on accepting Web Bluetooth.

• Is Web Bluetooth in any shape or form out of the question?
• Is there any type of improvement in user approval possible that would increase user protection against malicious actors using Bluetooth?
• Are there improvements in the browser required before doing this?

And, practically, the development process.

• Which version of Web Bluetooth could be worked upon by someone?
• What security features can be worked on?
• Who's willing to work on those?

Of course, it would go to far to do that in an issue like this, but it might be useful to have a place for it.

[webprofusion-chrisc]

Is this the only place where this topic is being discussed? Currently I just direct users to use Chrome or Edge where Web Bluetooth already works but that doesn't really seem right in the spirit of open standards.

The blocker here seems to be that given write access to a device, devices can theoretically be updated to do things nefarious (like updating a device firmware to pretend to be a keyboard and have it capture user keystrokes etc). Perhaps there is also a general worry that devices can also be destroyed by malicious firmware scrambling etc.

The primary objection is that asking a user if it's ok to connect to a device isn't enough to say what could happen to that device, so how about a warning that the worst could happen and a link to read more information, with checkbox to confirm acknowledgement? Or is the real root of the problem a lack of resources/will to implement this feature (e.g. why bother when there are other things that need worked on).

Obviously we can just direct users to other browsers for features like this (see also web midi) in the meantime but I worry this gradually erodes the relevance of Firefox.

[tomrittervg]

I am not speaking on behalf of all Mozilla, but I would also be concerned about violating the same-origin policy; if the Bluetooth device allows an origin to read and store data it could allow hostile reading of cross-origin data.

[fabricedesre]

@webprofusion-chrisc Asking the user to sign with its blood solves nothing - of course users will check all checkboxes and tell you they read the information (spoiler: they didn't).

None of that protects against malicious code being served without the legitimate site owner being aware. Unfortunately here the consequences can be dire, like some kind of phishing on steroids.

Maybe an approach similar to https://blog.cloudflare.com/cloudflare-verifies-code-whatsapp-web-serves-users/ could be used to vet code, with Mozilla or some other 3rd party as a trust anchor.

[mrquincle]

I think the list of user persona at https://wiki.mozilla.org/DeveloperExperience/Personas have to be expanded a lot to be able to reflect what people truly think of their users in these issues.

Ah, it's the developer personas, my bad. Can't find the web browser personas though. :-)

[webprofusion-chrisc]

As chrome is obviously a real-world implementation of Web Bluetooth, which real world malicious bluetoothery has taken place? Is there scope for origin-specific blacklists for device/api protection? e.g. via Firefox "Deceptive Content and Dangerous Software Protection"

[fabricedesre]

As chrome is obviously a real-world implementation of Web Bluetooth, which real world malicious bluetoothery has taken place? Is there scope for origin-specific blacklists for device/api protection? e.g. via Firefox "Deceptive Content and Dangerous Software Protection"

Again, the risk is not that a site could be recognized as phishing - this would be covered by the existing Safe Browsing feature shared by blink & gecko. The risk is an innocuous site being turned into a malicious one. Current model in Chrome is close to YOLO. Imagine someone managing to change the code shipped by https://flash.android.com : that could have really bad, concrete consequences like bricking devices. While Google services have likely very good security, this is not the case broadly speaking.

[mrquincle]

If I may contemplate a bit... Still don't know the best place for it.

Suppose, the industry is going the Matter route, and in the end all, all those IoT devices are accessible over IPv6, we would navigate to some kind of URI and be able to interrogate the given device.

This is different from setting up a Web Bluetooth connection, because the device has to serve something to the user. There's no cross-origin resource sharing going on.

If we then go back to our current situation, we might perhaps come up with something that would pass the protective instincts of the devs. Suppose, some bluetooth://XX:XX:XX:XX:XX:XX URI, and all information served to the user coming from the device, would that be okay? Can we create a Bluetooth SIG approved BLE service and characteristic(s) definition(s) which would be able to serve data towards such a user?

We can also allow for a particular mapping from Bluetooth names to MAC addresses, which would involve scanning. However, I would consider first the above without that functionality.

And of course it won't work for all BLE devices in the field right now, but it gives some idea about how a possible roadmap might look like.

[chrysn]

Suppose, some bluetooth://XX:XX:XX:XX:XX:XX URI, [...] Can we create a Bluetooth SIG approved BLE service and characteristic(s) definition(s) which would be able to serve data towards such a user?

Creating protocols atop of BLE is certainly an interesting endeavour, but IMO exceeding what we need here: a way for the device to indicate that yes the device is OK with arbitrary browsers connecting.

If the only concern here is to protect the device, then it should be easy to create a characteristic whose mere presence indicates to the browser that yes indeed this device is OK with Web Bluetooth being talked to it. In a minimum viable version, this would neither need elaborate specification nor Bluetooth SIG registration -- a mere characteristic UUID custom to Mozilla (like a vendor prefix, allowing experimentation before everyone agrees on how to do things right) could get this unstuck.

(In a later version, an application with SIG could be done to get a shorter identifier ... or the characteristic could be defined to contain an Origin pattern that limits interactions to sites trusted by the device, although personally I wouldn't recommend relying on that, because any host with regular application Bluetooth access could ignore this, that's already true for all of Web Bluetooth limitations. But the priority should be to find if and how the Mozilla position here can be changed at all to enable some first applications.)

[adamroach]

@webprofusion-chrisc

As chrome is obviously a real-world implementation of Web Bluetooth, which real world malicious bluetoothery has taken place?

You're basically arguing that Chrome's YOLO approach here must be sound because there haven't been any resultant high-profile consequences. The problem is that your premise is wrong: https://www.wired.com/story/chrome-yubikey-phishing-webusb/

[webprofusion-chrisc]

@adamroach I get it, you're arguing not to provide the feature in case it will be used for nefarious means, I completely understand that. We probably shouldn't have invented computers because bad guys can use them to do bad things. Your premise is that there is no meaningful way that a UI, system, or feature flag could be implemented to prevent evil websites doing bad things via bluetooth (and other serial comms).

My premise (rather than YOLO) is that I suspect Mozilla don't want to implement the feature because they don't see enough value in it to make it happen and security is the best (and simplest) default argument.

Additionally, "my premise" is that if we thought hard enough about it we could have a known list of device IDs, whitelisted firmware write origin domains and firmware patching thumbprint (firmware writes will start with specific bytes, or a given pattern, per device). No need to ship the data in-browser, or as a hardware device characteristic, it could be an API shared by browsers etc, with the Bluetooth SIG as custodian (a "Device Authority" perhaps). I suspect though that any device access at all could be argued as potentially nefarious by anyone with a sufficiently advanced imagination, so then you may need devices listed which are also read only by specific origins.

I see some comments about cross-origin - as far as I know the chrome bluetooth support is not cross origin and cannot currently be iframed etc.

[fabricedesre]

I see some comments about cross-origin - as far as I know the chrome bluetooth support is not cross origin and cannot currently be iframed etc.

No, the cross origin issue is when:

• site1.com uses web bluetooth to change some state on a BT device.
• site2.com uses web bluetooth to read back that state, effectively doing a cross origin read.

[webprofusion-chrisc]

@fabricedesre so the concern there is that you can fingerprint/track the user? You would have needed to allow the bluetooth connection to that device twice in order to select and allow both websites to work equally with the device. If there was a whitelist/blacklist device vs domain API then sites known to fingerprint could be blacklisted as appropriate. There's some administration required there on the list side but I assume it's on par with other phishing detection systems etc. Is there a practical concern that users of top10famouspeopleseendoingstufftheyshouldnt.com will see the bluetooth connection prompt and specifically allow connection to their fitbit etc? If so, I'd suggest a report suspicious website button in the connection prompt.

[nschonni]

I'm guessing most of the Mozilla folks have long since muted this thread that you keep necroposting to, but you might want to check out the CONTRIBUTING.md https://github.com/mozilla/standards-positions/blob/main/CONTRIBUTING.md#discussing-mozillas-position-on-a-web-specification

[webprofusion-chrisc]

Noted. There was a post 7 days ago, so I didn't realize comments were unwelcome, thanks, clearly this is the wrong forum for advocacy but perhaps it should equally not be a forum for opposition (by non-mozilla org members) otherwise you end up with back and forth.

[andrewgoz]

tl;dr - Implement Web Bluetooth/Serial/USB for locally installed web apps (when supported).

I came here looking for information on Firefox support for Web Bluetooth (and Web Serial). I had hoped to find a "coming soon", but have been disappointed to find Mozilla effectively walking away and washing their hands of it. In doing so, Mozilla are leaving the development and direction of these desired technologies solely in the hands of Chromium (Google).

If Mozilla are concerned about the design of these technologies then they HAVE to provide working alternatives. Otherwise, developers such as myself have no option other than to use the already available and working implementation provided by Chromium.

While I understand the concerns relating to these technologies, I disagree with the justifications and reasons Mozilla have used to reach their decision not to implement them. I accept that that decision has been made.

My hope is that if Mozilla ever decide to support PWAs (locally-installed web applications) - another exciting web technology Mozilla are choosing to ignore - that if users have gone to the effort to install a PWA locally, that app should be treated the same as any other locally installed app and that Mozilla reconsider their decision and make technologies such as Bluetooth (and Serial and USB) that may be problematic on the open web, accessible to local apps.

[chrysn]

Given a PWA installation is not going through any user interactions more serious than the popup that was already deemed insufficient here, I doubt that'll be deemed acceptable.

There is, however, an avenue open through add-ons (see https://github.com/mozilla/standards-positions/issues/720) -- that'll need some time, but I reckon that using and feedbacking on the current experiment there is the most promising path toward web bluetooth, web usb and web serial these days.

[andrewgoz]

The user interactions required to install a PWA can be as simple or as complex as the browser developers decide they should be. They are not relevant to this discussion or the intent of my suggestion..

[johnrbnsn]

@chrysn

Given a PWA installation is not going through any user interactions more serious than the popup that was already deemed insufficient here, I doubt that'll be deemed acceptable.

Also, installing from a Native app store (Google Play, Apple Store) is also just a single click, but you can preview permissions. Perhaps Firefox could implement PWAs and explicitly enumerate permissions?

I'm in the same boat as @andrewgoz , I'm stuck with Chromium browsers because of Web Bluetooth. Developing native apps is a dying direction (IMO, at least as far as my development is concerned, no need to learn multiple methods to make apps when everything is moving in web direction) since PWAs were invented. Why develop separately for Windows, Mac, Linux and Mobile when Web can do ~90%?

[dmikester1]

So I'm just curious, how do the Chromium browsers handle Web Bluetooth? Do they just accept these risks and live with them? Or did they find a way to mitigate the risks and implement it?

I really feel like Mozilla is going to have to figure out how to add Web Bluetooth at some point, IMO.

[chrysn]

build some kind of extension to WebRTC to use BT for communication instead of IP

With WebTransport gaining traction, something along these lines might also be implemented for WebTransport instead of WebRTC (with the difference that WebRTC could have used peer-to-peer terminology, whereas a WebTransport executed through BLE would treat the BLE peripheral as a server with an origin distinct from all HTTP based origins – should work just as well).

While I'm still hopeful for a solution along the lines of #720 (revisiting through add-ons), should that avenue fail, resurrecting the WebRTC effort or pivoting it towards WebTransports could be a viable fallback.

[Pandapip1]

Let me preface this by rationalizing why developers would like to use Web at all: it's (intended to be) a cross-platform solution to interact with a device. Not implementing these APIs doesn't reduce the need to interact with peripherals. It just means that developers have to use other technologies. The alternatives are:

1. Installing a potentially malicious executable

...that's it. This is obviously a worse solution than Web, and on some platforms requires fewer prompts. On windows, all you need to do is click a download link, and click on the downloaded file. No permission prompts; full user access.

To the extent that the majority of users understand security practices, it's pretty well known that installing a malicious app can have arbitrarily catastrophic results.

I would not assume this to be the case, unless you can provide data to back up this statement.

Importantly, this means that any action that exposes the user to a risk -- say, turning on a microphone -- must be explained in a way so that the user clearly understands the risk and proactively consents to it. With the microphone example, this is pretty obvious: you can convey in just a few words that the website in question will be able to hear you, and users can extrapolate entirely what that means.

For raw device access as envisioned in a number of APIs (Web USB, Web Bluetooth, Web NFC, and Web MIDI), the risks of exposing those APIs to users cannot be reasonably conveyed. This is pretty much an intractable flaw of allowing raw, non-semantic access to devices regardless of the protocol used to do so.

I agree that any permission prompt must be strongly worded. But I have to disagree with your statement that "the risks of exposing those APIs to users cannot be reasonably conveyed." If this were truly the case, then no application can be allowed to interact with those devices, since you can download an executable with firefox, and then run that executable. Is the risk sufficiently conveyed there?

If Mozilla's position was "it's too challenging to convey the risks of exposing those APIs to users," then I would be more understanding, and the community could have a productive discussion on a prompt. But I'd argue that claiming impossibility is incorrect.

[danburonline]

Especially after the recent news of Apple trying to reduce the functionality of the web platform, it is even more evident that we need to fight for the web and bring in more powerful standards and APIs into all major browser vendors. I highly agree with @Pandapip1's arguments, and I'm curious about what is happening at Mozilla regarding modern web APIs like Web Bluetooth.

[adamroach]

On windows, all you need to do is click a download link, and click on the downloaded file. No permission prompts; full user access.

???

[Pandapip1]

???

Fair enough. I forgot I had that prompt turned off while I was still using windows. That does give me an idea though...

Unironically, would a full-page (as to avoid webpages using phishing tactics to get users to bypass the warning) "Firefox protected your computer" popup with a "Decline" / "more info" adequately convey the severity of the permissions being granted?

[builder555]

If Mozilla's position was "it's too challenging to convey the risks of exposing those APIs to users," then I would be more understanding, and the community could have a productive discussion on a prompt. But I'd argue that claiming impossibility is incorrect.

100% agreed. Yes, it's difficult to implement it safely, doesn't mean it's impossible. If we used the same logic for every step in web development, websites would not have any interactivity or file downloads at all.

Let's figure out how to do it properly and provide users with better functionality than the native apps.