Obfuscate mouse pointer motion and click behavior
vmonaco opened this issue · comments
Right now, kloak only works for obfuscating keystrokes. Anonymizing mouse pointer motion and click behavior, without affecting user experience too much, requires some further research.
The same technique (of randomly sampling the delay and adjusting distribution bounds to ensure event order, described in [1]) could be applied to mouse click events (and other I/O peripherals with buttons, like joysticks or controllers).
There's more difficulty in obfuscating the "shape" features of the pointer motion. This has to do with that the mouse motion being a continuous rather than discrete process.
A solution might have to be some combination of UI design and obfuscation. For example, grab the mouse device and draw the true pointer location in real time, while the obfuscated pointer (which lags behind the true pointer) quickly follows in a random path, eventually stopping where the true pointer is located. The obfuscated pointer events would be what is written to the uinput device, while kloak draws the true pointer location on screen.
Clever idea
Device fingerprinting can be performed with high accuracy using DOM event timestamps:
https://github.com/vmonaco/vmonaco.github.io/blob/master/papers/Device%20Fingerprinting%20with%20Peripheral%20Timestamps.pdf
This approach is more general than for just keyboard events. I actually think mouse events are more at risk for this type of attack.
CC @adrelanos . Introducing a delay to mouse events isn't ideal but it probably doesn't have to be much. Just enough to throw off phase estimation, 8-16ms is probably enough.
I started working on this and realized we need some way to measure how well a defense works for mousemove and click events. I put together a demo of just the PSD estimates that runs entirely client side:
https://github.com/vmonaco/device-fingerprinting
Clone and run locally or try it live here:
https://vmonaco.github.io/device-fingerprinting/
Even though that demo only does PSD estimates and not instantaneous phase, obfuscating the PSD itself would be probably sufficient. You'll basically want to look at the shape of the PSD and fundamental frequency estimate before/after using any defense and make sure they look different. Removing the fundamental frequency makes estimating instantaneous phase much harder.
Great stuff. Tested the online site and it works. Tried to run it locally from the cloned repo but events aren't detected. Would compiling a user contributed dataset help further with obfuscating mouse behavior?
Can I suggest releasing the fingerprinting code as AGPL (if you're comfy with strong copyleft) just to make sure no bio-metric services hoover up the code, add more advanced tracking techniques and then deny researchers the ability to discover and counter their tracking?
Also found some older code for mouse wheel tracking you may find interesting:
http://jcarlosnorte.com/assets/fingerprint/
http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprinting.html
Thanks a lot for those links, I came across Jose's work a while back and then forgot where those demos were.
AGPL seems like a good license for that, thanks for the suggestion. I'll add it.
I think there's enough public data already available to backtest a mouse defense. And I just realized, that demo probably won't work if you just open the local file in a browser because of the web worker (at least in chrome, see https://stackoverflow.com/questions/6811398/html5-web-workers-work-in-firefox-4-but-not-in-chrome-12-0-742-122/6823683#6823683). Another way to run it locally is to start a web server from the same directory:
$ python -m http.server
Then navigate to http://localhost:8000
Also found this browser addon code for mitigation, though I'm not qualified to know how effective it is. May provide inspiration for implementing a system level defense in kloak. The paper is behind an ACM paywall.
@HulaHoop0 and @adrelanos, see #38 which addresses this and some other issues.
fixed by #38