Updating privacy considerations - recovery of two identifiers

[lknik]

Hello,

After carefully analyzing the spec, it seems it could be possible to actually recover the max patterns list and max duration length values. While at this moment there is no actual apparent risk since the current implementers appear to limit the max pattern length to 128 and max duration to 10 seconds, it is not clear what could be implementing the spec in the future.

For example, an algorithm monitors DeviceOrientation events and causes a single vibration, increasing the duration while tracking the time when device is vibrating. At some point, the time would stop to ascend, indicating the platform's max duration. This is an identifier.

We could update the privacy considerations to reflect this, i.e.

"It is theoretically possible to recover the values of max length and max duration using external detection sensors. In some scenarios, those values could act as identifiers."

Once again, this concerns a situation where in some case, e.g. Web of Things devices, those values would start to be different. In any case, this would make the spec future proof.

[dontcallmedom]

I'm not convinced that maxPattern and maxDuration are particularly sensitive information; their fingerprinting surface is very limited (if not null given that it's most likely equivalent to the one exposed by the UA string), and given that you have to vibrate the device, their detection would not be exactly discrete either.

(If this concerns a future usage of that API in a "Web of Things" context, then I think that aspect should be addressed in that context)

[lknik]

Well, since I also think most of the browser vendors will choose identical values of those parameters. This is why I also used the wording "theoretical". It's just something we can document, as those parameters are not (otherwise) possible to obtain with via any standard API.

Also of note, someone could possibly do with short vibrations (few ms), which are not that easily observable to the user (possibly depending on the hardware, too - i.e. "unexpected"). I tested that, also.

On the other hand, I'm unsure if it makes sense to include a remark on WoT in the Vibration API spec. Perhaps there would be a place in that in the note I am thinking of coming up with. We'll need to discuss the shape of such possible note.

[anssiko]

I labeled this v2. Emerging APIs such as WebVR might require more control over vibration (see e.g.: https://lists.w3.org/Archives/Public/public-webapps/2016AprJun/0052.html), which suggests there might be interest for v2.

[lknik]

Hello Anssi,

Good point. I suggest we ultimately should add this remark (possibly after rethinking). And I'm looking forward to privacy analysis of Vibration v2, after (possibly?) hearing Gamepad team's requests.

Best Lukasz

Ps. Need to explore options for obtaining GamepadAPI-like devices for my work ;-)

2016-08-23 12:30 GMT+01:00 Anssi Kostiainen notifications@github.com:

I labeled this v2. Emerging APIs such as WebVR might require more control over vibration (see e.g.: https://lists.w3.org/Archives/ Public/public-webapps/2016AprJun/0052.html), which suggests there might be interest for v2.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/vibration/issues/12#issuecomment-241702900, or mute the thread https://github.com/notifications/unsubscribe-auth/ANTjbTO_HRZBnBs_IC2hrA8en4JgmvnDks5qitnFgaJpZM4JJjlg .

[himorin]

@lknik @anssiko close this issue per update by https://github.com/w3c/vibration/pull/46 ?

[lknik]

@lknik @anssiko close this issue per update by #46 ?

Hello, While Vibration API remains a possible out of bands emitter (and hey, I find it interesting how my early privacy analyses seem to still cross-pollinate further reviews :) ), this issue is for sure to be closed because the configuration is preset. By the way, it’s a good move!