Re: [vibration] privacy consideration PING comments

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
>