Re: Scanning for beacons w/in a web page

Hi Jeffrey,

the problem area for scanning is active scanning that causes SCAN_REQ to be send. So either you use the LE Privacy feature and with that Resolvable Private Addresses or you use a Non-Resolvable Private Address. When you take a stack like BlueZ for example, these are your only two options. It actually enforces it.

Only when doing passive scanning, using the Identity Address (Public or Static Random) is an acceptable option.

One single drawback of using Resolvable Private Addresses (aka RPAs) is that Bluetooth 4.1 and earlier have issues with Directed Advertising from a peripheral. Only Bluetooth 4.2 solves this be either allowing RPA resolution in the controller or forwarding all Directed Advertising reports to the host stack for resolving.

And if anybody cares, pulling LE addresses out of thin air with something like an Ubertooth is dead simple. That sets you back around 100 USD. No expensive protocol sniffers needed.

Regards

Marcel


> On Jan 14, 2015, at 18:59, Jeffrey Yasskin <jyasskin@google.com> wrote:
> 
> As far as I know, the only security/privacy risk from BLE scanning is
> location tracking
> (https://webbluetoothcg.github.io/web-bluetooth/use-cases.html#risk_unpaired_data_leak).
> If anyone knows of others, please do speak up.
> 
> That does mean that the permissions UI for BLE scanning (when it
> doesn't include communication) will be similar to
> navigator.geolocation. However, some Chrome folks are not entirely
> happy with some aspects of geolocation, so I expect we'll try to avoid
> those mistakes in any new location API. I'll try to find a list of the
> problems so that y'all can think about how to fix them.
> 
> I believe there are plans to coalesce multiple permission requests
> into fewer user prompts. I doubt there would be a unified API, but
> requesting both geolocation and BT scanning in the same turn will
> hopefully only ask the user one question, if we can figure out how to
> word that question. Feel free to suggest detailed UI for this.
> 
> Thanks,
> Jeffrey
> 
> On Wed, Jan 14, 2015 at 5:58 PM, Neftaly Hernandez
> <neftaly.hernandez@gmail.com> wrote:
>> 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.
>> 
> 
>

Received on Monday, 19 January 2015 07:06:59 UTC