Using Mouse Movements To Track You On The Tor Network

[HardOCP News]

How could something like this even work? Could you imagine what your mousing fingerprint looks like? Porn, porn, e-mail, forums, porn, porn, BOOBIES...more porn.


Jose Carlos Norte, a security researcher based in Barcelona, has devised a technique in which users can be tracked and their online activities watched -- even across the Tor network. "Even worse, it could be possible to identify the user if the fingerprint is the same in [the] Tor browser and in the normal browser used to browse [the] Internet," Norte says. "It is very important for the Tor browser to prevent any attempt on fingerprinting the user."

 

[Gman1979]

So change your mouse DPI and move the keyboard to a ps/2 adapter when using Tor. Check.

 

[Sonicks]

So change your mouse DPI and move the keyboard to a ps/2 adapter when using Tor. Check.

I don't know how that'll prevent this JavaScript from reading your mouse inputs.

Better yet, use a touchscreen and that'll remove any possibility of this mouse fingerprinting business.

 

[Gigus Fire]

since javascript is client side based, you could just treat it as a ad and block it with any sort of ad blocker easily.
This whole thing of being able to identify people through TOR is just kind of silly. If i read this right, he's trying to identify anyone who uses a particular webpage that employs his code.

 

[Gman1979]

I don't know how that'll prevent this JavaScript from reading your mouse inputs.

Better yet, use a touchscreen and that'll remove any possibility of this mouse fingerprinting business.

If you change you mouse DPI, you'll naturally change the way you have to move your mouse to get the cursor to the same point. If you move the keyboard to a ps/2 port, there's enough inaccuracy in the ps/2 signal to make fingerprinting keystroke counts and such less accurate.

What I mentioned was aimed more at breaking the connection between matching the fingerprint of the Tor Browser use with the normal use of a browser not routing through Tor.

 

[Wolf-R1]

since javascript is client side based, you could just treat it as a ad and block it with any sort of ad blocker easily.
This whole thing of being able to identify people through TOR is just kind of silly. If i read this right, he's trying to identify anyone who uses a particular webpage that employs his code.

For now this is his code. It's proof of concept that can be coerced upon other sites or even injected via advertising.

 

[Gigus Fire]

For now this is his code. It's proof of concept that can be coerced upon other sites or even injected via advertising.

Just a another reason to block all ads.
Fairly sure his toolset that he's using to detect mouse usage and sending that information back can easily be blocked as well.

 

[MRAB54]

If you are enabling javascript on your Tor browser, you're doing it wrong.

 

[extide]

If you move the keyboard to a ps/2 port, there's enough inaccuracy in the ps/2 signal to make fingerprinting keystroke counts and such less accurate.

LOL WUT? No... there is not any "inaccuracies" in a PS/2 signal.. that's not how it works...

 

[dgz]

LOL WUT? No... there is not any "inaccuracies" in a PS/2 signal.. that's not how it works...

PS/2 has a bit lower default polling rate which could be skewing the results? I am not sure what he means.

Anyway, using Tor with JS enables is asking for trouble. Browsing with JS enabled is no joke but with Tor it's on a whole new level.

 

[Gman1979]

PS/2 has a bit lower default polling rate which could be skewing the results? I am not sure what he means.

Anyway, using Tor with JS enables is asking for trouble. Browsing with JS enabled is no joke but with Tor it's on a whole new level.

It was the clock skew in the PS/2 bus itself along with the lower polling rate. And as mentioned before, I meant the comment in reference to switching up some simple stuff would make matching the Tor/non Tor fingerprints more difficult.

 

[extide]

There is no "Clock Skew" in the PS/2 protocol (the kb/mouse actually generates the clock signal), maybe you were thinking of jitter, but that doesn't really apply here. The mouse/keyboard sends data to the host immediately, the host does not poll for data from the kb/mouse.

 

[LightningCrash]

There is no "Clock Skew" in the PS/2 protocol (the kb/mouse actually generates the clock signal), maybe you were thinking of jitter, but that doesn't really apply here. The mouse/keyboard sends data to the host immediately, the host does not poll for data from the kb/mouse.

Did you game on PS2 mice? It was pretty common to set the host's sampling to 200Hz.

 

[extide]

Did you game on PS2 mice? It was pretty common to set the host's sampling to 200Hz.

That's just a windows thing, though, PS/2 mice send the data basically immediately, which triggers an interrupt on the CPU, and the data is saved to a register or location in memory, the sample rate you set in windows is the rate at which windows samples that memory location, and updates the "screen", and by screen I mean the buffer, not the actual display.

Yeah, I gamed on PS/2 mice, heck I gamed on serial mice before that

 

[rezerekted]

If I'm using TOR I use it via TAILS, they have tools in place to stop fingerprinting.

 

[LightningCrash]

That's just a windows thing, though, PS/2 mice send the data basically immediately, which triggers an interrupt on the CPU, and the data is saved to a register or location in memory, the sample rate you set in windows is the rate at which windows samples that memory location, and updates the "screen", and by screen I mean the buffer, not the actual display.
Yeah, I gamed on PS/2 mice, heck I gamed on serial mice before that

The host will actually tell the PS/2 mouse what report rate to use ("Set Sample Rate" command 0xF3).
PS/2 mice send data immediately in the Stream Mode (0xEA) at the sampling rate defined by the host. If there is no movement, no samples.
However there is also a less used Remote Mode (0xF0) where the mouse updates its counters and waits on the host. The host then polls movement data from the mouse.

 

[extide]

The host will actually tell the PS/2 mouse what report rate to use ("Set Sample Rate" command 0xF3).
PS/2 mice send data immediately in the Stream Mode (0xEA) at the sampling rate defined by the host. If there is no movement, no samples.
However there is also a less used Remote Mode (0xF0) where the mouse updates its counters and waits on the host. The host then polls movement data from the mouse.

That's interesting, I was kinda wondering why windows worked the way it did and that makes sense that that option would be sending the sample rate to the mouse.