Re: [vibration] privacy consideration PING comments

Great, thanks. I'll then work as a connector and bake out the final
considerations. Then I'll proceed with a preliminary ambient light sensors
work (mostly based on my report).

But my modest take is that a lot if "unexpected" here. I am still inclined
to treat Vibration per se as something providing "input" (for other sensors
e.g. accelerometers, maybe microphones - although this would likely be
quite difficult to do it reliably), and technically this is mostly
out-of-bands even.

LO

2016-04-11 7:57 GMT+02:00 Christine Runnegar <runnegar@isoc.org>:

> 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
>
>