FPRandom: Randomizing Core Browser Objects to Break Advanced Device Fingerprinting Techniques

Abstract

The rich programming interfaces (APIs) provided by web browsers can be diverted to collect a browser fingerprint. A small number of queries on these interfaces are sufficient to build a fingerprint that is statistically unique and very stable over time. Consequently, the fingerprint can be used to track users. Our work aims at mitigating the risk of browser fingerprinting for users privacy by ‘breaking’ the stability of a fingerprint over time. We add randomness in the computation of selected browser functions, in order to have them deliver slightly different answers for each browsing session. Randomization is possible thanks to the following properties of browsers implementations: (i) some functions have a nondeterministic specification, but a deterministic implementation; (ii) multimedia functions can be slightly altered without deteriorating user’s perception. We present FPRandom, a modified version of Firefox that adds randomness to mitigate the most recent fingerprinting algorithms, namely canvas fingerprinting, AudioContext fingerprinting and the unmasking of browsers through the order of JavaScript properties. We evaluate the effectiveness of FPRandom by testing it against known fingerprinting tests. We also conduct a user study and evaluate the performance overhead of randomization to determine the impact on the user experience.

The stamp on the top of this paper refers to an approval process conducted by the ESSoS artifact evaluation committee chaired by Karim Ali and Omer Tripp.

Appendices

A Analyzing Differences in the AudioContext API

In order to have a better understanding of the diversity of audio fingerprints on the web, we deployed the AudioContext script found by Englehardt et al. on the AmIUnique.org website (used in our Beauty and the Beast study [14]). After discarding more than 1,000 fingerprints from browsers that did not implement the AudioContext API, we collected in total 19,468 audio fingerprints on a period of 100 days between June and September 2016. The results of this study can be found in Table 3. We use the Shannon entropy in bits to better represent the probability distribution of each of the attributes. The higher the entropy is, the more diversity is exhibited between devices.

Table 3. Study of 19,468 audio fingerprints

Most of the collected attributes have a single value and do not provide any ground to distinguish one device from another. From the collected audio fingerprints, only 3 attributes have an entropy superior to a single bit:

• acSampleRate is the default sample rate of a created track when using the AudioContext API. The most common values are 44,1 kHz (49,0% of collected fingerprints) and 48 kHz (48,5%) but some browsers still present some unusual ones (1,7% have 192 kHz and 0,7% 96 kHz).

• audioDynSum is the sum of 500 frames generated by a very specific audio processing (compressed audio from an oscillator). The precision of each frame is up to 15 decimal digits. The large majority of values are really close to each other with differences only appearing from the 6th or 7th decimal digit.

• audioDynHash is similar to audioDynSum as it takes the exact same output but it covers the entirety of the rendered track instead of a few hundreds frames. As it covers a larger space, the entropy is a little higher and this test exhibits more diversity than all other collected attributes.

With these results, we decided to focus only on the differences created by the audio processing performed inside audio nodes. Especially, we want to introduce random noise in the computed frames so that each run of the same test produces different variations. Other values like the default sample rate are still interesting to change but they can easily be modified and they are not the focus of this work.

Fig. 5.

String comparison between the appName and appVersion properties

B Example of String Comparison When Ordering JavaScript Properties

Figure 5 illustrates the comparison mechanism between the appVersion and the appName strings. The engine starts with the ‘a’ letter on both strings. Translating this letter to their corresponding Latin-1 code points yields the decimal numbers ‘97’. Subtracting 97 from 97 results in 0. As no difference is detected, the engine continues but faces the exact same result for both the second and third characters in each string as they are identical ‘p’ letters. However, the behavior is different from the fourth character. The first string presents a ‘V’ and the second an ‘N’. Translating to their decimal code points yields ‘86’ and ‘78’. This time, since the subtraction $86-78=8$ does not give a zero, it informs the engine that a difference has been detected. As the result is positive, appName is placed before appVersion. If the result of the subtraction were to be negative, it would have been the opposite order.