My work with Whonix is done under a paid contract, and I’m not at liberty to spend the project’s time (and money) to engage too deeply in what kind of feels like online drama. I will briefly note what I think unman is talking about, and how it interacts with kloak, since that might be useful info for Qubes-Whonix users in general.
Qubes already uses virtualization technology to get keyboard and mouse events from dom0 into individual qubes. In particular, there are X11 input drivers that proxy input events into the qubes. These drivers do not allow all aspects of the input devices attached to dom0 to leak into individual qubes, they just get the necessary data from point A to point B in such a way that you get a usable desktop. Some of the data that is not carried across is exact input timing data (from my own testing with vmonaco’s tools, it looks to me like there’s a 60Hz timer somewhere in the driver or some other part of the input timeline that decides when to drive input events into the qube). This greatly reduces the resolution of timing information that attackers can reasonably gather, and does likely provide some protection against deanonymization.
The reason this isn’t ideal on its own is twofold:
- One, the behavior is distinctly different from how non-Qubes-Whonix works. This means that while a Qubes-Whonix user’s input patterns might look the same as other Qubes-Whonix user input patterns, they won’t look like non-Qubes-Whonix input patterns, giving the attacker a bit (as in a literal 1 or 0 bit) of information for fingerprinting the user. One only needs so many bits of fingerprintable information before they can get a reliable fingerprint.
- Two, the behavior doesn’t mask timings entirely. For the keyboard part of things, I can type pretty dang fast, but even I’m not generating 60 keyboard input events per second non-stop or even for short bursts (even when considering that both keydown and keyup events are input events). There is likely still a good amount of data an attacker can gather, even with resolution being decreased. It might not provide them a unique fingerprint all by itself (or maybe it will), but it provides more bits, contributing further to whatever other fingerprintable data they can collect. A similar but not identical scenario applies to mice.
Qubes event buffering is supposed to provide the same kind of obfuscation that kloak provides (it uses the same algorithm under the hood for keyboard input and will eventually do the same for mouse input as well), so the behavior is or will be similar to that of non-Qubes-Whonix, allowing the user to blend in with a bigger user pool. (Probably not 100% identical behavior because of factors like the lower resolution of input devices, different kinds of data being handled, etc., but still very similar.) It also provides better obfuscation than just lowering timing resolution. It’s like the difference between obfuscating an image by scaling it down, and blurring things beyond recognition. Both make things harder to see, but blurring theoretically works better, depending on how you do it.