Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure predicted events only use input from the current partition #518

Closed
jyasskin opened this issue Sep 5, 2024 · 4 comments · Fixed by #527
Closed

Ensure predicted events only use input from the current partition #518

jyasskin opened this issue Sep 5, 2024 · 4 comments · Fixed by #527

Comments

@jyasskin
Copy link
Member

jyasskin commented Sep 5, 2024

From https://www.w3.org/TR/2024/WD-pointerevents3-20240318/#predicted-events:

Some user agents have built-in algorithms which, after a series of confirmed pointer movements, can make a prediction (based on past points, and the speed/trajectory of the movement) what the position of future pointer movements may be.

If the prediction is based on the user's behavior on other sites, or on the same site across storage clearing, it could let sites join identities they shouldn't be able to join. Would it be possible to restrict the possible source data for generating predictions to the current partition?

@patrickhlauke
Copy link
Member

patrickhlauke commented Sep 5, 2024

the spec itself does not define nor mandate what algorithms (on the underlying platform OS, or the user agent) are used - but unless I'm mistaken, the prediction is purely based on the previous movement leading up to the pointer event itself, so does a speculative "if the user continues on the same trajectory at the same speed, the next likely position they'll reach is this".

maybe the "past points" wording was not clear enough - I'll see if this can be explained a bit better.

@mustaqahmed
Copy link
Member

Thanks @patrickhlauke, you posted something very similar to what I have drafted from a slightly different perspective. So posting anyway:


Does it help that the spec mentions two inputs to the prediction mechanism both of which are already "mostly exposed" to the Web?

... can make a prediction (based on past points, and the speed/trajectory of the movement) ...

The past points are known to the site already. The speed/trajectory is mostly a function of the known rate of input events but I can see that the (unknown) shape of the stroke could have some role in the prediction too. The shape may not be visible to the hardware or the browser predicting the next points, and even if it is visible, it seems to have a lighter role than the other already-known inputs.

@jyasskin
Copy link
Member Author

jyasskin commented Sep 5, 2024

One kind of prediction I'd be worried about would be if the OS or browser learns from the full history of a user's behavior that their pen acceleration curve usually maxes out at 34.52px/s and has a particular logistic shape, and so predicts that shape of acceleration every time the user starts drawing on a page. It'll still be based on "past points", but it'll incorporate too many of them and so be identifying too quickly.

@patrickhlauke
Copy link
Member

patrickhlauke commented Nov 6, 2024

@jyasskin I've had an initial stab at clarifying this, but noting that the spec itself does not actually define the algorithms that UAs will use. #527

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants