Re: [vibration] privacy consideration PING comments

To Nick’s question about feedback to Frederick/DAP, I will take this on.

Any last comments, observations, ideas before I send a note?

Christine (PING co-chair)
> On 29 Mar 2016, at 10:35 PM, Lukasz Olejnik (W3C) <lukasz.w3c@gmail.com> wrote:
> 
> 
> 
> 2016-03-27 7:59 GMT+02:00 Nick Doty <npdoty@ischool.berkeley.edu>:
> 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.
> 
> But is this a risk related to Vibration API, or others?
> It is a combined risk, and also the list of potential sensor APIs might be subject to change. Isn't it better to leave it as is proposed (that vibration CAN be used and poses a risk, but with conjunction with other sensors)? So once again, vibration can induce/produce data. But to read it, other sensors need to be used (in case of same device). 
> 
> 
> I'm just wondering what would be the best way to avoid any confusing parts.
> Specifically, fingerprinting is mostly related to the construction of other sensors.
> That said, the word "unexpectedly" also sounds good.
>  
> 
>> 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.
> 
>  I agree. Browsers would have little problems with providing this information. Now: how to incentive them? I am thinking about some transparency/UI note for a while now. 
> 
> 
> 
> ---
> 
> 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?
> 
>  I sent a more detailed PDF to the list, already.
> 
> 
> Cheers,
> Nick

Received on Monday, 11 April 2016 05:58:50 UTC