W3C home > Mailing lists > Public > public-web-bluetooth@w3.org > April 2016

Re: Web Bluetooth security model

From: Von Dentz, Luiz <luiz.von.dentz@intel.com>
Date: Thu, 7 Apr 2016 15:26:46 +0300
Message-ID: <CACumGOK9gQS_uFh72puTM3Azj5JFQ872eW+OMd1dZQ-cEKz3Cw@mail.gmail.com>
To: Paul Theriault <ptheriault@mozilla.com>
Cc: Jeffrey Yasskin <jyasskin@google.com>, public-web-bluetooth <public-web-bluetooth@w3.org>
Hi Paul,

On Thu, Apr 7, 2016 at 7:40 AM, Paul Theriault <ptheriault@mozilla.com> wrote:
> 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.

I don't think it would be a good idea to whitelist standard profiles,
if that is what you are suggesting, as you experienced a lot of times
peripherals will come up with their own services and that doesn't mean
it is not working as intended.

> 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.
> Let me know what you think, if I should improve anything, etc.
> Thanks,
> Jeffrey
Received on Thursday, 7 April 2016 12:27:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:54 UTC