@Patrick is this code stable and maintainable as it currently exists?
i.e. do we see us having the resources to maintain it for the longhaul?
Yes.
In context of kloak-alike functionality inside Qubes:
kloak-alike functionality might become available and enabled by default for Qubes-Whonix-Workstation users in Qubes R4.3.
Related ticket:
Related pull request:
Optional feature request:
- unlikely
- not crucial since this will be enabled by default in Qubes anyhow
(kloak is already default in non-Qubes for a long time.)
Was merged.
The future of kloak-alike functionality in Qubes R4.3 and above is bright.
Could not be reproduced and original reporter disappeared.
It does, though depending on the speed at which your pointing device sends scroll events it may or may not be useful. Scroll events are treated identically to key press/release events and mouse button clicks, in that they are scheduled for release at a semi-random future time on an event-by-event basis. If your pointing device generates only a few scroll events during normal use, and you aren’t scrolling at a breakneck speed, kloak should be able to be somewhat effective at masking the exact timing between scroll events, but if your device sends a flood of fine-grained scroll events (or you scroll at extreme speeds like some pointing devices are designed to allow), it will probably not be particularly effective in those instances.
It might be possible to combine scroll events in a similar way to how we combine mouse movement events in Whonix 18’s kloak (yet to be released), in order to circumvent the issues of event flooding. That could possibly provide anonymity benefits. More research will be needed to determine if this is possible and how useful it is.
The research isn’t really theoretical half so much as it is practical - is it actually possible to meld together scroll events such that if you generate two events in quick succession, you can turn them into a single event that scrolls as much as both of the events combined? Furthermore, does that provide the ability to actually mask differences in both scrolling device users and the scrolling devices themselves, or is the behavior of users and devices distinct enough to show through the jitter insertion mechanism kloak uses at its core? Both of those are unanswered questions at the moment.
Kloak’s README.md has a good bit of info about how it works under the hood, but the tl;dr: is that all input devices generate a series of events that the kernel then sends to userspace through various mechanisms. Usually what happens is a display server (such as X11 or labwc) will read the input events, and translate those into what you perceive as characters being typed on the screen, scrolling, clicking, and pointer motion. Kloak works by inserting itself between the display server and the input events coming from the kernel, and then applies manipulations to those events to make it harder to profile the user causing the events to be generated.
The original implementation of kloak was rather simple - all it did was grab input events, and schedule them for release at a semi-random time in the future, ensuring that each event was scheduled to be released between the release time of the last queued event, and a certain maximum limit. This ensured that events were seen by userspace in the correct order, but without the timing between the events being visible. For keyboards this worked great, but for mice and touchpads it was a problem because pointing devices generate lots of input events to move the pointer. This would flood the queue, make kloak’s scheduling mechanism always schedule an event for release at the maximum future time (thus getting rid of jitter), and kloak was unable to hide the pointer’s path. To work around this, we recently rewrote kloak so that consecutive mouse movement events are merged together, thus allowing jitter to still be present and hiding the pointer’s path (though it will still always end up in the right location).
Now though we have the question of scrolling. There are actually multiple different kinds of scrolling events, because there are multiple kinds of scrolling devices - there are mice with mouse wheels that have distinct “clicks” in them (most cheap mice are in this category), there are mice with smooth, high-resolution scroll wheels, there are mice with high-resolution, weighted, magnet-assisted scroll wheels that allow the user to scroll extremely fast for prolonged periods of time, there are touchpads with two-finger scrolling, and there are some laptops with a trackpoint that allow you to hold a particular button and then push the trackpoint up or down to scroll. As such, some pointing devices send one scroll event every so often (similar to mouse clicks), some of them send a brief flood of events (similar to mouse movement), and some of them send a long flood of events. The current way of masking those events is pretty much the same thing we do with keyboard keys, so for pointing devices that send a flood of events, this probably doesn’t help much.
The question then is how to not only make all users of these devices look the same, but also make all the different devices themselves look the same? This is a hard problem to solve, because even if you merge together consecutive scroll events in order to allow jitter insertion and mask the true number of events, you still have the fact that some scroll events are going to show up in short bursts characteristic of “clicky” mouse wheels, some scroll events are going to show up in longer bursts characteristic of touchpad scrolling, and some scroll events are going to show up in very long bursts characteristic of someone using a high-end Logitech or similar device and trying to scroll at breakneck speeds.
Possibly. I wouldn’t expect mice to send multiple scroll events for a single “tick”, but certainly there are profile-able things here. On the bright side, there seems to be some merging of events already happening since kloak doesn’t use the high-resolution scroll event API, but for some devices (particularly touchpads and some mice) that probably isn’t enough.
Perhaps reaching out to Vinnie and asking for his input on these interesting research questions (when he has time) could guide the next stage of defenses?