-
Notifications
You must be signed in to change notification settings - Fork 35
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
Obfuscate mouse pointer motion and click behavior #7
Comments
Clever idea |
Device fingerprinting can be performed with high accuracy using DOM event timestamps: 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: Clone and run locally or try it live here: 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:
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 |
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.
[1] https://arxiv.org/pdf/1609.07612.pdf
The text was updated successfully, but these errors were encountered: