Re: Scanning for beacons w/in a web page

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

Received on Wednesday, 14 January 2015 20:01:23 UTC