Re: [vibration] privacy consideration PING comments

just in case it got lost, I’ll repeat my plea to keep different terms for:

fingerprinting:  the ability to identify a device or user, based on observable characteristics;

beaconing: the ability to link two or more devices, or detect the presence of a device, based on emission and reception of signals (sometimes, but not always, signals that are imperceptible to humans)


> On Mar 26, 2016, at 22:59 , Nick Doty <npdoty@ischool.berkeley.edu> wrote:
> 
> This topic was discussed on this week's PING teleconference and I wanted to make a couple notes on the mailing list of issues that came up that might not already be in this or related threads.
> 
>> On Mar 8, 2016, at 2:52 AM, Lukasz Olejnik (W3C) <lukasz.w3c@gmail.com> wrote:
>> 
>> Beaconing, device fingerprinting, cross device tracking, these all describe the same threat model: Device A generates some sort of unique signal, which is picked up by device B and used to link the two devices.
>> 
>> Fingerprinting does not need to concern a device B.
> 
> One additional threat might be cross-origin or cross-browser tracking on a single device. So in addition to fingerprinting via finding idiosyncracies in a particular accelerometer (with vibration as the trigger), it might also be possible for different browsing contexts on a single device to communicate in unexpected ways, by noticing accelerometer changes at the same moment that a vibration is called. That is, the user might not want example.com in a private browsing window and example.com in a regular browsing window to know that she is the same user, but a vibration called by one origin and accelerometer changes noted in another window could allow for that correlation. This allows for cross-origin correlation and also cross-browser correlation, on the same device.
> 
> Maybe there are essentially different levels here: device fingerprinting (single origin on multiple visits), device fingerprinting (across origins), cross-origin communication (on-device), cross-browser communication (on-device), cross-device communication, beaconing (to other people in the room). The consideration should be to note that the Vibration API, in combination with microphone or accelerometer access, could enable all of these capabilities unexpectedly.
> 
>> My logic was that if we limit the Vibration API to some very specific calls (like a dot, and a dash), it would be easier to audit use of the API. Yes, a developer may have to repeatedly call: dot() dash() dot() dash() dot() dash(), but an unusual amount of calls to the API could be a signal auditors use to 
>> 
>> While I'm unsure if developers would like that ;-) - I certainly encourage putting thought into transparency recommendations, and privacy UIs. Many good things can be done by browser vendors...
> 
> +1 that auditing here would be very useful, if difficult. I'm not sure the API would need to be reduced to dot(), dash() to enable that auditing; the user agent can log exactly what pattern is being used in the millisecond separation model and could theoretically decide to warn the particularly concerned user (or log for followup by an auditor) if it sees something particularly elaborate. I'm not sure separating the vibration calls into different methods will make that logging any different.
> 
> ---
> 
> As a process matter, it sounds like we're hoping to hear back from Lukasz about some further elaboration/research on the fingerprinting concern. Once that happens, is someone in charge of getting back to Frederick/DAP with the combined results of this thread?
> 
> Cheers,
> Nick

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 29 March 2016 17:04:03 UTC