Attack summary

When a Tor user switches tabs (to another Tor tab or to his clearnet browser) his sessions can be linked from the mouse entry-exit points.

This attack has two variants:

Attack 1: Tor Browser plus normal browser

Users can have their Tor Browser activity linked to their non-Tor IP by:

• moving the mouse from Tor Browser to another non-Tor browser (and vice versa)
• switching said browsers with hotkeys

Attack 2: only Tor Browser, with multiple tabs opened

There's another vulnerability involving the use of only Tor Browser.

Tor Browser has separate exit nodes (and IPs) for each tab. However, switching tabs with hotkeys creates a unique pattern, meaning all opened websites (despite being opened on separate tabs) can be attributed to the same user.

Test results

I tested it on my PC:

• It is very accurate in Tor-to-normal, but less so due to speed. It can be further improved by projecting the mouse track on the border of the browser.

• The match is extremely accurate when using CTR TAB in Tor (that is, only one browser). Note that both fingerprints are drawn on top of each other (3rd graph), since they are completely identical.

This has to be tested with data from users that don't know of the attack (to prevent mouse movement biases).
Also, it has to be independently verified by other researchers, although I doubt there's anything that makes the attack infeasible.

TorProject had been notified prior to release

Update to their documentation:
"Discourage more running a browser in parallel to Tor Browser"

Preconditions

1. JavaScript must be enabled on both browsers.
2. Websites must collect mouse x,y,time data.
3. Websites must share that data with each other.

Big tech is already sharing data for anti-fraud purposes, etc. GIFTCT Whether it's x,y,time I don't know.

Also, Google Tag Manager (used by ~18 million websites) or similar 3rd parties could be gathering such data (haven't confirmed it yet). If such data is indeed gathered in one place, then whoever has access to it can use this attack.

Metrics analysed

The following metrics are compared between users when they are within a specified time difference.

Mouse movement close to entry and exit locations:

• x, y, time
• angle
• speed
• acceleration

Due to time granulation in Tor at 100ms speed and acceleration can't be calculated in a traditional way. A way around this is deducing the elapsed time based on density of registered points. The storage of x-y values seems to be following the speed pattern of my mouse movements.

However, delays due to other simultaneous browser events perhaps will affect it.

Tor CTR TAB metrics

Only the location and the time-frame is used, since probably most users stop moving their mouse before switching tab.

Exit and entry point distances on both browsers

Measuring the entry-exit distance between points in a browser and comparing it with other browsers results in the creation of unique fingerprints.

Firstly, a center of all matching points is created (for each browser). Then the matching users' centers are taken as a common point and the distance of each matching point is compared.

Pixels are like chessboard boxes

Slow mouse movement results erroneously in exit/entry angles of 45.00000, 90.00000 or 0.00000 degrees. Or other "standard" values for slightly higher speeds.

That's because x,y are "quantized" and during slow speeds adjacent points are noted. Meaning we can't take just the last 2 points before browser exit to calculate the angle at slow speeds.

So, more accurate methods are used.

Increasing accuracy

To reduce false positives smaller thresholds can be used for all metrics.

Also, the distance comparison of critical points (that is, suspected exit or entry points) can be calculated while taking into account speed and acceleration.

Bug - Crashes

It sometimes crashes (when specific mouse-tracks are stored in a browser tab session).
Simply restart the program and open new tabs.

I'll fix it in the future.

Software limitations

This is simply a proof of concept.

I haven't taken into account all scenarios, e.g.:

• user moving one of the browsers
• user trying to deceive the server by manipulating data
• interrupted data transfer
• changing IP during session
• assignment of existing IP to new user
• accuracy (false positives and false negatives)

The above could make the attacks a bit harder.
But a more sophisticated software would overcome them.

Investigate later

• Can single-browser single-tab metrics be used to extract patterns related to a user's UI layout (location of shortcuts on desktop, etc.)?