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

Obfuscate mouse pointer motion and click behavior #7

Closed
vmonaco opened this issue Jan 7, 2017 · 8 comments
Closed

Obfuscate mouse pointer motion and click behavior #7

vmonaco opened this issue Jan 7, 2017 · 8 comments

Comments

@vmonaco
Copy link
Owner

vmonaco commented Jan 7, 2017

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

@PowerPress
Copy link

Clever idea

@vmonaco
Copy link
Owner Author

vmonaco commented Aug 5, 2021

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.

@vmonaco
Copy link
Owner Author

vmonaco commented Aug 17, 2021

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.

@HulaHoop0
Copy link

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

@vmonaco
Copy link
Owner Author

vmonaco commented Aug 22, 2021

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

@HulaHoop0
Copy link

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.

https://github.com/luileito/mousefaker

@vmonaco
Copy link
Owner Author

vmonaco commented Sep 20, 2021

@HulaHoop0 and @adrelanos, see #38 which addresses this and some other issues.

@vmonaco
Copy link
Owner Author

vmonaco commented Aug 16, 2023

fixed by #38

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

No branches or pull requests

3 participants