- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Tue, 24 Apr 2018 23:21:41 +0100
- To: "Jason A. Novak" <jnovak@apple.com>
- Cc: public-pointer-events@w3.org, public-privacy@w3.org
I've proposed the following changes. Comments welcome. P On 24/04/2018 20:59, Jason A. Novak wrote: > > >> 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 > > -- 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 22:22:10 UTC