Re: Scanning for beacons w/in a web page

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.


>
> 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?


> 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.

Scott