Open kklash opened 3 years ago
Indeed. I copy-paste the last paragraph of the our paper's discussion section:
Finally, we acknowledge a limitation of our adversarial noise technique. The W3C consortium introduced the concept of "trusted events" to help developers differentiate between events triggered by a genuine user interaction and those triggered programmatically, e.g., by a 3rd party script. Our Chrome extension adds mouse cursor distortions programmatically via JavaScript, therefore those events are considered untrusted, although currently none of the major mouse tracking companies filter out untrusted DOM events. It is a matter of time, however, for companies to catch up and update their tracking technology. Therefore, in future work we will release a program that runs at the Operating System level and thus can trigger mouse events that are seen as trusted by the web browser.
https://luis.leiva.name/web/docs/papers/mouseprivacy-chiir2021-preprint.pdf
Ah thank you! I wasn't able to find a free copy of the paper previously, will give it a read now :+1:
I understand this tool is primarily for mitigation of mouse profiling rather than comprehensive prevention of it. However it seems like it would be extremely easy for a malicious web-page to filter out events dispatched by
fakeMove
.The web page need only check if
event.isTrusted
before counting themousemove
event towards analytics. Even if you figure out how to fakeisTrusted
, you'd still have to fake a number of other factors which each allow a web page to differentiate between simulated and real mouse movements.Perhaps instead, the original
isTrusted
mousemove
event should be stopped from propagating, and only fake moves dispatched to downstream listeners. But one would need a fool-proof way to prevent calling applications from getting upstream of mousefaker's listener in the event capture/bubbling sequence, which is quite easy to do:I can't find any way to prevent that simple listener logic from differentiating real mouse movements from the simulated ones.
Instead of faking events, one could proxy or overwrite the XY coordinate properties of the authentic
mousemove
event, so that the true coordinates are obscured in such a way as to be irrecoverable. However, this would suffer from the same problem as the previous solution: If the web-page can intercept the event before we can overwrite those values, then we're back to square one.