The paper revisits website fingerprinting (WF) attacks against Tor under realistic, open-world conditions. Instead of relying on idealized lab datasets, the authors collect a large-scale dataset (800k+ traces) from a real guard relay, combined with controlled client traffic.
Their main finding is that WF remains a serious practical threat. In a realistic setting, state-of-the-art attacks still achieve high performance (around 95% precision and 92% recall at a 9% base rate). Notably, a guard relay is a particularly strong vantage point, as it can separate circuits and reduce noise from concurrent browsing.
They also evaluate Tor’s Conflux (traffic splitting). While it reduces attack effectiveness in some cases, a well-positioned guard with a latency advantage can still recover much of the lost accuracy.
Overall, the paper challenges the idea that WF only works in lab conditions and shows that, under certain assumptions, it can be effective against real Tor traffic.
source:
*
”Reality Check for Tor Website Fingerprinting in the Open World”
Mohammadhamed Shadbeh1, Khashayar Khajavi1, and Tao Wang1*
I tested multiple Firefox based browsers on my laptop, observing identical ClientRect fingerprints across all of them due to shared hardware rendering traits. Switching to Tails OS with Tor Browser Bundle (TBB) produced the same ClientRect fingerprint as on the original laptop browsers, confirming that even amnesic, the ClientRect fingerprint is unique to the device.
In summery I tested two laptops with FF based browsers and the ClientRect was fingerprint the same for device despite using Tor Browser in tails.
HP laptop → FF browsers and TB on tails = same fingerprint DBF54A72
Thinkpad laptop → FF browsers and TB on tails = different fingerprint then HP laptop but all shared the same fingerprint of the device ED6C0BC1
I can’t find a reference to “ClientRect” in this paper, can you provide a link to the methodology for the ClientRect fingerprints you have calculated here? I see BrowserLeaks have a ClientRect test here but their test seems to us the JS getClientRects() method which was investigated as a vector & fixed some years ago.
I also note there is an open issue which includes possible ClientRect fingerprint vulnerability (subpixel exposure) here - is this related? If not it looks like a new issue needs to be opened.
I can’t find a reference to “ClientRect” in this paper, can you provide a link to the methodology for the ClientRect fingerprints you have calculated here? I see BrowserLeaks have a ClientRect test here but their test seems to us the JS getClientRects() method which was investigated as a vector & fixed some years ago.
That is what im talking about and I don’t see what you are pointing at as fixed?
I have tried mutiple fingerprinting sites for ClientRects/DOMRects and hashing or method to fingerprint might have been different but the hash was the same (not as browser leaks but website specific).
Idk how this could be addressed via a patch in the browser or a feature added to nocript or uBlock? Chameleon a webextension for Firefox has this is something I have looke at, however I have never tested it personally.
The only other thing that comes to mind would be to see if bwrap in tails could be used to set specific env variables for a entirety of a tails session to launch Tor browser to alter the ClientRects Fingerprint. Last I checked bwrap is already used to start the browser, unless things changed. Downside it wouldn’t protect all TBB users only Tails users, but the inital cost would be cheaper to maintain imo if it works (possible Wayland display conflicts)?