Security: require devices to opt-in

[johnmellor]

Most existing Bluetooth devices don't expect untrusted websites to be interacting with them. The use cases document mentions that "a mechanism similar to the GPU Blacklist may be appropriate". However there is many orders of magnitude more variety in bluetooth devices than there is in GPUs, so it seems infeasible to blacklist vulnerable devices. Instead, it might be wise to require devices to opt in to being accessible via the web API.

On the other hand, native apps on all major OSes already get unrestricted access to bluetooth with barely any prompting. So maybe we're already doomed :-(

[jyasskin]

I've asked our security team to look at this question (@metromoxie), but until they do:

1. It's currently possible for a website to inline-install a Chrome App with two clicks, and then that app gets full access to any nearby device that speaks the services it asks for. With this proposed API, the same two clicks give similar access, but only to one device.
2. The fact that the Chrome App lives in a Store doesn't help much since the store doesn't have access to the potentially-vulnerable devices.
3. To some extent, we should treat the navigation through the requestDevice dialog as expressing trust in the website. Of course, trust can be mistaken.
4. I believe that reads are unlikely to be vulnerable. Let me know if you disagree with this. If I'm right, a possible middle ground would be to constrain only writes. We could define a new Descriptor similar to the Characteristic Presentation Format Descriptor, but with a more precise schema of the allowed values. Then we'd require that this Descriptor be present and match the attempted write before we'd send it to the device. Since that Descriptor isn't currently standardized and so isn't in use by any current devices, this would effectively be an opt-in.

I'd rather avoid (4) since it limits the current usefulness of the API, but I think it's plausible.

[jyasskin]

I wrote https://medium.com/@jyasskin/the-web-bluetooth-security-model-666b4e7eed2 to analyze the security risks with the new API. Not everyone has been convinced that this is safe enough to expose to the web, but we seem to have general agreement from Chrome's security team that our defenses are enough.