Re: Scanning for beacons w/in a web page

The BT_ADDR of a beacon in a museum would almost certainly be random and
rotated very quickly, so is meaningless.

I wouldn't bother surfacing it in the api

On Wed, Jan 14, 2015, 12:01 PM Jeffrey Yasskin <jyasskin@google.com> wrote:

> I agree with various people that access to classes of devices isn't
> what we should be aiming for in the first release of the API. That
> said, it's worth thinking about how it might work so we're ready for
> V2.
>
> As Chris Palmer has said, "We must start with the story about how
> we'll communicate it to users."
>
> 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?
>
> 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.
>
> 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.
>
> If we incorporate permission-to-talk into the request to track
> location, we wind up with several options in the first dialog: "No",
> {limited-location (somehow), full-location} x {ask for each device,
> communicate with any discovered device}.
>
> I definitely want a "watch all devices" permission to be
> heavier-weight for the app's UI and more scary for the user than a
> "connect to one device" permission, to avoid incenting all apps to ask
> for the over-broad permission.
>
> Please point out places I've made mistakes, and keep exploring how
> this should look for users.
>
> Thanks,
> Jeffrey
>
>
> On Tue, Jan 13, 2015 at 1:29 PM, Scott Jenson <scottj@google.com> wrote:
> > I appreciate the privacy reasons why the current BLE approach is to
> connect
> > to a single device and talk only to that device.
> >
> > However, for the physical web project, we'd also like to figure out a
> way to
> > support ''the museum scenario". In this case, all of the exhibits
> broadcast
> > a single URL, the 'museum app' which displays the overall museum
> experience.
> > However, it can also show what exhibits are nearby and give you info as
> you
> > walk through. It could even connect to exhibits and make them
> interactive.
> >
> > The purpose of this example is call out the need for a web page to work
> with
> > a collection of related BLE devices, not just a single one. My concern is
> > that the current one-at-a-time approach that is being taken, while
> secure,
> > is preventing this scenario.
> >
> > Is there a way we could ask the user for an additional permission,
> something
> > like we do for geo-location, so the JS could then scan for a family of
> > beacons?
> >
> > Scott
> >
> >   Scott Jenson   |   Chrome UX  | scottj@google.com
>
>