Re: Scanning for beacons w/in a web page

Hi Jeffrey,

your example with the lightbulb is not working here. If you buy a BT lightbulb, then you certainly want to enter a trust relationship with it and have the communication with it encrypted. Authentication and encryption works on point-to-point basis with Bluetooth (LE and classic). And I assume you do not want to give access to your lights to your neighbor only because he/she is in proximity.

When it comes to your personal devices, then you better enforce a 1:1 user confirmed transaction and not just try to collect data from devices that are just around. And there are LE devices on the market that ignore any kind of authentication and encryption. Sadly these come in form of heart rate monitors, pulse oximeters, scalers and other devices. It is a pretty bad example on how everybody can get access to personal medical data with these home medical devices.

There is also an issue with power consumption. It is easy to keep the controller scanning for known devices. If it has to look into every single advertising packet to see if it matches some criteria, it will consume more power than just looking for known devices.

Regards

Marcel


> On Jan 14, 2015, at 13:59, Jeffrey Yasskin <jyasskin@google.com> wrote:
> 
> On Wed, Jan 14, 2015 at 1:01 PM, Scott Jenson <scottj@google.com> wrote:
>> On Wed, Jan 14, 2015 at 12:00 PM, Jeffrey Yasskin <jyasskin@google.com>
>> wrote:
>>> 
>>> The main privacy risk from connecting-to-every-device-in-a-class
>>> appears to be the location-tracking aspect, so we need to ask users
>>> whether the site can track their location using surrounding bluetooth
>>> devices. Can we time- or space-box the grant? i.e. can/should we let
>>> users make it auto-revoke when they leave the museum?
>>> 
>>> How does an application infer the location of a beacon? I assume the
>>> application uses the beacon's BT_ADDR or a unique ID in the
>>> advertising data, and then looks that up in a database. Dominic Battre
>>> recently objected to the statement in
>>> 
>>> https://webbluetoothcg.github.io/web-bluetooth/#identifiers-for-remote-bluetooth-devices
>>> that the UA may expose the BT_ADDR to web pages, so I'd like him to
>>> comment on the user warning we'd need to allow that for a class of
>>> devices. Scott, do you have any suggestions here?
>> 
>> 
>> There are many ways to determine location, the simplest is to have each
>> beacon have a unique ID and whenever you connect to it, you look it up.
>> However, that risk is just as real with only a single beacon. Claiming that
>> multiple beacons is somehow more risky than a single one is splitting hairs.
> 
> It sounds from Scott Remnant that the unique ID would always be in the
> advertising data, so to provide "location", we'll have to include the
> advertising data in the Device that we expose.
> 
> I think I want to split the hair between exposing a single device that
> the user chose, and exposing a set of devices or all devices. Giving
> access to one location per click seems significantly less dangerous
> than giving access to all locations with one click, so we should
> mitigate all-locations access somehow.
> 
>>> Permission to _talk to_ the device could come with the
>>> location-tracking, or it could be separate. I'm not sure how to
>>> explain either, really: how do we identify a class of devices that's
>>> distinct from "all devices", and how do we get a name for that class
>>> that users will understand correctly? Scott, this one's for you too.
>> 
>> 
>> As discussed above, you can't separate the two. While it's nearly impossible
>> that your heart rate monitor can give away your location, it is possible if
>> you connect to a parking meter.
>> 
>> However, we do have the geo-location API in the web today, we have already
>> covered the concern that a web api may give away your location. The
>> difference here is that 99% of the time, a BLE device won't be able to give
>> away your location so how can we responsibly warn the user without scare
>> mongering?
> 
> The use cases I've seen for set-of-device access seem like location
> use cases anyway. The museum certainly is. What's an example that's
> not?
> 
> I do agree that we don't want to over-warn, since that'll make users
> ignore warnings in general.
> 
>>> If we keep permission-to-talk separate from location-tracking, we can
>>> do it something like this: you'd get a notification that this website
>>> can communicate with this device (possibly on the website itself),
>>> you'd click the notification, and it would pop up a 3-way permission
>>> dialog: "No", "Yes this device", and "Yes this class of devices". Then
>>> users control how much access the site gets. On the other hand, this
>>> is an extra dialog, and we don't want to interrupt the user
>>> unnecessarily.
>> 
>> 
>> A couple of points here. Again, you can't enforce location vs not-location.
>> Also 'class of devices' is a fairly sweeping term and is likely hard to
>> define. This is actually my biggest concern and what I wanted to focus on.
>> It would be very hard to enforce a single class of device and most likely
>> you'd have to offer generic scanning capabilities (because anything less
>> would be dishonest) This could be offered on a limited basis (possibly) but
>> much like geo-location, would have to be a prompted user request.
> 
> I'm definitely worried about making users grant access to every
> bluetooth device in the world if they want to use their museum's site,
> or, worse, their single BT lightbulb. Please think about how to build
> a UI for this that resists attacks from only-semi-trustworthy sites.
> 
> Thanks,
> Jeffrey

Received on Monday, 19 January 2015 07:06:59 UTC