Re: For horizontal review: WD: Pointer Events Level 2 (Call for Wide Review)

> On Apr 24, 2018, at 2:21 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote:
> 
> On 24/04/2018 16:34, Jason A. Novak wrote:
>> Hi Patrick -
>> Thanks for the email, apologies for the delayed response.  I have a few observations based on my understanding of the specification. Please let me know if I’m misinterpreting the spec.
>> - pointerId appears to be a unique value for the pointer causing the event.  I did not see anything regarding how frequently pointerIds should be reset, and as a result it seems like this could be a long term fingerprinting mechanism.  It would be a good mitigation to specify that user agents should reset these pointerIds on with some frequency and that the values not be predictable (e.g. generated randomly with cryptographically strong randomness).
> 
> To clarify, pointerId is just a number - generally 0, 1, 2, 3, 4, 5, ... - to just disambiguate the different pointers, not a unique id given to each finger/device which persists. Similar in use to, say, the "identifier" value on touch events. But yes, adding a note about how UAs should and should not assign the pointerId may well be worth it.

Thanks for the clarification.  In addition to "adding a note about how UAs should and should not assign the pointerId” it may also be worth it to say that the expectation is that the "pointerId is just a number” to clarify.

> 
>> - There’s a good discussion of the fact that the data exposed in pointer events — the angle or tilt at which a pen input is held, the geometry of the contact surface, and the pressure exerted on the stylus or touch screen — could be used to fingerprint a user but there’s no mention made of mitigations.  It would be a good mitigations to specify that user agents could either not provide precise values by default but rather could round the values provided; or user agents could add some element of jitter to their responses.
> 
> Being inaccurate would, however, negate their usefulness (e.g. in drawing applications). Perhaps the UA could offer this, but as an option only that can be enabled/disabled.

Alternatively, I wonder if there’s a layered approach here: start with rounded / imprecise values and then, on some event / action / engagement with specific part of website, provide more precise values.

> 
>> - Based on my read of the specification, I think that the pointer information plus timing of events could be used by a malicious website to determine if a user was using assistive technologies. This may be a consideration to call out in the Security & Privacy considerations, perhaps in a more general way, e.g. “the use of certain input technologies may reveal sensitive information about the user themselves”
> 
> I thought this was already covered under the "may be used to infer characteristics of a user" part in the S&P considerations.

I think that the S&P considerations is missing that the inferred characteristics may themselves be sensitive.

Thanks,
J

> 
> P
> -- 
> Patrick H. Lauke
> 
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Tuesday, 24 April 2018 20:00:19 UTC