Re: [vibration] privacy consideration PING comments

Hi all,

I think one thing we are getting hung up on is that, while the Vibration
API does not, in itself conduct cross device tracking, it can be used to
generate signals that can be received by another device in order to perform
cross device tracking.

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.

As the Center for Democracy and Technology's comments on cross device
tracking to the Federal Trade Commission point out[1], cross device
tracking is very hard for users to give informed consent to, if consent is
obtained at all.

Cross device tracking is also pretty much impossible to opt out of, hence
the Federal Trade Commission requesting comments on the subject.

I know that there has been extensive debate on this subject at W3C, for
example resulting in the Fingerprinting Guidance document [2].

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 spot beaconing. It would be harder to do that with
arbitrary length, user defined patterns. For example, someone could design
a free game that, when a specific user plays it, slightly varies the player
damage vibration to be uniquely identifiable. This is an especially real
threat since many apps have a legitimate need to use the microphone, and
I'm not clear if apps that conduct cross device tracking provide notice
that the microphone may also be used for advertising purposes, not just
say, making voice calls in a game.

I know this seems like a far fetched threat, but internet standards are
used by everyone, including dissidents in places where they may be jailed
or killed if they are de-anonymized.

[1] https://cdt.org/files/2015/10/10.16.15-CDT-Cross-Device-Comments.pdf
[2] https://github.com/w3c/fingerprinting-guidance


/********************************************/
Greg Norcie (norcie@cdt.org)
Staff Technologist
Center for Democracy & Technology
District of Columbia office
(p) 202-637-9800
PGP: http://norcie.com/pgp.txt



*CDT's Annual Dinner (Tech Prom) is April 6, 2016.  Don't miss out!learn
more at https://cdt.org/annual-dinner <https://cdt.org/annual-dinner>*
/*******************************************/

On Sat, Feb 27, 2016 at 1:43 PM, Lukasz Olejnik (W3C) <lukasz.w3c@gmail.com>
wrote:

>
>
>
>
>
>>
>>
>> 6. Applications might want to give indications when vibration is in use.
>>>
>>> Definitely, there SHOULD be an option to indicate it...
>>>
>>
>> I don't think that's right. There is an indication that vibration is in
>> use: the device is *moving*.
>>
>
> It is, if the user is monitoring this device at that very moment, and also
> including your considerations below (thanks!).
>
>
>>
>> So there are a couple of more interesting things:
>>
>> When a foregrounded page has permission for vibration, there should be an
>> indicator. The same applies to a backgrounded page - I think something like
>> the audio playing thing that browsers have started doing would be useful.
>> Indeed, it would copy a familiar iconic paradigm from the world of phones
>> which have had vibrators for more than two decades (and therefore is
>> unlikely to have any IPR issues outstanding).
>>
>> There are plenty of use cases for a backgrounded page having vibrate
>> permission - the simple one being the same as the phone, that it is less
>> obtrusive as a way of requesting attention, and works without actually
>> seeing the device.
>>
>> And finally, of course it is important that all such notifications or
>> status indicators are actually *accessible* - have sufficient contrast, are
>> announced to screen readers / magnifiers, etc. While this is something that
>> browsers should be doing, rather than technically part of the spec, it is
>> worth noting that in the privacy considerations and mitigations, and
>> tracking whether we have acieved the goal. A spec that provides theoretical
>> accessibility but is implemented consistently in a way that discriminates
>> against users with disabilities really isn't good enough.
>>
>
> This is, in essence, somewhat similar to what I was thinking about for
> long now. I do hope to make the PDF public asap, definitely I'll post it to
> the list.
>
> Best
> Lukasz
>
>
>>
>> cheers
>>
>> Chaals
>>
>>
>>
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>>  chaals@yandex-team.ru - - - Find more at http://yandex.com
>>
>
>