kloak currently helps with obfuscating both keystrokes and mouse movements. The way kloak works is by recording evdev events as they are received from the input devices, then releasing them to the OS with jitter added to the timing. This is great for keystroke and mouse click events, but it works really poorly for mouse movement obfuscation for two reasons:
- Mouse movements generate an onslaught of evdev events. I get around 370 events per second from my MX Master 3S mouse. This quickly floods the queue and results in almost all events being delayed for the maximum amount of time allowed by the set kloak delay, getting rid of most of the jitter.
- Mouse event timing isn’t the only important thing to keep in mind when trying to anonymize mouse movements, the pattern of movements also needs to be obfuscated. Adding jitter to the timing won’t help with this at all.
Properly fixing this will likely require some algorithm that merges multiple mouse movement events into single events, thus resulting in the mouse pointer “teleporting” to the location the user tried to move it to, rather than the pointer moving smoothly. This however comes with its own unique problem - it will only work seamlessly in virtual machines. If you try to squish together mouse movement events and teleport the pointer on physical hardware, that erratic pointer movement will be very visible to the end-user and impair use of the machine. This isn’t a problem for Whonix per se since it (almost?) always runs in VMs, but for kloak in general it’s a problem.
There is a tool that gets around some of these problems called mouser (warning: have not audited code), which provides a virtual mouse cursor that the user can control the real cursor with. A left-click results in the real cursor teleporting to the clicked location, then clicking. Right click has similar behavior but with right-clicking. A middle click results in the real pointer moving but not clicking anything. This neatly resolves both of the above problems, but introduces some problems of its own:
- Middle-clicking is now impossible. The middle mouse button does exist for a reason, applications like Blender use it heavily.
- The user now has to operate the mouse cursor itself, rather than just operating the computer and using the mouse as a tool for that. There’s significant increased cognitive load in using the mouse in this scenario, which may be undesirable.
- Not all applications play nice with the virtual cursor technique used by mouser, as documented in the known issues. In particular, the cursor sometimes gets hidden, sometimes doesn’t show up in the right spots, and doesn’t work at all under Wayland.
- What even is the expected behavior when clicking and dragging? I can’t really think of an anonymity-preserving way to make click-and-drag work in this situation that isn’t awkward (combined left-mouse-button hold with middle clicking?)
Let’s assume we do go with a solution that involves combining mouse movement events in kloak. What algorithm should be used here? One technique might be to detect when a mouse movement event is coming immediately after another mouse movement event, and merge together the events as appropriate. This would probably be relatively simple to implement depending on the specifics of the math involved.