Advanced Tor Browser Fingerprinting
jcarlosnorte.com>The most intersting fingerprinting vector I found on Tor Browser is getClientRects. Is strange that reading back from a canvas has been prevented but simply asking the browser javascript API how a specific DOM elements has been drawn on the screen has not been prevented or protected in any way.
This isn't as strange as he makes it sound, it is done to prevent the link color history attack [1]. Most of the other CSS properties aren't allowed on :active or :visited modifiers.
Unless JavaScript is disabled, this arms race is going to continue forever.
Tor users do disable JS. A friend who makes Tor sites told me that it makes web development interesting.
Only because JS has been used as lipstick on the html pig. Html should do a lot more by default, which would make javascript unnecessary in 90% of the case. A few features that should really be html based:
- form/input server-side validation (you would specify a URL as an attribute of the input / form to which what-if data would be posted)
- input auto-complete (same thing, URL in attribute of the input)
- adaptive design (they should rethink CSS with various formats in mind)
With these 3 things alone I think you can pretty much create a fully working JS-free website. You would only need JS if you really need to build a SPA (which should be the exception: online trading platforms, etc).
The fact that now even a blog article is not viewable without JS is a joke.
Is there a way to take another approach of preventing dynamic data from getting back without an explicit opt-in from the user? This will never happen of course on the regular internet, but for hidden services or some other static-page-only-unless-opt-in surely even if fingerprinting information can be obtained, can we block it from getting back to the host?
It seems like a losing battle to me. You'd have to prevent Javascript inserting links into the DOM (it could stick parameters in the URL), inserting images (similar), loading any assets from anywhere programmatically, any AJAX requests, any redirects, setting any cookies... and probably more besides.
...and eventually you'd have some chap like the OP here who will come up with a clever way to exfiltrate information somehow anyway.
Even updating only 100ms at a time, you could statistically infer much smaller intervals if you're able to cross-reference timestamps.
Doesn't tor browser use No Script by default?
Yes, but JavaScript is still enabled by default[1].
[1]: https://www.torproject.org/docs/faq.html.en#TBBJavaScriptEna...
Yeah, but a lot of sites use javascript. Furthermore, I believe most tor users will disable noscript if they find a site that doesn't work.
Lots of ideas, many of which I've had as well, but I am missing conclusions. On the demo page it tells me my CPU benchmark and some scrolling measurements. Great, but how unique was that now? And how are you going to make the data points into a fingerprint? Because next time I scroll, I will totally scroll a millisecond differently.
> Great, but how unique was that now?
He needs to collect data first in order to be able to say something about that. Panoptoclick [1] can report on uniqueness because they have test data from thousands of clients. Perhaps these fingerprints can be added there for the exposure (and because they will work to identify non-tor browsers as well).
> And how are you going to make the data points into a fingerprint?
The two "scrolling deltas" arrays are very different in nature, you could easily drop all the zeros and boil it down to "all 3" or "not all 3". That would give a nonzero contribution to the number of bits of that form an overall fingerprint. Similarly for the CPU benchmark, a phone is not as powerful as a desktop, so a result of "500" on one and "2800" on another are very likely different machines. So bin it to the nearest 500 and you'll have another non-zero contribution. Repeat for client rectangles and so on.
Good points but not even an attempt is being made at using the data. He could have tried his laptop, his phone and his mom's tablet or something, at the very least, though that would probably still be hugely overfitting the data.
Yeah this seems very amateur. Lots of ideas of how to gather information from a user, but no thread about how to connect any of it back together.
The "Uber Cookie" is basically a readout of totally random metadata. The CPU benchmark is substantially different each time I run it.
That's a pretty uncharitable/dismissive summary. The data he showed is far from "totally random"; see my reply to lucb1e above.
I don't believe that any of these will link different Whonix instances on the same host machine. Using Tor browser in the same OS that you use for general work is not secure. Even sharing the same host machine is insecure, where anonymity really matters.
The author is missing the point of the Tor Browser. They don't try to make fingerprinting impossible. They want to make the outcome uniform across all users. See "Strategies for Defense: Randomization versus Uniformity" in their design docs [1].
And (as other said) uniformity is increased when using an anonymous/privacy enhancing operating system like Tails or WHONIX underneath.
[1] https://www.torproject.org/projects/torbrowser/design/#finge...
Most of these are nullified by disabling JavaScript.
Disable javascript. Disable user-agent. Run from VM.
Demo does nothing for me. I'm dubious how repeatable or unique those results are.
Did the author of the article submit his findings to the Tor Project?
I'm sure at least one developer of the Tor project reads hacker news.
EDIT:
Far more interesting is the author's most recent article.... wtf
http://jcarlosnorte.com/security/2016/03/06/hacking-tachogra...
That one should probably have its own thread.
O_o Ouch... indeed...
It does now.
Still, what with responsible disclosure etc.?
It's just a survey without conclusion. The methods aren't unknown.
It is a walk through of some administrative commands. What is being disclosed?
All these have been discussed elsewhere. This is pretty much saying, "hey, TOR doesn't do anything special to prevent people from getting metrics.