Re: Web Bluetooth security model

Hi Jeffrey,

Thanks for writing this up.  Back at the start of this process, we talked about a CORS-like opt-in for devices. I note that seems to have been ruled out - I remember seeing some discussion about this, but can you summarise was this approach not taken?  Were there technical reasons why devices couldn’t signal that they were Web Bluetooth safe/ authorise origins?  Would it be something possible to consider in the future, or is it infeasible?

Regarding the conclusion:

"Some users’ devices probably will be exploited by malicious websites using Web Bluetooth. We believe the other security benefits will outweigh this.”

If I understand your article - your justification of this statement is something like: currently you have to install native apps to use bluetooth devices. Native apps which have poor security in terms of least privilege. So by allowing websites to access bluetooth devices, you gain the ability to access devices without the necessity of installing potentially insecure/malicious native code (at the risk that you might accidentally break your device if you connect it to a malicious website)? Is that what you meant?

Even with that benefit do you think your UI effectively conveys this risk to users? Well, yes you do, as you state, but one-click away from device compromise seems hard to accept? I can’t think of any other APIs on the web which fall into the same risk profile. (i.e. one wrong user decision results in permanent device compromise). Currently the UI seems to be very similar to existing permission prompts for microphone - any thoughts on how to convey the elevated risk to the user here?

Had you considered discriminating between well-known services and unknown services? IE if the website is requesting a well known service like ‘running_speed_and_cadence’, then the user agent could enforce a whitelist of allowed characteristics as defined by the related service specification e.g. [1]. As opposed to enforcing a blacklist of block services I mean. I’m not sure how closely devices actually adhere to these definitions however. I bought a cheap pedometer to test this idea, but it doesn’t actually use the standard characteristic IDs, making this approach not useful for this particular device. Still, in general, perhaps the user agent could potentially have a fallback ‘scary’ UI for unknown services, and limit the permission request style approach only for devices which properly implement well known bluetooth services. The ability to connect to unknown services might even be a something behind a configuration toggle, to be enabled by users who understand the risk. 

Just some thoughts, let me know what you think.

Regards,
Paul Theriault



[1] https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.service.running_speed_and_cadence.xml

> On 7 Apr 2016, at 1:34 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> 
> Hi all,
> 
> I wrote an article about the security concerns in Web Bluetooth and how we're dealing with them, at https://medium.com/@jyasskin/the-web-bluetooth-security-model-666b4e7eed2 <https://medium.com/@jyasskin/the-web-bluetooth-security-model-666b4e7eed2>. Let me know what you think, if I should improve anything, etc.
> 
> Thanks,
> Jeffrey