Browser Fingerprinting - Defenses
September 12th, 2019
As we saw in the previous blog post, browser fingerprinting can be very efficient at identifying a browser. It can be used for security but also for tracking reasons, completing the existing technologies. As browser fingerprinting gained more and more visibility, countermeasures started being developed. I will present the defenses sorted by the mechanism they used. We can consider 3 mechanisms : blocking the access to the attribute value, breaking the stability and unifying the attribute values.
Blocking the access
Because browser fingerprinting relies mainly on JavaScript attributes~\cite{gomezboix18}, the simplest way of being protected against fingerprinting is to block the execution of fingerprinting scripts. Ghostery, NoScript, AdBlock and Privacy Badger are popular browser extensions that block tracking scripts. These extensions use filter lists, either proprietary or crowdsourced, such as EasyPrivacy as well as heuristics to determine if a request should be blocked.
Breaking the stability of a fingerprint
As we saw at the end of the previous blog post, a fingerprint is a reliable tracking technique because it is stable over time. One of the defense is to break the stability by introducing several changes between each fingerprint collect, or between each browser session. Many extensions exist to alter attributes such as User-Agent spoofers. They aim at lying on the OS and browser. However, as we saw in the previous blog post, there are many ways to detect the OS and browser - User-Agent in HTTP header, User-Agent in navigator object, eval.toString().length, presence of -moz- or -webkit- prefix in function names, etc. Lying on some of the attribute values but not on all might be worse, as it will create some inconsistencies that cannot exist in the wild without specific modifications. Consequently, it is very difficult to lie on every attribute, and it has been proved (cite nikiforakis13) most of the User-Agent spoofers are introducing inconsistencies.
Another type of extension is canvas poisoner. They aim at adding some noise to the canvas to hide the real values of the canvas. The images on the right show a real canvas, and a canvas altered with Canvas Defender, which is an extension to add noise to the canvas. Vastel (cite Vastel) showed that we can easily detect the noise added by these extensions, which can lead to more unique fingerprints since knowing the user has one of these extensions increases uniqueness. Furthermore, they show that in some cases you can extract the noise and recover the canvases original value, making the extension counterproductive.
Others techniques aim at creating several identities. Torres (cite Torres) created a browser extension that generates different fingerprint identities for each website the user visits. The approach is breaking the stability for third-party websites, making it useful if a third-party fingerprinting script is included on different domains, it cannot use the fingerprints collected on those domains to track the user. Unfortunately, the extension no longer seems to be maintained. Laperdrix~\emph{et~al.}~\cite{laperdrix17} proposed an approach, Blink, that leverages virtual machines to generate consistent and unique fingerprints. Each time it is launched, it generates an environment that exhibits a new fingerprint. He also proposed a version of Blink that uses Docker containers instead of VMs.
Unifying the attribute values
Apart from stability, the main properties of browser fingerprinting is uniqueness. It comes from the fact users have different languages, timezones, coming from different configurations and software. One of the techniques used to be less traceable is to have the same attribute values as the other users. This is a technique The Tor browser is implementing, by returning the same value for many attributes. The table below shows the attributes available, unified, modified and blocked.
| Status in Tor | Fingerprinting attribute |
|---|---|
| Available | Local storage availability, Session storage availability |
| Constant value | JavaScript and HTTP User-Agent, HTTP Accept-Language, Accept, Accept-Encoding and Accept-Charset headers, Date.getTimezoneOffset() |
| Modified | Screen resolution |
| Unavailable | Plugin list, Flash font list |
In a general manner, the best fingerprinting defenses are the ones that are used by a large set of users. Consequently, defenses built by browsers have the advantage of being directly applied to millions of users and are a reliable source of protection. Several browsers implemented countermeasures to browser fingerprinting:
Apart from the protections presented upper, Tor is implemented other protection.
Since version 5.5 (January 2016), the Tor browser makes JavaScript font fingerprinting ineffective by building a unique list of basic fonts for all users.
This does affect a page's rendering if the pages chosen font is not available.
Additional fonts can be allowed by modifying the font.system.whitelist attribute in the Fonts.conf configuration file for Tor, but this is not recommended since it would make users more identifiable.
Tor also asks for the user's permission to use the canvas API.
In their study, Saito (cite Saito) found that 14% of the Tor browsers running on version 5.5 or higher can be fingerprinted, compared to 70% for versions before 5.5.
The reason is, as explained earlier, the list of fonts is highly discriminating.
Firefox implements many of the same protection as the Tor browser.
Firefox started to address the fingerprint tracking problem by reducing font uniqueness.
Since Firefox 52, it is possible to define a font whitelist using the same configuration setting as Tor, font.system.whitelist.
Firefox 58 introduced a configuration element to block the canvas API or to warn the user when it is used.
Firefox aims at simplifying the way to block fingerprinters by adding a dedicated interface in Firefox 68 (May 2019).
Firefox also disabled the battery API after a research article showing it could be used to track users [Olejnik15].
Safari was one of the first browsers to block Flash because of security concerns.
More recently, Safari added a system called intelligent tracking prevention (ITP) that aims at protecting against tracking, including browser fingerprinting.
While the strategy they use is not public, the idea behind the strategy is to unify system attributes, such as fonts, among all MacOS devices to remove the unicity of their fingerprints.
Brave, a privacy-oriented browser that natively integrates protection against browser fingerprinting
For example, it blocks access to APIs that enable generating fingerprinting attributes with entropy, such as the audio, the canvas, and the WebGL APIs.
Moreover, scripts cannot access the screen.left and screen.top parameters.
While the private mode does not store cookies once the session is closed, it does not include many browser fingerprinting countermeasures. However, Wu (cite Wu) showed the countermeasures that were introduced in private modes create inconsistencies. Recently, Chrome tried to make the private mode having the same behavior as the normal. It was quickly demonstrated the Storage API could detect the private mode in newer versions on Chrome.
- Pierre Laperdrix, Benoit Baudry, and Vikas Mishra. FPRandom: Randomizing core browser objects to break advanced device fingerprinting techniques. In: ESSoS 2017 - 9th International Symposium on Engineering Secure Software and Systems. https://hal.inria.fr/hal-01527580
- Nick Nikiforakis, Wouter Joosen, and Benjamin Livshits. PriVaricator: Deceiving Fingerprinters with Little White Lies. In: Proceedings of the 24th International Conference on World Wide Web, WWW 2015. https://doi.org/10.1145/2736277.2741090
- Takamichi Saito et al. Tor Fingerprinting: Tor Browser Can Mitigate Browser Fingerprinting? https://doi.org/10.1007/978-3-319-65521-5_44
- Antoine Vastel et al. Fp-Scanner: The Privacy Implications of Browser Fingerprint Inconsistencies. In: 27th USENIX Security Symposium (USENIX Security 18). https://hal.inria.fr/hal-01820197