Randomize non-webcompat FP values to prevent fingerprinting

[pes10k]

Currently our main approach for protecting against fingerprinting is to try and make web api endpoint values as predictable as possible, to try and keep users in as large an anonymity set as possible.

This is probably the right "fundamental" approach, but its got problems:

1. Takes lots of engineering time and we're getting out run by new FP-contributing endpoints
   2)There are lots of places where creating predictable / constant results of FP surface will break sites

We should take the opposite approach, at least for the medium term: Identify values used in creating fingerprints that can be modified (w/in some range) and intentionally vary those. Instead of shooting for putting all users in as-large-as-possible-an-anonymity set, this would instead aim to put all users in a constantly changing anonymity set of 1.

The approach has the downsides of being circumventable by attackers (just remove those values from their FP generation techniques) but, even then we get the win of removing FP surface.

Possible areas:

• minor version numbers for OS and browser in UA (easy)
• Sentographic style manipulations to Web Audio and Canvas APIs (difficult)
• values for deviceMemory, maxConcurrency, etc (easy)
• plugins (e.g. injecting made up plugins) (easy)

Existing work in the area:
Nikiforakis, Nick, Wouter Joosen, and Benjamin Livshits. "Privaricator: Deceiving fingerprinters with little white lies." (WWW 2015)
Laperdrix, Pierre, Benoit Baudry, and Vikas Mishra. "FPRandom: Randomizing core browser objects to break advanced device fingerprinting techniques." International Symposium on Engineering Secure Software and Systems.

Related: #2471

[fmarier]

Bromite has a patch for WebAudio fingerprinting: https://github.com/bromite/bromite/blob/master/build/patches/AudioBuffer-AnalyserNode-fingerprinting-mitigations-via-IDL.patch

[pes10k]

@fmarier is there more to the patch? I see how the IDL def changes, but I don't see where the randomization is actually performed. (It might also be that im not familiar enough with the internals of this stuff though, so apologies if im missing something)

But, if there is something off the shelf we can pull in, that would be terrific! The approach in the FPRandom paper seems to change the volume of generated frames by (+/- .001%) which is a dead simple, but probably good enough way of going about it.

Also, a large idea is to generate a per session seed, and use it as the basis for all the FP values we'd like to add noise to (possibly: version nums in UA, canvas, audio, etc). WDYT?

[fmarier]

I've not taken the time to understand what the patch does, I just noticed it while looking for something else and I thought I'd make a note of it for when we get back to this issue.

[bsclifton]

Updated to add milestone (here and to PR that closed it)

@pilgrim-brave @pes10k any QA needed for this? If so, let's add some test steps to the top post and label as QA/Yes. If not, we can label with QA/No

[bsclifton]

Marked as QA/No as this should be covered by automation, per @pes10k