Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web Bluetooth #95

Open
autonome opened this issue Jul 6, 2018 · 7 comments

Comments

@autonome
Copy link

commented Jul 6, 2018

Request for Mozilla Position on an Emerging Web Specification

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 6, 2018

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

This comment has been minimized.

Copy link

commented Jul 9, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Jul 9, 2018

@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

This comment has been minimized.

Copy link

commented Jul 9, 2018

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

This comment has been minimized.

Copy link

commented Jul 10, 2018

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 dbaron added the w3c label Aug 9, 2018

@lidel lidel referenced this issue Dec 6, 2018
@dbaron

This comment has been minimized.

Copy link
Member

commented Dec 17, 2018

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

@reillyeon

This comment has been minimized.

Copy link

commented Dec 17, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.