Re: Scanning for beacons w/in a web page

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 Wednesday, 14 January 2015 22:00:24 UTC