This post introduces browser fingerprinting and anti-fingerprinting mechanisms. We explain what JShelter implements and the strengths and downsides of the anti-fingerprinting mechanisms.

In short, browser fingerprinting is a stateless tracking method vastly prevalent on the web in recent years. Similarly to a human fingerprint, browser fingerprinting tries to find a set of features that make (almost) every fingerprint unique and the browser uniquely identifiable.

The fingerprinting features contain various sources, mostly accessible through browser application interfaces, APIs. The APIs provide essential functionality for modern websites; however, they leak sensitive information about the browser, operating system, or device itself. Many different devices are connected to the internet — most of them with a very specific configuration. Leaking hardware and software properties may result in a sufficiently identifiable browser fingerprint. Furthermore, do not forget about the possibility of leaking information that may uncover vulnerabilities of your system for the sake of potential attackers.

At first glance, browser fingerprinting seems to be a great evil in the world full of privacy concerns. However, we should be aware of two distinct purposes for using browser fingerprinting.

Firstly, there is a negative or destructive use case during which websites profile cross-domain user activities without user consent. Trackers use the fingerprint as a cross-domain identifier.

Secondly, there is a positive or constructive use case, where websites tend to collect information about your system to improve the usability or security of their application. For example, applications can recommend installing critical security updates based on your system properties. Some websites collect browser fingerprints to verify known devices of their users to prevent fraud. The JShelter.org website offers the download link in the extension store based on the user agent.

Many browser vendors have already introduced changes to the cookie policy. Browsers such as Firefox, Safari, and Brave block third-party cookies, often abused for stateful tracking. Chrome developers recently announced that they will jump on the bandwagon too. The counter-measures against stateful tracking techniques result in a substantial increase in the usage of browser fingerprinting.

Counter-measures to browser fingerprinting

Unlike cookies, browser fingerprinting does not require storing an identifier on the device. Instead, the identifier is recomputed with each visited page. Once the fingerprint is obtained, it can be sent to a tracking server in a subsequent request. Moreover, the whole process of fingerprint extraction is invisible to a user. There are many sources of potentially identifiable information from which a fingerprint can be constructed. A fingerprint is considered passive when it contains natively accessible information from HTTP headers or network traffic. On the other hand, active fingerprint runs JavaScript code to retrieve data from browser APIs. JShelter focuses on detecting and preventing active fingerprinting.

Nowadays, there are many solutions to mitigate the effects of browser fingerprinting to improve internet privacy.

Modifying the content of fingerprints is a valid choice to resist a fingerprinting attempt. However, each modification may create an inconsistency that may improve the fingerprintability of the browser. Many protection tools use predefined or real fingerprints instead of the user's one to counter this issue.

Another approach is to create homogeneous fingerprints. If every fingerprint is the same, there is no way to tell the users behind the browsers apart. The leading representative of this approach is the Tor browser. Level 3 of JShelter aims to create a homogenous fingerprint. Unfortunately, homogeneous fingerprints have an inherent downside of following specific rules to be effective. Most importantly, the effectiveness of the approach depends on the broad coverage of the blocked APIs and the size of the population employing the counter-measures. All browsers with the same fingerprint form an anonymity set. An observer cannot distinguish between browsers in the anonymity set. With every missed fingerprintable attribute, the anonymity set breaks into smaller sets. For example, the Tor browser strongly recommends using a specific window size. Suppose you use a window size different from all other Tor browser users. In that case, a fingerprinter can identify you solely by this attribute. Also, keep in mind that Tor browser hides your IP address, which JShelter does not do. Hence we see Level 3 protections more as leak prevention than an anti-fingerprinting measure. If you like the idea of homogeneous fingerprints, install Tor browser.

Brave browser modifies the readings from APIs misused to create fingerprints. Nevertheless, the goal is to create a unique fingerprint for each domain and session. As the fingerprint changes for every visited domain, its use for linking cross-domain activities is smaller. JShelter already implements the farbling protection of Brave and uses them as the default anti-fingerprinting approach.

Recently, we added Fingerprint detector (FPD) to JShelter. FPD does not modify the fingerprint. Instead, FPD monitors APIs that are often misused by fingerprinters. When FPD detects a fingerprinting attempt, it warns the user. You can also allow FPD to block all subsequent transmissions of the page and remove stored data to prevent storing the fingerprint and loading it after a page reload. Hence, FPD allows the page to compute the fingerprint but (if allowed) blocks the page from uploading the fingerprint away from your computer.

Other approaches include blocking JavaScript code from suspicious sources or decreasing the surface of browser APIs with explicit permission control. Extensions like NoScript Suite are perfect complementary measures to JShelter.

Despite all the efforts, there is no ultimate approach that can prevent fingerprinting while keeping a high level of usability in mind. Every approach has its strengths and weaknesses, so the challenge is to find a balance between privacy and usability.