|
|
Log in / Subscribe / Register

New vectors for fingerprinting Tor Browser

By Nathan Willis
March 9, 2016

Browser fingerprinting enables a web site to differentiate between anonymous visitors, capturing enough minor differences between visiting browsers to uniquely associate each browser with a specific profile. The technique lets sites track individual users across multiple visits and IP addresses, which is problematic enough for any user who is concerned about privacy. But fingerprinting that can identify users coming through the Tor anonymizing network is even more worrisome. Recently, research uncovered several new fingerprinting vectors that work against Tor Browser—and, by extension, most other web browsers. How significant the vectors are in practical terms, however, remains to be seen.

Jose Carlos Norte posted his findings at his blog on March 6. In the post, Norte describes five experiments he has run attempting to collect entropy (in the information-theory sense) data about visiting web browsers, which helps uniquely identify users. The tests were conducted with Tor Browser on multiple machines, although under controlled conditions.

Prints

All of the tests involve JavaScript (which is enabled by default in Tor Browser). The first test captures the deltas sent by the mouse wheel's scroll events: a physical wheel will send a "3" for every delta, while a trackpad will send a variable stream of deltas that depends on the characteristics of the trackpad and the user's action.

The second test is related; it captures the scroll speed of the mouse, which Norte notes is linked to both the operating system's settings and the capabilities of the hardware. The third test is the speed of the mouse's movement which, as with the scroll speed, depends at least in part on OS and hardware factors.

The fourth test is a CPU benchmark. A CPU-intensive script is run in a Web Worker and the execution time recorded as the result. Norte pointed out in the post that Tor Browser already implements an anti-fingerprinting countermeasure by limiting the clock resolution of JavaScript's Date.getTime() function to 100ms. He was able to bypass this limitation by incrementing a counter once every millisecond with WindowTimers.setInterval(), though, and speculated that there are other ways to work around the clock-resolution problem.

The fifth test is akin to the canvas fingerprinting techniques already explored in existing research. To recap, canvas fingerprinting involves drawing a known shape into an HTML5 <canvas> element, then hashing the pixels of the resulting image. A number of factors result in small differences in how the shape is rendered, meaning considerable entropy can be collected about the specific machine in use.

Norte's test also exploits differences in the on-screen contents rendered by the browser, but it does not require any special element to be drawn onto the screen. Rather, the script queries the Element.getClientRects() function, which returns the precise pixel positions of each CSS border box for a given page element. That function can be called on any page element; Norte's tests call it on a text block, the size and position of which vary with window size, font configuration, and other factors.

Impact

The blog post links to a test page that users can access to see what data their browsers generate. Norte himself reports data only for two machines, which is far from enough to be meaningful. In particular, it is easy to see for oneself that the mouse-speed, scroll-speed, and CPU-benchmark numbers can vary considerably on a single machine between two test runs.

It might be possible to collect multiple samples across time and compute an average, but the value of doing so is likely to be small. Too many external factors can affect the CPU benchmark, and a fingerprinting technique needs to be reproducible to track users. The scrolling behavior recorded is, at the fundamental level, a measurement of user activity, not of the browser.

On the other hand, there is certainly some entropy to be found in determining whether the visiting machine uses a trackpad or a mouse with a physical scroll wheel. By far the most interesting test, though, is the getClientRects() fingerprint. Tor Browser now takes steps to alert the user whenever a script tries to read data from a <canvas> element, specifically so that users can block canvas-fingerprinting attempts.

It is hard to say how big the entropy contribution of either test is in the wild. The entropy numbers published by projects like the Electronic Frontier Foundation (EFF)'s Panopticlick count on millions of users contributing to the test data; the proportion of users that produce the same result on a particular measurement is what determines the entropy reported in Panopticlick's results. So a scroll-wheel delta of "3" (corresponding to any mouse with a physical wheel) does not contribute much, while the deltas sent by a truly strange trackpad would contribute noticeably more.

Various fingerprinting measurements can also overlap with each other, which reduces the entropy contributed by each metric. For instance, there was a bug opened against Tor Browser in 2015 that speculated on several additional JavaScript-based techniques to detect information about the attached pointing device—which may already be in use by real-world browser fingerprinters. It is not clear that Norte's techniques contribute additional information not already detectable through these other means. For its part, Panopticlick does not yet record pointer-related information about browsers except for whether or not the browser has touchscreen support. The techniques used to detect touchscreen support (such as the MouseEvent.mozInputSource property) may also overlap with Norte's tests for many devices.

Norte posted about his findings on the Tor Browser bug-discussion list. The limitations of the Date.getTime() countermeasure were already a known issue, it seems, but a new bug was opened to discuss the getClientRects() issue. Tor's George Kadianakis noted in the bug report that Tor Browser already takes some steps to sanitize the JavaScript functions used in Norte's test; the packages now bundle in a set of default fonts (so variations in system fonts should not impact how an element is rendered) and the browser rounds off the dimensions it reports for window sizes to the nearest 200 pixels.

Naturally, finding and circumventing fingerprinting vectors in Tor Browser is an ongoing process. The project will, no doubt, implement fixes for the open issues as soon as it is able. If further investigation indicates that the getClientRects() vector is indeed a significant entropy source, that could require more subtle adjustments, since getClientRects() has legitimate uses.

For those users running other browsers, however, Norte's findings are simply more bullet points in the already lengthy list of ways that a web site can track people across sessions. Purists will point out that these fingerprinting vectors, like so many others, require JavaScript to be enabled. But, as an increasing percentage of web sites rely on JavaScript for even basic functionality, Tor Browser's approach—which tries to balance practical function with a measure of anonymity—looks more and more like the only way to avoid being fingerprinted.


to post comments

New vectors for fingerprinting Tor Browser

Posted Mar 10, 2016 9:53 UTC (Thu) by paulj (subscriber, #341) [Link] (3 responses)

tl;dr: JavaScript is a massive and un-pluggable side-channel for extracting system-identifying information.

New vectors for fingerprinting Tor Browser

Posted Mar 10, 2016 15:37 UTC (Thu) by flussence (guest, #85566) [Link] (2 responses)

And it's infinitely worse than Java or Flash due to how deeply it's ingrained into the same process used to load potential attacker sites.

I wouldn't use any browser that, out of the box, isn't designed to allow the user to make an informed choice to *whitelist* all of those when they're really necessary; it's literally a remote arbitrary code execution vector. The Tor project seems to not be quite as paranoid.

New vectors for fingerprinting Tor Browser

Posted Mar 10, 2016 17:12 UTC (Thu) by roblucid (guest, #48964) [Link] (1 responses)

Well I've used noscript for years, but it requires someone with some technical ability to get sites working, it can be quite disruptive to say booking air line tickets or shopping to have it on. Therefore, I don't turn it on for family/friends I set up; they'll just think "Web's bust" and may be try a less secure browser.

New vectors for fingerprinting Tor Browser

Posted Mar 10, 2016 18:04 UTC (Thu) by misc (subscriber, #73730) [Link]

Yup, I use noscript and just booking a ticket of bus in eastern europe is taking me 10 to 15 minutes if I lose my current whitelist. There is also lots of website who just show a white page, because they do not cope with script failure in a proper way.

I can't imagine having that by default and expecting people to make any meaningful decision.

Now, if people didn't flock to external SaaS service with proprietary code and incentives to spy on us, maybe the problem wouldn't be so prevalent. But then, maybe if we did listen more the RMS instead of trashing him as "out of the reality", we wouldn't also be so surprsed of the current state of the web.


Copyright © 2016, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds