Re: Vibration API privacy considerations

Indeed, I think we need to make a general statement that anything that can be initiated or modulated that is perceptible away from the device can be, and probably will be, used as a beacon. We may need a note on beaconing.

We’ve had this with Bluetooth and WiFi (passive beaconing, where the MAC address is detected); we’ve had it with audio (‘active’ beaconing, where the device is made to emit distinct inaudible sound), and it could be done with vibration to some extent, though the reach of perceptibility of vibration is not as good as either of those two.

Beaconing, in turn, needs exploration. Possible uses include linking a set of devices to a single user; identifying the location of a device; singling out a device from a set of candidates. Maybe we need a note on beaconing and the problems and opportunities it raises.

I am reminded of ‘Bump’, an app that allowed you to transfer information from one device to another by simply bumping them together. I assume it worked by noting the only two devices in the set of devices actively running the app, that detected a sharp ‘bump’ in their accelerometers at the same time. Sometime one doesn’t need to convey much in the ‘beacon’ if timing can be precise.

In terms of detecting devices, imagine a store that provides free wifi but monitors traffic. It notices the people browsing their own website over their free wifi and re-writes the HTML so that (a) the prices shown online match the in-store ones and (b) causes the devices to ‘beacon’ so that they can work out which user this is, precisely (what department they are in, are they near a sales associate or cash desk, and so on). (They could maybe also do this by WiFi triangulation.)

Is the vibration API accessible to service workers or in ways that it can be called when I am not actively browsing that site?

> On Feb 19, 2016, at 8:41 , Greg Norcie <gnorcie@cdt.org> wrote:
> 
> CDT's comments to the FTC on cross device tracking may help explain why any standard that allows a unique pattern to be emitted can be used for tracking:
> 
> https://cdt.org/insight/comments-on-cross-device-tracking-to-the-ftc/
> 
> 
> /********************************************/
> 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
> /*******************************************/
> 
> On Thu, Feb 18, 2016 at 12:11 PM, Lukasz Olejnik (W3C) <lukasz.w3c@gmail.com> wrote:
> Hello
> 
> 2016-02-16 21:30 GMT+01:00 Joseph Lorenzo Hall <joe@cdt.org>:
> Are those two things or just one? That is, is this section claiming:
> 1) it is possible to fingerprint a device through the Vibration API by
> requesting information that could be used to uniquely identify a
> device by characterizing "tiny imperfections during their
> manufacturing"; and 2) it is possible for an external observer to
> identify someone close to them in physical reality ("meat space") by
> causing the user to visit a specific web page that then uses the
> Vibration API to vibrate the device (and the external observer
> observes this and connects a particular web session with a particular
> device)?
> 
> 
> It is not suggested that Vibration API allows fingerprinting on its own. 
> 
> The only thing I intended to suggest was that in presence of other sensors - capable of performing the readouts - Vibration API provides the input.
> So yes, in conjunction with other sensors. This is specified there.
> 
> That said, ability of creating patterns with vibration is another concern.
> 
> 
> Regards
> Lukasz
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Friday, 19 February 2016 17:19:42 UTC