The following writeup is adapted from my bug report to DuckDuckGo in issue #736 and partial patch proposed in PR #737.

Intended Protection

One technique for device fingerprinting involves observation of minor variations in mathematical operations. For example, the result of floating point operations may differ depending on the underlying implementation. These differences may be introduced by software or hardware and will often affect the least significant bits of the floating point representation.

To expose these implementation differences, fingerprinting software executes floating point operations that are likely produce disparate results when executed on different hardware or software stacks. In particular, the Web Audio API defines an AudioBuffer object consisting of 32-bit floats. The API also provides numerous operations for modifying the audio data - each of which is a potential source for implementation differences.

To prevent fingerprinting software from using these differences to fingerprint a browser, the DuckDuckGo Privacy Essentials (DPE) browser extension adds random noise when reading the contents of an AudioBuffer. The extension generates this random noise by using a pseudo-random number generator (PRNG) to modify calls to the AudioBuffer API.

PRNG Analysis

Analysis of the PRNG used in DPE yields two weaknesses which lessen the effectiveness of the protection. First, the PRNG is seeded with low-entropy input. Second, due to an implementation flaw, the chosen PRNG results in low quality randomness.

Low-Entropy Seed

The following code snippet demonstrates how the seed is selected for the PRNG. Notice that key.charCodeAt(0) selects the first character from key, where key is a hexadecimal string. Consequently, item takes a value in the range [0-9a-f], which has only four bits of entropy.

// Iterate through the key, passing an item index and a byte to be modified 
export function iterateDataKey (key, callback) { 
    let item = key.charCodeAt(0) 
    for (const i in key) { 
        let byte = key.charCodeAt(i) 
        for (let j = 8; j >= 0; j--) { 
            callback(item, byte) 
 
            // find next item to perturb 
            item = nextRandom(item) 
 
            // Right shift as we use the least significant bit of it 
            byte = byte >> 1 
        } 
    } 
} 

Source

Recommendation 1: Seed the PRNG with sufficient entropy. For example, a 64-bit LFSR should be seeded with 64-bits of entropy.

Choice of PRNG

DPE uses a Linear Feedback Shift Register (LFSR) PRNG. LFSRs have the benefit of being quite fast, which might be beneficial for low-latency audio applications. However, the chosen LFSR implementation operates on a 64-bit register. Normally, this would be fine, however JavaScript uses IEEE 754 format to represent numbers internally. This format only allows lossless representation of up to 53-bit integers. The result is that the PRNG output (ignoring the low-entropy seed discussed above) quickly decays into a predictable sequence of outputs.

The PRNG implementation is as follows:

export function nextRandom (v) { 
    return Math.abs((v >> 1) | (((v << 62) ^ (v << 61)) & (~(~0 << 63) << 62))) 
} 

Source

The PRNG selects which indexes in the AudioBuffer output are modified. Because the PRNG decays into a predictable state, the result is that far fewer than the desired numbered of outputs are modified. The following displays a simulation of the PRNG output for several seeds, demonstrating the high number of repeated indexes. Note that the output values of the PRNG are taken modulo the length of the AudioBuffer:

length=64  seed=97  sequence=[33, 48, 24, 12, 58, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31, 15, 7, 3, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 63, 31, 47, 55, 59, 3, 63, 31]
length=128  seed=57  sequence=[57, 28, 114, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15, 7, 3, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 127, 63, 95, 111, 119, 123, 67, 31, 15]
length=200  seed=98  sequence=[98, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87, 43, 127, 163, 167, 183, 191, 95, 47, 23, 111, 55, 127, 63, 31, 15, 7, 103, 151, 175, 87, 143, 71, 135, 167, 183, 191, 195, 151, 175, 87]
length=200  seed=99  sequence=[99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199, 99, 199, 99, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 199, 99, 199, 199]

Recommendation 2: Change the PRNG implementation. For example, a 32-bit LFSR would have similar performance characteristics but, better randomness given the limitation on JavaScript’s integers.

Implementation Choices

Beyond the PRNG, an additional design choice limits DPE’s ability to limit fingerprinting via the AudioBuffer API due to the amount of unprotected data.

Perturbation ratio

As an implementation choice, the iterateDataKey function (linked above) does not increase the number of perturbed elements with the length of the AudioBuffer. Instead, at most 8 * key.length elements are perturbed. In practice, the actual number is lower due to 1) duplicate elements chosen by the PRNG (discussed above), and 2) byte having at most seven ASCII bits¹.

As the length of the audio buffer grows, the ratio of perturbed to unperturbed elements falls. This makes it easier to extract unprotected fingerprint data from longer audio buffers.

Recommendation 3: Scale perturbation with the length of the buffer so that longer buffers do not yield a greater chance of selecting unperturbed items. If performance constraints allow, perturbing all elements in the buffer is preferable.

Boolean Logic

In the following code, byte ^ 0x1 is always true except when byte is zero, in which case, the index is perturbed by adding zero (i.e., not perturbed). Perhaps byte & 0x1 was intended instead. Currently, this has the effect that all perturbations are subtractions which further limits the randomness of perturbations applied.

iterateDataKey(audioKey, (item, byte) => {
    const itemAudioIndex = item % channelData.length

    let factor = byte * 0.0000001
    if (byte ^ 0x1) {
        factor = 0 - factor
    }
    channelData[itemAudioIndex] = channelData[itemAudioIndex] + factor
})

Practical Attacks

Due to the issues outlined above, the several practical attacks become possible. Fixing these issues should significantly mitigate the following attacks.

As a general theme, the following attacks allow reversing or bypassing the anti-fingerprinting techniques applied by the extension. At least some fingerprinting tools have expressed interest in reversing anti-fingerprinting protections (see section “Reverting Brave standard farbling”).

Pre-computed perturbation set

If the fingerprinting software relies on an AudioBuffer of known length, it is possible to pre-compute the set of indexes which may be perturbed over all PRNG seeds. (In fact, the computation is fast enough to be computed dynamically if variable buffer lengths are used.) Once the set is computed, the fingerprinting software may choose to ignore those indexes when generating the fingerprint, regardless of the extension’s presence. This makes the fingerprints comparable across all browsers.

The limited entropy in the seed means there are only sixteen possible sequences of indexes to ignore. And due to the poor performance of the PRNG, those sequences share significant overlap.

The following table shows the percent of items that could be perturbed without a priori knowledge of the PRNG seed. The listed percentage represents the amount of data in the AudioBuffer that is perturbed by at least one of the 16 possible seed values. Even with a short buffer length (such as n=64), approximately 50% of the buffer’s indexes are unperturbed under all seed values, giving plenty of unprotected values from which a fingerprint might be extracted. Modestly longer buffer lengths have even less protection.

length=64  percent=0.515625
length=128  percent=0.335938
length=192  percent=0.333333
length=256  percent=0.218750
length=320  percent=0.246875
length=384  percent=0.205729
length=448  percent=0.194196
length=512  percent=0.132812
length=576  percent=0.166667
length=640  percent=0.151562
length=704  percent=0.144886
length=768  percent=0.119792
length=832  percent=0.123798
length=896  percent=0.116071
length=960  percent=0.111458
length=1024  percent=0.076172
length=1088  percent=0.103860
length=1152  percent=0.096354
length=1216  percent=0.092928
length=1280  percent=0.089063
length=1344  percent=0.087798
length=1408  percent=0.081676
length=1472  percent=0.081522
length=1536  percent=0.066406
length=1600  percent=0.076875
length=1664  percent=0.069712
length=1728  percent=0.076968
length=1792  percent=0.066964
length=1856  percent=0.068427
length=1920  percent=0.063542
length=1984  percent=0.064516
length=2048  percent=0.042480

To give a specific example, a buffer of length n=64 will have the following indexes perturbed by the extension depending on the input key:

// {seed: [indexes]}
{
  "48": [3, 7, 12, 15, 24, 31, 48, 58, 63],
  "49": [3, 7, 12, 15, 24, 31, 47, 49, 55, 58, 59, 63],
  "50": [3, 7, 15, 31, 35, 39, 50, 51, 63],
  "51": [3, 7, 15, 31, 39, 51, 63],
  "52": [3, 7, 27, 31, 38, 47, 51, 52, 55, 63],
  "53": [3, 7, 11, 23, 27, 31, 38, 43, 47, 51, 53, 63],
  "54": [3, 7, 11, 23, 27, 31, 43, 47, 51, 54, 63],
  "55": [3, 7, 27, 31, 47, 51, 55, 63],
  "56": [3, 7, 15, 28, 31, 50, 56, 63],
  "57": [3, 7, 15, 28, 31, 47, 50, 55, 57, 59, 63],
  "97": [3, 7, 12, 15, 24, 31, 33, 47, 48, 55, 58, 59, 63],
  "98": [3, 7, 15, 31, 34, 39, 51, 63],
  "99": [3, 7, 15, 31, 35, 39, 51, 63],
  "100": [3, 7, 14, 15, 31, 36, 39, 51, 63],
  "101": [3, 7, 11, 14, 23, 27, 31, 37, 39, 47, 51, 63],
  "102": [3, 7, 11, 23, 27, 31, 38, 39, 47, 51, 63]
}

Taking the union of indexes for each key, the following list of indexes could be ignored when generating a fingerprint to avoid accessing data modified by DPE:

// [indexes]
[3, 7, 11, 12, 14, 15, 23, 24, 27, 28, 31, 33, 34, 35, 36, 37, 38, 39, 43, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 63]

Recovery of PRNG state

Using the “Sample pre-computed perturbation set” table above, it is possible to reverse the set of perturbed elements to the seed used by the PRNG. The following code snippet recovers the seed by observing the perturbations in the audio buffer. (Note, while this example initializes the buffer to a known state, this attack can be performed on any buffer where the sum of all elements is not zero).

extractAudioKey() {
  // Reverse table for length=64
  const revtable = {
    "3,7,12,15,24,31,48,58,63": 48,
    "3,7,12,15,24,31,47,49,55,58,59,63": 49,
    "3,7,15,31,35,39,50,51,63": 50,
    "3,7,15,31,39,51,63": 51,
    "3,7,27,31,38,47,51,52,55,63": 52,
    "3,7,11,23,27,31,38,43,47,51,53,63": 53,
    "3,7,11,23,27,31,43,47,51,54,63": 54,
    "3,7,27,31,47,51,55,63": 55,
    "3,7,15,28,31,50,56,63": 56,
    "3,7,15,28,31,47,50,55,57,59,63": 57,
    "3,7,12,15,24,31,33,47,48,55,58,59,63": 97,
    "3,7,15,31,34,39,51,63": 98,
    "3,7,15,31,35,39,51,63": 99,
    "3,7,14,15,31,36,39,51,63": 100,
    "3,7,11,14,23,27,31,37,39,47,51,63": 101,
    "3,7,11,23,27,31,38,39,47,51,63": 102
  };

  var ab = new AudioBuffer({length: 64, numberOfChannels: 1, sampleRate: 48000});
  var abb = ab.getChannelData(0);

  // Initialize the buffer to a known value
  for (var i = 0; i < abb.length; i++) {
    abb[i] = 1;
  }

  // Read back the data, which will be perturbed by DDG
  var abb = ab.getChannelData(0);

  // Find perturbed elements.
  var perturbed = [];
  for (var i =In pra 0; i < abb.length; i++) {
    if (abb[i] != 1) {
      console.log(i, abb[i], abb[i] != 1)
      perturbed.push(i);
    }
  }

  // Lookup the perturbation set in `revtable`
  var lookup = perturbed.join(',');
  return revtable[lookup];
}

Due to how the cache is linked with the AudioBuffer instance, it is possible to discover the seed after having read the perturbed data.

Source

function getCachedResponse (thisArg, args) { 
    const data = cacheData.get(thisArg) 
    const timeNow = Date.now() 
    if (data && 
        data.args === JSON.stringify(args) && 
        data.expires > timeNow) { 
        data.expires = timeNow + cacheExpiry 
        cacheData.set(thisArg, data) 
        return data 
    } 
    return { audioKey: null } 
} 

Once the seed is known, there are a few possible uses:

• The seed is four bits of entropy which can be used to fingerprint a DuckDuckGo extension user’s session. This value is derived from the user’s session key and therefore cannot be used to track a user across sessions, but could track the user within a given session even if other data (such as cookies) have been cleared.
• The seed determines which indexes are perturbed and can be used to target specific indexes for exclusion from a fingerprint. This is more targeted than the “pre-computed perturbation set” described above, allowing for recovery of additional unperturbed data from a smaller buffer.
• The seed (which is also the first four bits of the audioKey) fully determines the perturbation applied to several indexes in the buffer. Knowing the seed may allow the perturbation to be reversed. The remainder of this section is dedicated to this case.

Knowing the seed allows determination of the perturbation applied to several indexes within the buffer. The amount of perturbation is determined by a byte (hex digit) of the key and the iteration of the perturbation process. Because the first byte of the key is used eight times (bit-shifted once each time), it is possible to compute the perturbation that was applied. In this instance, the non-random PRNG output provides a degree of protection by perturbing most values many, many times with a different portion of the key. However, the first few PRNG outputs are sufficiently unique to only appear once for several seeds.

This green cells in this table show the indexes perturbed only once, depending on the seed. All such indexes are perturbed using the first byte of the key - which is known during this attack. Therefore, the perturbations are reversible (to the degree allowed by floating point precision).

In practice, I believe there are simpler methods to approximate the original values. However, they are not related to the PRNG and are therefore not discussed here.

Footnotes

The DuckDuckGo Privacy Essentials addon is a browser addon available for the Firefox and Chrome browsers. The addon lists several features including blocking trackers, private search, encryption, privacy grades, and support for Global Privacy Control. It is the 7th most popular addon for Firefox¹ with approximately 1.5 million users.

While the addon’s name clearly implies privacy-related functionality, its technical measures remain undocumented. The objective of this post is to analyze the anti-fingerprinting functionality of the addon for ease of comparison against alternative privacy solutions.

Scope

At the time of writing, DuckDuckGo Privacy Essentials (DPE) has 25 released versions on addons.mozilla.org, with the first version released August 21, 2019.

This post will only discuss version 2021.6.2 of the addon. The addon’s XPI file was downloaded from the Mozilla addons site, and was found to have a SHA256 hash of 510c4e7b7e720ccb5ee0eec78c498dee5c012a5939b8b0706b7a195377876fa2. Based on the tags from the addon’s Git repository, the commit hash corresponding to this version is bcef1583085ecbfdb5a3a52c12538ea949e8a65e.

All analysis and testing in this report is focused on Firefox for Desktop. Analysis of other browsers - including the Firefox mobile browsers - is out of scope for this post. For “part one” of this series, we limit our analysis to the anti-fingerprinting functionality found in ./shared/js/content-scope/.

Anti-fingerprinting

Audio API

DPE intercepts calls to several methods in the audio API. Specifically:

• AudioBuffer.getChannelData
• AnalyserNode.getByteTimeDomainData
• AnalyserNode.getByteTimeDomainData
• AnalyserNode.getFloatTimeDomainData
• AnalyserNode.getByteFrequencyData
• AnalyserNode.getFloatFrequencyData

The addon modifies the return values of these methods by adding deterministic noise to the channelData buffer based on the value of audioKey:

iterateDataKey(audioKey, (item, byte) => {
    const itemAudioIndex = item % channelData.length
    let factor = byte * 0.0000001
    if (byte ^ 0x1) {
        factor = 0 - factor
    }
    channelData[itemAudioIndex] = channelData[itemAudioIndex] + factor
})

In an attempt to limit tracking across sites, audioKey is a hash including the domain of the site. This should imply that a user’s fingerprint will not be shared across domains and therefore cannot be used for cross-site tracking. Further analysis is required to determine if this noise is sufficient to mask the underlying fingerprint. The key is generated as follows:

export function getDataKeySync (sessionKey, domainKey, inputData) {
    const hmac = new sjcl.misc.hmac(sjcl.codec.utf8String.toBits(sessionKey + domainKey), sjcl.hash.sha256)
    return sjcl.codec.hex.fromBits(hmac.encrypt(inputData))
}

Canvas API

DPE intercepts calls to several methods in the canvas API:

• CanvasRenderingContext2D.getImageData
• HTMLCanvasElement.toDataURL
• HTMLCanvasElement.toBlob

Similar to the audio API protection, canvas data is also modified based on a domain-specific key to limit the ability to track users across sites:

iterateDataKey(canvasKey, (item, byte) => {
    const channel = byte % 3
    const lookupId = item % length
    const pixelCanvasIndex = arr[lookupId] + channel

    imageData.data[pixelCanvasIndex] = imageData.data[pixelCanvasIndex] ^ (byte & 0x1)
})

Do Not Track API

DPE unsets navigator.doNotTrack, but does not also unset the DNT header. If a fingerprint includes both the header and DOM values, this behavior may make a user of the addon more unique compared to the global population.

NOTE: In response to this post, a future release is expected to stop removing navigator.doNotTrack.³

Global Privacy Control

The DuckDuckGo Privacy Essentials addon has a feature titled Global Privacy Control (GPC). On a technical level, GPC is a draft specification for communicating privacy preferences via HTTP headers and JavaScript properties.

It is interesting that DPE disables navigator.doNotTrack but specifically adds the navigator.globalPrivacyControl field and Sec-GPC header. Do Not Track and Global Privacy Control are competing specifications for communicating tracking preferences; DuckDuckGo was involved in creating the draft specification for GPC, which may indicate the reason for this preference. Still, it seems like this behavior should be documented as it may interfere with the user’s expectations when enabling Do Not Track.

DPE allows the presence of the GPC header to be toggled by the user via the addon’s settings. However, navigator.globalPrivacyControl is always present and indicates the user’s configuration of the addon. Beyond allowing fingerprinting of the addon’s presence, this allows fingerprinting based on the addon’s configuration.

The value of navigator.globalPrivacyControl is computed as follows:

// If GPC on, set DOM property to true if not already true
if (args.globalPrivacyControlValue) {
    if (navigator.globalPrivacyControl) return
    defineProperty(navigator, 'globalPrivacyControl', {
        value: true,
        enumerable: true
    })
} else {
    // If GPC off, set DOM property prototype to false so it may be overwritten
    // with a true value by user agent or other extensions
    if (typeof navigator.globalPrivacyControl !== 'undefined') return
    defineProperty(Object.getPrototypeOf(navigator), 'globalPrivacyControl', {
        value: false,
        enumerable: true
    })
}

Referer

In the absence of a Referrer-Policy header, Firefox defaults to stripping path information from the Referer header for external links. However, certain Referrer-Policy configurations, such as unsafe-url, will cause the full path to be sent.

DPE specifically avoids modification of document.referrer on internal links (i.e., links between pages on the same host) using the following condition:

new URL(document.URL).hostname !== new URL(document.referrer).hostname

Hardware APIs

The choice of 8 for navigator.hardwareConcurrency may make a user more unique. According to the Firefox Public Data Report for June 14th, 2021, 52% of Firefox users have two physical cores, followed by 34% with four cores. Only 3% reported having eight physical cores. Firefox’s own “resist fingerprinting” functionality spoofs navigator.hardwareConcurrency to 2 to make users appear less unique compared to the global population.

It is possible that the addon creators are attempting to mitigate potential performance impacts. If a webpage uses workers for compute-intensive tasks, the webpage may throttle performance by letting CPU capacity go unused. However, spoofing additional cores may also cause a webpage to spawn more than there are available cores, which may also have deleterious performance impact.

NOTE: In response to this post, a future release of DPE is expected to set navigator.hardwareConcurrency to 2.⁷

Screen Size

Overall, DPE prevents observation of window movements and total monitor count. The position of the window on the screen remains static whereas the default behavior is to update those parameters in realtime. Additionally, since certain OS-level UI elements are only present on some monitors, movement of the window across monitors cannot be detected in this way. DPE does not hide monitor resolution, which may be somewhat unique, especially on mobile browsers and monitors with special form factors (ultra-wide, HDPI, etc.). The Firefox Public Data Report indicates that the two most popular display resolutions are 1920x1080 (38%) and 1366x768 (26%).

Non-Firefox APIs

Browsers often offer experimental or non-standard APIs. Additionally, not all browsers conform with all released standards. The addon has anti-fingerprinting protection for the following APIs which are not supported in Firefox and are therefore not analyzed here:

• Floc API (Document.prototype.interestCohort)
• Battery API (navigator.getBattery())
• Temporary Storage API (navigator.webkitTemporaryStorage)

Future Work

• Evaluate data shared with DuckDuckGo servers during/after the installation of the addon.
• Evaluate the efficacy of the above anti-fingerprinting techniques. For example, whether it is possible to amplify the signal of the audio API fingerprinting techniques to overcome the injected noise.
• Analyze how the DPE Privacy Grade is computed and whether external servers are accessed in computing the grade.
• Assess the reproducibility of the published XPI file from the addon’s source code.
• Analyze the tracker blocking functionality, including cookie handling for known tracker domains.

Updates

• 2020-07-07:
  • Added notes indicating that a future release of DPE will stop removing navigator.doNotTrack and will set navigator.hardwareConcurrency to 2. Thanks to the DuckDuckGo team for their communication and quick response!
  • Corrected a spelling error.

Footnotes

When a security vulnerability is found in software, it is desirable to know how long the software was vulnerable to that particular vulnerability and which versions were impacted. This information allows communications to be sent to consumers of that software so they know to upgrade, and it places bounds on the known window of vulnerability (which is relevant to to investigations that might look for indicators of abuse). Additionally, accurate information about the range of affected versions reduces false positives in security scanning tools.

Recently, I submitted a security advisory for Rust’s nalgebra crate. While discussion provided a version number that fixed the vulnerability, I still needed to find the version that introduced the vulnerability to populate the unaffected field in the advisory format. The following post describes my methodology for finding when the vulnerability was introduced, without any prior knowledge into the nalgebra crate.

Understanding the vulnerability

First, we need to understand the vulnerability well enough to evaluate whether a given version of the code contains that vulnerability. The vulnerability in question results from a failure to validate input in a deserialize implementation for the VecStorage struct. In this case, the deserialize function was automatically generated by a macro.

#[cfg_attr(feature = "serde-serialize", derive(Serialize, Deserialize))]
pub struct VecStorage<T, R: Dim, C: Dim> {
    data: Vec<T>,
    nrows: R,
    ncols: C,
}

The first line of the code snippet is the macro that generates the serialization and deserialization logic (derive(Serialize, Deserialize)). This logic is only enabled if the serde-serialize feature flag is enabled (this allows users to opt-in to the serialization functionality if it is required).

In the following lines, we see the struct members. data is a vector which is expected to have length nrows * ncols. However, the automatically generated deserializer does not guarantee that invariant. This allows specially crafted inputs to violate the length invariant, which allows memory access past the end of data’s allocated buffer.¹

We now know what to look for: if VecStorage has an automatically derived Deserialize implementation, then then the version is vulnerable.

Finding the range of affected commits

Now that we understand how to check a version of the software for the vulnerability, we need an efficient strategy to scan the history of the project to find when the vulnerability was introduced. The nalgebra Git history has nearly two thousand commits, so evaluating each commit by hand is unreasonable.

The process can be accelerated using a binary search to determine which commits to evaluate. Git implements this binary search functionality with a sub-command called bisect. With the bisect tool, you tell Git whether a given commit should be labeled as “good” or “bad.” With those labels, Git will attempt to narrow in on the exact commit that caused the change from “good” to “bad.” In our case, we define “good” to mean “not vulnerable” and “bad” to mean “vulnerable.”

The following steps demonstrate how to run git bisect on the nalgebra repository:

1. Find the most recent vulnerable commit. If a fix is available, the commit immediately preceding it is likely to be the most recent vulnerable commit. If a fix is not available, the latest commit on the main branch may suffice. In this case, the nalgebra project fixed the issue in 5bff536. So, we run git checkout 5bff536^, where the ^ is used to checkout the preceding commit.

    git clone https://github.com/dimforge/nalgebra.git
    cd nalgebra/
    git checkout 5bff536^
   

2. Start the bisect process. Because we know the current commit is vulnerable, we mark it as “bad” with git bisect bad.

    git bisect start
    git bisect bad
   

3. Choose a known-good commit. If additional information is available to indicate a previously “good” commit, you can provide that information to reduce the search space. In this case, we do not have such information and must assume the vulnerability could have been introduced at any earlier point.

    # Without knowledge of a previous good commit, this will tell
    # `git bisect` to search the entire commit history.
    git bisect next
   
    # With knowledge of a good commit
    git checkout 123ABCD
    git bisect good
   

4. Step through commits: At this point, Git will begin automatically stepping through commits. When you mark a commit as good or bad, it will automatically advance to the next commit. As you continue marking commits, Git will narrow the search space to find which commit introduced the vulnerability.

   At each step, we run a recursive search with ripgrep to check if the derived Deserialize implementation is present:

    rg 'struct VecStorage' -B 1
   

   When we see output like the following, we know the commit is vulnerable.

    27-#[cfg_attr(feature = "serde-serialize", derive(Serialize, Deserialize))]
    28:pub struct VecStorage<T, R: Dim, C: Dim> {
   

   And we mark those commits as bad:

    git bisect bad
   

   When there is no output from ripgrep, we know that VecStorage is not present in that commit, so we mark it as good:

    git bisect good
   

5. Continue stepping through commits: Repeat the instructions from step #4 until you see output like the following:

    Bisecting: 7 revisions left to test after this (roughly 3 steps)
    [0f66403cbbe9eeac15cedd8a906c0d6a3d8841f2] Rename `MatrixVec` to `VecStorage`.
   

   If at any point you make a mistake, you can start over by running:

    git bisect reset
    git checkout 5bff536^
   

Relocated code

We were able to identify commit 0f66403 after only several iterations. However, this is not quite the commit that introduced the vulnerability. From the commit message, we see that VecStorage was renamed from MatrixVec:

Bisecting: 7 revisions left to test after this (roughly 3 steps)
[0f66403cbbe9eeac15cedd8a906c0d6a3d8841f2] Rename `MatrixVec` to `VecStorage`.

Running git show 0f66403cbbe9eeac15cedd8a906c0d6a3d8841f2 displays the diff for this commit. We can see that the struct was only renamed - the derive code is still present, which means the code is still vulnerable:

 #[cfg_attr(feature = "serde-serialize", derive(Serialize, Deserialize))]
-pub struct MatrixVec<N, R: Dim, C: Dim> {
+pub struct VecStorage<N, R: Dim, C: Dim> {
     data: Vec<N>,
     nrows: R,
     ncols: C,
 }

To continue searching backwards from this point, we need to restart the bisect operation at this new commit:

git bisect reset
git checkout 0f66403cbbe9eeac15cedd8a906c0d6a3d8841f2
git bisect bad
git bisect next

And modify our checks with the new struct name:

rg 'struct MatrixVec' -B 1

Modified code

We are quickly closing in on the point where the vulnerability was introduced. Along the way, you might notice that the feature flag logic was removed. However, Deserialize is still present inside the #[derive(...)] macro, which means we can mark this commit as “bad” and continue:

#[derive(Eq, Debug, Clone, PartialEq, Serialize, Deserialize)]
pub struct MatrixVec<N, R: Dim, C: Dim> {

Found, at last

Finally, we have reached the end and have identified commit 086e6e7.

086e6e719f53fecba6dadad2e953a487976387f5 is the first bad commit
commit 086e6e719f53fecba6dadad2e953a487976387f5
Date:   Sun Feb 12 18:17:09 2017 +0100

    Doc + slerp + conversions.

:100644 100644 37a437170a0652cdea2b1fa9acc432b0c36d0238 398f0db9bd785f614dce61b12189118ee94f0243 M      Cargo.toml
:100644 100644 f9586c02d4bb6566c368f4af1355ce0ddeeb4468 00457c113ed7b92e490db1c0fc40369ce9bee791 M      Makefile
:100644 100644 c860659cb7e48ed3fe1b02f10eb477e6dde753f7 7d6a99fa156eac406835d7ed97573ed5f5266061 M      README.md
:000000 040000 0000000000000000000000000000000000000000 1ec3a39daebd14edf61757bf8bd97def798d24b4 A      examples
:040000 040000 75d90764b1b2611d068ac8924988cefb425c05f3 2f2d71b9b97c4b8c339ae3397e67d550afa4a027 M      src
:040000 040000 6daa48d65a69f7450442bf4dd3f35fa2549d8f5e 3224ca40928811a275336a1d7f47784b3962d876 M      tests

Running git show 086e6e719f53fecba6dadad2e953a487976387f5, we scan the diff and find that this is where the Deserialize implementation was added. We found the commit where this vulnerability was introduced!

-#[derive(Eq, Debug, Clone, PartialEq)]
+#[derive(Eq, Debug, Clone, PartialEq, Serialize, Deserialize)]
 pub struct MatrixVec<N, R: Dim, C: Dim> {

Converting to versions

There is one last step to our process. We need to find the first version of this crate that was released with vulnerable code. We know that 086e6e719f53fecba6dadad2e953a487976387f5 first introduced the vulnerability, so we can run the following command to see which tags contain that commit in their history:

git tag --contains 086e6e719f53fecba6dadad2e953a487976387f5

This outputs a list of tag names. v0.11.0 is the earliest version containing the vulnerable Deserialize implementation. We now have all the information we need to complete the advisory report.