- From: Jason A. Novak <jnovak@apple.com>
- Date: Tue, 24 Apr 2018 14:59:46 -0500
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: public-pointer-events@w3.org, public-privacy@w3.org
> 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:42 UTC