Re: Scanning for beacons w/in a web page

Hi Krishna,

actually beacon have in theory the ability to track you. If you have control over the link layer in your beacon you can easily track SCAN_REQ from the devices finding you.

Only when the central or observer uses Random Private Addresses or only does passive scanning, the beacon can not track you.

Regards

Marcel


> On Jan 14, 2015, at 12:39, Shingala, Krishna <Krishna.Shingala@nordicsemi.no> wrote:
> 
> Hello all,
> 
> I have been an observer member of the group for some time now. This conversation seems to be like a teaser to the brain leaving lot of open questions to my mind. I am viewing the discussion from a purely Bluetooth and BLE perspective as this is the subject  most familiar subject to me. 
> 
> Before I move to the questions that leave me curious, I would like to provide some context on beacons, class of devices etc.
> 
> Class of device is a classic Bluetooth concept which is not used in Bluetooth Low Energy (Bluetooth Smart) at all. Yes, minor and major numbers of the beacons could be viewed to be  class of devices, but since this is not standardized by the Bluetooth specification, how the beacon data is interpreted is not a standard. As I mention this, I would also like to mention that beacons when advertising have no control over who is receiving the data, viewing it or interpreting it. It's a broadcast packet, and the device that plays the beacon is fully aware of this. It's also aware that could be tracked, its data and device address becoming known it devices with possible malicious intent. And there are ways of improving privacy by changing your address etc. I will not get there as I think it's a little out of scope.
> 
> What I am unable to grasp from the conversations below is who the user below is , whose privacy are we concerned about and where is the approval from the user collected.
> 
> As I already mentioned above, beacons or devices that are advertising are broadcasting and full aware that their identification and data become known to anybody who receives it. Also they have no knowledge of who received the data, or if anybody did receive it at all. Therefore, the user cannot have any approval mechanism on the beacon. So the location tracking and privacy concerns for beacons seem a little out of scope in this group. 
> 
> Coming to which devices or group of devices that one would want to listen to, this has to come from the user. Reason: there are various ways of identifying devices and listening to them. It could be based on device name, based on device address, based on a whitelist, based on type of services supported, etc. And not all information that comes from the user, needs a dialogue box to know what the user needs. Automated scripts, a fine tuned application etc could represent the user and knowing exactly what it is looking for in the scope of its functionality most decisions could already be made.
> 
> Also, " In the first iteration of Web Bluetooth connecting to multiple devices or scanning devices does seem out of scope" surprises me a little, as without being able to scan for devices using web Bluetooth, the connectivity scenario appears rather hard to users of the web Bluetooth.  It nearly mandates having prior knowledge of devices that you would like to communicate to, instead of being able to discover them. 
> 
> Regards,
> Krishna
> 
> -----Original Message-----
> From: Jeffrey Yasskin [mailto:jyasskin@google.com] 
> Sent: 14. januar 2015 21:01
> To: Scott Jenson
> Cc: public-web-bluetooth; Dominic Battre
> Subject: 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 Monday, 19 January 2015 07:06:59 UTC