Better mouse obfuscation

[arraybolt3]

Somewhat by accident, we’ve ended up with a new anonymity enhancement in kloak. We now use an “event batching” technique for scroll events similar to what we previously used for mouse movement events. The main reason this was done was actually unrelated to providing better anonymity; Tor Browser and Firefox both had almost entirely non-functional scrolling with kloak because we weren’t sending “axis_discrete” scroll events alongside the normal “axis” scroll events. The quick-and-easy way of adding these kinds of events would have also resulted in usability bugs, and solving those usability bugs required doing about 90% of the work needed to do anonymity-improving event batching, so I decided to do the whole job since it wasn’t much extra effort.

The basic idea behind the enhancement is two-fold: make all scroll devices look like the most common type of scroll device (specifically, “clicky” mouse wheels), and merge together high-resolution and quickly sent scroll events into less-precise, less-frequent scroll events.

• We keep track of the distance the user has scrolled in any particular direction, waiting until the user has scrolled a certain amount in one direction to actually send a scroll event.
• Once the needed scroll distance has accumulated in kloak, we create a scroll event that looks like a mouse wheel “click”, and schedule it for release the same way we schedule all other input events.
• If the user scrolls very quickly and ends up with a large scroll distance in the accumulator, instead of sending a large number of individual scroll events, we combine the scroll events together so that applications see one big scroll event instead of several smaller ones.

While this is supposed to enhance anonymity, it’s worth noting that users can do things that will still allow them to be fingerprinted even with these protections. Just like kloak isn’t able to entirely hide your typing speed or mouse movement speed, it’s also not able to entirely hide your scrolling speed. If you have a mouse with a free-spinning inertial mouse wheel like a Logitech MX Master device, and you attempt to scroll at full speed with it, applications will see a continuous stream of very large scroll events, which will look very different from someone using a true “clicky” mouse wheel. With typing and mouse movement this isn’t so bad, since most people probably don’t have massively different mouse movement speeds, and people can only type so fast, but with scroll speed this is exacerbated because laptop two-finger scrolling and inertial mouse wheels can both scroll much faster than “clicky” mouse wheels ever could. Thus, users should exercise caution when it comes to how they scroll, especially how fast they scroll, when using apps that may attempt to fingerprint them.

Like the enhanced mouse movement anonymization features, the new scrolling anonymization features will be first available in Whonix 18. At the time of this writing the new enhancements aren’t in trixie-developers yet, but they likely will be soon.

[crabprogrammer]

I would like some clarification on what qubes event buffering does.
But lets start with clearly, in easy language, define what exactly gets fingerprinted in mouse movement.
There are two categories of mouse movement data that gets fingerprinted:

1. timing: acceleration, tremors which create jitter, velocity.
2. Path: the path of the movement. You can visualize this as a line. It has curvature, tremots (jitter), smoothness.

The software used to defeat mouse fingerprinting has to defeat both of the above categories. If it only defeats the timing category, the fingerprint of the path pattern will still be unique and the random timing won’t protect you. And vice versa, if it only protects against path fingerprinting, the timing data can still be fingerprinted.

I hope I have misunderstood the information on what qubes event buffering does because it sounds like it only attempts to randomize the timing category. That is not enough and if that is all it does, I don’t think it’s worth using qubes event buffering. Because it’s not possible to willingly change your path without software. Because even if you move the mouse in a different path, perhaps zigzag instead of a upwards curve, the tremors would still be the same and unique to you.

And then you’ve also said this:
“Because pointing devices flood the queue with events when the pointer is moved, this usually results in almost all of the events involved in a pointer movement being delayed for exactly the maximum delay time. This removes almost all anonymizing jitter and may allow an adversary to fingerprint and identify the user via mouse movements even if Kloak or event buffering is being used.” from http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Kloak#Qubes_Event_Buffering

So this means qubes event buffer and kloak doesn’t even create random timing. What it really does is add a fixed offset which is easily fingerprinted by looking at the relative timing difference between timings. That is hard to understand, so I will show what I mean.

This example will use 3 mouse movement events simplified.

First without Kloak or Qubes event buffering:
Event A: 100 ms (this is the time it took to move the cursor from a previous mouse movement event).
Event B: 200 ms (200ms from A to B)
Event C: 50 ms.
The simplest way to create a fingeprintable pattern is the pattern: [100, 200, 59]
This fingerprinting works when the user doesn’t use qubes event buffering.

With Kloak or Qubes event buffering:
But with qubes event buffer (which in practice adds a fixed offset (the maximum delay)) +50ms offset in this example:
Event A: 150 ms, Event B: 250 ms, Event C: 100 ms.
If the adversary knows what the offset is, then they can just subtract the offset and get the same pattern as without qubes event buffering.
But if they don’t know the offset, there is still a way:
150 ms - 250 ms = 100 ms
250 ms - 100 ms = 150 ms
Pattern: [100, 150]

The same pattern will be for the example without Kloak:
100 ms - 200 ms = 100 ms
200 ms - 50 ms = 150 ms
pattern: [100, 150].

The mouse fingerprinting doesn’t need to know what the offset is. It just has to be a fixed offset. It doesn’t work if the timing is random like it is meant to be in theory.

I haven’t seen this written elsewhere so I hope this is helpful to better understand.

I really hope I am misunderstanding everything about Kloak and Qubes event buffering because this is really bad if it’s as I understand it.

And if it is as I understand it, it’s also very disappointing that you are prioritizing UX more than anonmity. That is hard to make sense of when Whonix is about anonymity.

I think the other software mentioned in this topic such as by Anon381 seems much better. Yes, it has a weakness for dragging but that is a very small weakness compared to all the weaknesses of Kloak.

The concept of teleporting the cursor is really the best in practice because it solves both the timing and path fingerprinting threats.

I think we should reconsider using it instead of Kloak in Whonix. Because anonmity loves company. It just wouldn’t be so effective to use Anon381’s tool if there are only a few users who use it. To get a bigger user base for a tool, Whonix need to prioritize Anon381’s tool instead of Kloak.

But I don’t know what happens with qubes event buffering then. Can Anon381’s tool be used in Qubes OS instead of qubes even buffering?

[arraybolt3]

There are a lot of questions here, I think most of them are addressed here:

Keystroke and Mouse Deanonymization

That being said, I will try to answer these specific questions briefly:

• Kloak currently hides both the timing and the path of mouse movements, if you’re using non-Qubes-Whonix 18 or higher. It goes very far out of its way to avoid the fixed offset issue you mention. Previous versions of Kloak only attempted to hide mouse movement timing, and had the flooding issue that resulted in fixed offsets, but this was fixed in Whonix 18.
• Qubes event buffering currently only attempts to hide the timing of mouse movements, and has the flooding issue resulting in fixed offsets. This is planned to be fixed, but there are many development tasks that are higher priority at the moment. See this and the stack of tasks above it:

ToDo for Developers

• The “Mouser” tool that you reference is an interesting alternate solution, but it would be possibly very difficult to implement in Qubes because of how window stacking works under Qubes (windows from multiple VMs have to interact with each other, but each VM can only receive events for its own windows). Even if it would work on non-Qubes-Whonix, it may not work on Qubes-Whonix.
• This is just a personal opinion, but I think the additional cognitive overhead needed for dragging and hovering is high enough that it would ultimately damage anonymity by driving users to turn the feature off so they could work normally. As you say, anonymity loves company, so if a lot of users turn the feature off, we lose company and thus damage anonymity. The current, mouse-movement-anonymizing version of Kloak in non-Qubes-Whonix 18 is already hard enough to use that some of our users are quite frustrated with it. Making it any worse is likely not in anyone’s best interest.

[crabprogrammer]

Thanks, your reply cleared up a lot of things.
There is still one big elephant in the room.

But let me start bu saying I know you have done a lot of work, it’s appreciated. Take what I say as constructive feedback. I also apologize if you think I’m asking things that have been answered already but I did read the whole current topic Better mouse obfuscation and the wiki page on qubes event buffering http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Kloak#Qubes_Event_Buffering. And on that wiki page it says “may allow an adversary to fingerprint and identify the user via mouse movements even if Kloak or event buffering is being used.” but from what you’ve told me now, it seems that wiki section may be out dated because it sounds like Kloak doesn’t have that problem, it’s just Qubes event buffering which has it. And lastly, this is also very advanced topic so I hope we can be tolerant if someone has a bit difficult to put all the pieces together.

Is qubes event buffering worth using if it only takes care of the timing problem? (if it gets fixed)
Because the pathing can still be fingerprinted. And it’s not something that can be solved without software to create random jitter noise to blend with our own jitter caused by tremors.
It seems like qubes event buffering just causes unnecessary overheard/lag without actually protecting against mouse movement fingerprinting.

But Kloak seems to work great in Whonix from your description.
This creates a strange problem. Because qubes os users who want privacy, have to buy a second computer without qubes os which they use for anonymous web browsing. That seems very ridiculous and thoughts appear such as if it’s even worth using Qubes OS when it doesn’t have anonymous web browsing. Because it’s not enough to just have qubes-whonix if it doesn’t have Kloak, and qubes event buffering isn’t enough. Protection against mouse fingerprinting is too important to achieve anonymity when browsing the web. So anyone who values anonymity, should not use qubes os.

The TODO link you gave only linked to a github issue which basically says that the TODO is to fully implement Kloak into Qubes OS. But there’s no description of the challenges or any sub-goals towards that goal.

About Mouser, I agree that its weakness means it can’t be used for all websites if you plan on for example using the cursor to select text to copy. So users would need to decide if they want to be anonymous or not for each individual website by toggling it on/off. I know this is not optimal mainstream UX but apart from dragging and hovering, Mouser actually protects against mouse fingerprinting, but qubes event buffering doesn’t. It makes more sense to use a tool that works in practice, and does it what it’s supposed to do.

Also, there are in some cases some workarounds the user of Mouser could do if they want to copy some text on a webpage. They would need to adapt to this weakness by, for example “select all” or manually typing the text instead of copying it if it’s a small text. Could also get the source for the page. There are more ways, it’s just examples on the kind of thinking needed to deal with the weakness of Mouser.

But currently, the only option which qubes os users have, is to uninstall qubes os and install whonix or another linux distro and then install whonix in a VM, so they can use Kloak instead of qubes event buffering.

[arraybolt3]

In short, both Kloak and Qubes event buffering also cloak keyboard input patterns in a way that works, so yes, they are worth using. It is known that the mouse fingerprinting situation under Qubes is less than ideal and there are not plans to prioritize making it better any sooner than the TODO list indicates.