- From: Lukasz Olejnik (W3C) <lukasz.w3c@gmail.com>
- Date: Tue, 8 Mar 2016 11:52:38 +0100
- To: norcie@cdt.org
- Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
- Message-ID: <CAC1M5qrg1Wj6-rydh_40+N1Yz3KDxGgcZ-SYSGADu1TZzS4rwg@mail.gmail.com>
2016-03-03 2:10 GMT+01:00 Greg Norcie <gnorcie@cdt.org>: > 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. > Cross-device (yet, important!) aside, a more reliable risk/tool application of Vibration already exists, and is not far-fetched: fingerprinting other sensors. I came up with the current write-up primarily with this in mind. I think the rest of the "considerations" will be included in respective other sensors (I'm already working on this). > > 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. > > > 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...
Received on Tuesday, 8 March 2016 10:53:07 UTC