Re: Scanning for beacons w/in a web page

Hey, another watcher chiming in!

I plan to implement similar functionality as mentioned by Scott Jenson,
specifically for moving targets with unknown coords. I also plan to extend
the navigator.geolocation API in JS, by implementing trilateration against
multiple BLE beacons with precisely-known coords, in order to add several
sf of accuracy to navigator.geolocation.coords. An example would be using
the latter to find a specific bus platform, boarding the bus, using the
prior to detect the bus ID, then looking up the route number & number of
stops remaining.

I feel the permissions UI for BLE.listen should be near-identical to that
of navigator.geolocation. Adding 1 BLE beacon is already enough to
de-anonymize the user -- adding 10 more wouldn't change anything.

Are there any significant security/privacy risks to BLE.listen access,
beyond geo data? Apologies if I've missed an earlier mention.

Cheers,
Neftaly

PS: Possibly outside the scope of this discussion, but the example above
would certainly benefit if it were possible to combine permission requests
for both navigator.geolocation and BLE.listen into a single request.

On 15 January 2015 at 10: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
>
>