Review Web Bluetooth

[jyasskin]

I'd like to request a review of https://webbluetoothcg.github.io/web-bluetooth/.

[dbaron]

Is there a separate explainer document somewhere, or just the intro in the spec?

[jyasskin]

We moved the explainer into the spec's examples. There's a good introduction by @beaufortfrancois at https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web.

[lknik]

Hello,

I hope some of the input I provide might be of help in a the review process.

Thanks.

[scheib]

Thanks for the privacy article, @lknik. Web Bluetooth is a powerful API, and vendors and sites should reason carefully about how to design for it.

I'd like to note that many of these privacy points are delegated by the API to user agents. From an API design point of view, an asynchronous request is made which possibly returns access to a single device. This accommodates differing user agents policies, presentation, and evolution over time. This is well suited to chooser dialog models, similar to file selection. Chrome privacy and security teams have participated in and signed off on the initial design in 2014, and origin trial launch in 2016.

It's also worth noting that privacy and security topics have appeared in public discussions, including @beaufortfrancois’s introduction to Bluetooth, @jyasskin’s post about the security model, use-cases and the specification. Issues are the prefered mechanism to discuss specific topics.

Parts of the article wording & context confused me when reading, and I'm concerned that individuals reading briefly or only looking at parts will be misinformed.

Devices are not paired with remote servers.

Device information is only available when a user agent permits access to that device. Chrome's model is to use a chooser model, requiring a user to interact with the page, find and select a device in a list, and then initiate pairing.

Information is not available at all times to web apps.

Some of those points are mentioned in some sections, but elsewhere are omitted and presumed access is similar to native applications, which can pair to all devices, at any time, and communicate without any security with any external server. Web Bluetooth is more restrictive.

[lknik]

Vincent,

Thanks for your feedback. I am happy to hear it.

My intention was to look at the API from a high-level point of view.
That’s why I also mention Data Protection regulation side; I did consult people with expertise in this matter, of course.

You are correct, many aspects of Web Bluetooth are delegated to the user agent (e.g. how to expose it, how to show identifiers), the developer/site (e.g. how to handle the data), as well as the user (e.g. how to pick devices). All the parties should understand the sensitive nature of the API. So I agree that vendors and sites need to consider carefully their designs. That’s why I am suggesting to advise performing web privacy assessment, as is in the case of Generic Sensors API.

I wanted to make sure to note that any use of the API requires user permission. I understand this. I did read the specification and I did test Chrome implementation on desktop and Android. In my opinion, spec might not currently cover all the issues. However, I think I made it clear enough that user permissions are required for Web Bluetooth. That said, I did not feel like I need to emphasize the need for permissions in all paragraphs of my note, since I made that point several times... And you are correct, devices are not paired with remote servers directly. It’s just JavaScript on a site, so technically… Some data could be, potentially, sent to a server.

I do link to the very good security model writeup by Jeffrey, I also realize the mechanism went through Chrome security team vetting (as it's stated in Jeffrey's article). Similar processes take place at other security and privacy teams (e.g. Firefox). The reason I focused on Chrome is that I’m not aware of any other major implementation other than Chrome. I would be happy if you could point me to a different implementation, if possible.

I also acknowledge the analysis you point to, where the API is regarded to as “privacy-preserving”. Although I don’t know what this expression means in that context, it's not described, so I did not see where is the privacy-preserving mechanism.

In general, I also agree it would be good to expand privacy considerations. I’m happy to work on the issues in my spare time.

[scheib]

The specification requires user agents to inform users of access details (see first paragraph of the Security & privacy section).

I've created an issue for your privacy assessment suggestion.

[travisleithead]

Discussed at Tokyo F2F.

Reviewed the spec, looking for any potential immediate concerns given upcoming intents to ship.

We noticed:

To help ensure that only the entity the user approved for access actually has access, this specification requires that only secure contexts can access Bluetooth devices (requestDevice).

Has the group considered limiting web Bluetooth access to the top-level document only? (In addition to secure contexts)

[plinss]

Regarding the GATT blacklist:

1. why a new file format? Have you considered using an existing format with established parsing rules, e.g. json?
2. the term "blacklist" is offensive to some. Consider an alternative term?

[hadleybeeman]

We talked at length about the fingerprinting potential here and the difference between a user granting explicit consent ("Pair with this device") and them understanding how they're increasing their fingerprinting surface area. It's clear that you have taken on board the written work in this area (including the Unsanctioned Tracking Finding and the Fingerprinting Guidance document), so we'd mostly say you've done what we would hope in light of the features you're trying to add to the web platform. It's a tricky area though, since increasing the fingerprinting surface area (a bit) seems inevitable; I'd additionally be interested in seeing the results of the privacy assessment when you've completed it.

Also, I'd also be curious to know more about any long-term plans you have to maintain the GATT blacklist (who decides what's included, how they decide, etc.).

[scheib]

@plinss would you request the source of offense to consider posting to some of the top google results on 'blacklist alternatives', 'blacklist racist' e.g.
http://ux.stackexchange.com/questions/14812/alternative-term-to-blacklist-and-whitelist
http://english.stackexchange.com/questions/51088/alternative-term-to-blacklist-and-whitelist
https://www.quora.com/Is-the-term-blacklist-racist

[scheib]

Thank you for review!

Re: Limiting access to the top-level document only?:
We have an outstanding issue to address that. Note that sandbox, permission-delegation-api and to some degree feature-policy are relevant. For the time being Chromium disallows cross origin iframes.

Re: GATT blacklist file formats, why not JSON?
We desired comments & minimal parsing complexity. I've added this to the spec's companion rationale document.

Re: Blacklist term may be offensive.
I've filed WebBluetoothCG/web-bluetooth#327 to use a descriptive term.

Re: Blacklist policy?
We have an initial policy documented.

Re: Fingerprinting
The API minimizes the increase to passive fingerprinting, but we have experimentally drafted navigator.bluetooth.getAvailability (fingerprinting impact discussed in spec). When users actively pair devices they select data sources comparable to that of local file resources. The benefit and exposure are intrinsically linked.