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

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:07 UTC