Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector

[mikeperry]

WebAudio allows you to write data to AudioBuffers and perform effects/manipulation/spectral analysis on them, and extract their contents.

If the underlying routines are OS supported, they may be fingerprintable. ​https://developer.mozilla.org/en-US/docs/Web_Audio_API

[mikeperry]

This may be easy for someone who has a bunch of different OSes and writes some test JS to print out values from some audio manipulation tests using these buffer extraction functions. Well, easy to test for differences anyway.

[gk]

​https://developer.mozilla.org/en-US/docs/Web/API/OfflineAudioContext may leak audio processing capabilities.

[mikeperry]

Tag the set of things we should have implemented before a full 5.0 launch, and add them to the July radar.

[mikeperry]

I am going to shoot from the hip on this one and guess that this is at most an OS fingerprinting vector.

Certainly not something we'll solve by 5.0 anyways.

[mo]

"This page tests browser-fingerprinting using the AudioContext and Canvas API. Using the AudioContext API to fingerprint does not collect sound played or recorded by your machine - an AudioContext fingerprint is a property of your machine's audio stack itself. "

​https://audiofingerprint.openwpm.com/

[cypherpunks]

I have three different machines, one Windows and two Linux ones and I can verify that for each different machine using Tor Browser 5.5.5 the fingerprints are exactly the same for each machine.

The fingerprinting persists on OS reboots, Tor Browser restarts and using Tor Browser's "New identity".

I have tested using the website above (​https://audiofingerprint.openwpm.com) in Tor Browser 5.5.5 and have done the test three times for each machine.

This is very problematic, hope this can be fixed soon! Thanks all!

By the way, for those who want to do the test themselves, use this one: ​https://valve.github.io/fingerprintjs2/
Because ​https://audiofingerprint.openwpm.com automatically sends information to Princeton.

Edit: Sorry I thought fingerprintjs2 used the same "Audio fingerprinting" as Princeton's test.
So for those who want to do the test themselves, use ​https://audiofingerprint.openwpm.com and you might want to first enable Javascript, put yourself in Offline mode, and _then_ do the test, so that no information about your machine/browser is sent to Princeton.

[gk]

Replying to cypherpunks:

I have three different machines, one Windows and two Linux ones and I can verify that for each different machine using Tor Browser 5.5.5 the fingerprints are exactly the same for each machine.

Hm... if they are exactly the same for each machine isn't that a good thing? It allows you hiding in the crowd which is our strategy to beat fingerprinters. That said, I tested it as well with two different Linux machines (and distributions) and on a Windows computer. I got the same fingerprint for the Linux machines but a different one with Windows (which is on one of the Linux boxes, too). Thus, this seems to support the theory that this is an OS-fingerprinting problem. Or did I miss anything?

[cypherpunks]

Replying to gk:

Replying to cypherpunks:

I have three different machines, one Windows and two Linux ones and I can verify that for each different machine using Tor Browser 5.5.5 the fingerprints are exactly the same for each machine.

Hm... if they are exactly the same for each machine isn't that a good thing? It allows you hiding in the crowd which is our strategy to beat fingerprinters. That said, I tested it as well with two different Linux machines (and distributions) and on a Windows computer. I got the same fingerprint for the Linux machines but a different one with Windows (which is on one of the Linux boxes, too). Thus, this seems to support the theory that this is an OS-fingerprinting problem. Or did I miss anything?

The fingerprints are the same for Tor Browser 5.5.5 on each machine individually independent of browser, OS, or computer restarts.
So each Tor Browser can be uniquely identified. This is very problematic ...

[cypherpunks]

Replying to cypherpunks:

By the way, for those who want to do the test themselves, use this one: ​https://valve.github.io/fingerprintjs2/

Wrong.

fingerprintjs2 does not (currently) contain tests for AudioContext fingerprinting: ​https://github.com/valve/fingerprintjs2/. The OpenWPM page has the tests in an embedded script tag (it has several implementations, apparently observed in the wild Internet).

This page has some actual information: ​https://webtransparency.cs.princeton.edu/webcensus/. There's also this paper (see section 6.4): ​https://randomwalker.info/publications/OpenWPM_1_million_site_tracking_measurement.pdf

[gk]

Okay, we take a closer look and get to the bottom of it.

[boklm]

In my case, I get the same fingerprint on 2 different computers with the same OS and same Tor Browser version. But changing Tor Browser version (I tried with 5.5.5 and 6.0a5) changed the fingerprint.

[cypherpunks]

Okay I've rechecked and compared the individual test results for each machine.
Which I refer to as Linux A, Linux B, and Windows

AudioContext properties

Windows and Linux B had the exact same values namely:

{

"ac-sampleRate": 48000,

"ac-maxChannelCount": 2,

"ac-numberOfInputs": 1,

"ac-numberOfOutputs": 0,

"ac-channelCount": 2,

"ac-channelCountMode": "explicit",

"ac-channelInterpretation": "speakers",

"an-fftSize": 2048,
"an-frequencyBinCount": 1024,

"an-minDecibels": -100,

"an-maxDecibels": -30,

"an-smoothingTimeConstant": 0.8,

"an-numberOfInputs": 1,

"an-numberOfOutputs": 1,

"an-channelCount": 1,

"an-channelCountMode": "max",

"an-channelInterpretation": "speakers"

}

But Linux A only had different values, listed here:

  "ac-sampleRate": 44100,
  "ac-maxChannelCount": 10000,

Fingerprint using DynamicsCompressor (sum of buffer values)

• Linux A and Linux B both had 35.14587543532252
• Windows had 35.145139578345606

Fingerprint using DynamicsCompressor (hash of full buffer)

• Linux A and Linux B both had 12a8c630cab33ce196f223822f4d23c59717abeb
• Windows had 14b5e50593a946dbf54923aeefec7682156ea46c

Fingerprint using OscillatorNode

• Linux A, Linux B and Windows all had a different unique fingerprint.

Fingerprint using hybrid of OscillatorNode/DynamicsCompressor method

• Linux A, Linux B and Windows all had a different unique fingerprint as well.

Hope this helps.

[cypherpunks]

Tested this on 3 Linux machines, and also Debian and Whonix running in VirtualBox.

For two Linux machines (different models of thinkpads, lspci says they are both using the same audio device) I got same values.

For third Linux machine with another audio device I got different fingerprints and AudioContext properties.

Whonix got their own values.

Debian running in VurtualBox got same fingerprints as host machine, but AudioContext is different.

[arthuredelstein]

I've done some investigation of the fingerprinting via the Web Audio API. As far as I can tell, the source code for the Web Audio audio processing alogrithms, in mozilla-central's dom/media/webaudio/ directory, is doing computations that run on the cpu/fpu only. That is, I don't see any evidence for acceleration of these algorithms on audio hardware, gpus, or other special platform-specific tricks.

I also specifically examined the API calls used for fingerprinting in view-source:https://audiofingerprint.openwpm.com/, and tracked down their C/C++ implementations and the helper libraries they depend on (primarily Kiss FFT and libav/FFT) in the Firefox codebase . There's nothing I found that indicates OS- or hardware-specific algorithms.

So that suggests to me that we shouldn't expect radically more fingerprinting than is already observed via the JS Math API (as we discuss in #13018). And, if we are able to find partial defenses for Math-based fingerprinting, such as bundling our own math libraries or setting certain compiler flags, then I would expect these would help to defend against Web Audio fingerprinting attacks as well.

It is possible, however, that the Web Audio API provides an efficient way to sample the space of floating point arithmetic operations to find differences between platforms that would be difficult to find manually. It's also possible that extensive use of somewhat complex numerical algorithms in the Web Audio source code and helper libraries provide more possibilities for floating point discrepancies than can be observed in the relatively simple JS Math interface. So in that sense this API might be a little extra dangerous.

The Web Audio API looks to me like something that would only have occasional legitimate uses. Most sites using audio do not need to do any sound processing on the fly. Many games need only to play sound samples, which can be done with <audio> elements and don't require Web Audio. Uses for Web Audio I can think of include 3D games or other immersive content, music sequencers or audio/video editing apps. So, because these are fairly unusual, I think one efficient defense would be to prompt the user before allowing content to instantiate an AudioContext object, very similar to how we prompt before HTML5 Canvas image extraction (#6253).

[cypherpunks]

Replying to arthuredelstein:

The Web Audio API looks to me like something that would only have occasional legitimate uses. Most sites using audio do not need to do any sound processing on the fly. Many games need only to play sound samples, which can be done with <audio> elements and don't require Web Audio. Uses for Web Audio I can think of include 3D games or other immersive content, music sequencers or audio/video editing apps. So, because these are fairly unusual, I think one efficient defense would be to prompt the user before allowing content to instantiate an AudioContext object, very similar to how we prompt before HTML5 Canvas image extraction (#6253).

I think the prompt is a good solution if indeed the Web Audio API reveals more about a browser/machine/OS than the JS Math interface. If not, fixing the JS Math interface should fix this problem? Not sure...

Thanks (all) for looking into this issue!

[mikeperry]

I have two points for further experimentation either here or #13018:

1. Can we find two Linux systems that have the same bit-width but different fingerprints here (Ie: debian/stable vs Fedora, or something with a large time difference between releases and differences in base system)
2. If so, a useful test would be testing if simply copying the same libm.so (found in either /lib/x86_64-linux-gnu/libm.so.6 or /usr/lib/x86_64-linux-gnu/libm.so on my system) onto both TBB's TorBrowser/Tor/ directory to see if the fingerprints here become identical again. That Tor directory should be in LD_LIBRARY_PATH, overriding the /lib search. You can check /proc/pid/maps to see if it got loaded.

This simple test would help us determine if we're just looking at math routine differences. In which case, we could ship the equivalent of a uniform set of math routines for all platforms for TBB, and use those instead.

[boklm]

I have been running the ​https://audiofingerprint.openwpm.com/ test on one computer with 3 different linux distributions using docker (so the same kernel was used): Fedora 22, Debian Jessie, Debian Wheezy.

The Fingerprint using DynamicsCompressor (sum of buffer values) line was the same in all cases: 35.74996018782258

The Fingerprint using DynamicsCompressor (hash of full buffer) was the same on Fedora 22 and Debian Jessie: 158e8189a3551fe4f2e564ac377b0f1e588a1ab3
But it was different on Debian Wheezy: 205ae8bb7897e9c9faa399d83bbcdc704a9962a1

After putting a copy of a libm.so.6 from Fedora in the Browser/TorBrowser/Tor/ directory and running it again on Wheezy, the hash of full buffer value became the same as on the 2 other distributions.

So it looks like the libm.so.6 used affects the hash of full buffer.

[cypherpunks]

Replying to boklm:

I have been running the ​https://audiofingerprint.openwpm.com/ test on one computer with 3 different linux distributions using docker (so the same kernel was used): Fedora 22, Debian Jessie, Debian Wheezy.

The Fingerprint using DynamicsCompressor (sum of buffer values) line was the same in all cases: 35.74996018782258

The Fingerprint using DynamicsCompressor (hash of full buffer) was the same on Fedora 22 and Debian Jessie: 158e8189a3551fe4f2e564ac377b0f1e588a1ab3
But it was different on Debian Wheezy: 205ae8bb7897e9c9faa399d83bbcdc704a9962a1

After putting a copy of a libm.so.6 from Fedora in the Browser/TorBrowser/Tor/ directory and running it again on Wheezy, the hash of full buffer value became the same as on the 2 other distributions.

So it looks like the libm.so.6 used affects the hash of full buffer.

What about Fingerprint using OscillatorNode and Fingerprint using hybrid of OscillatorNode/DynamicsCompressor method ?

When I tested it (see comment 22) those were all different from each other, haven't looked too closely if the values remained the same though.

[gk]

Moving items to August 2016.

[qSKvY]

I run browserprint.info which has these tests on it and can confirm that the tests appear to be stable among regular browsers.
We looked at sets of multiple fingerprints that were made by the same browser.
We found that "Fingerprint using DynamicsCompressor (sum of buffer values):", "Fingerprint using DynamicsCompressor (hash of full buffer):", and "AudioContext properties:" where very stable (between 1 and 10 instances out of ~500 of them changing between fingerprints).
The other two were less stable but the majority of the time they were consistent (56 and 87 instances of them changing between fingerprints out of ~500).

[gk]

Tickets for September.

[Octopus]

Hello! Developer of Fingerprint Central here!
The website is still in ​beta but thanks to several visitors, it seems that we can already have an early insight on some AudioContext attributes from the 40 TBB fingerprints that were collected. I added the tests found from the ​OpenWPM Study and you can see some results below that I found the most relevant.

N°	Count	Percentage	User-Agent	pxi buffer hash	ac-sampleRate	ac-maxChannelCount
1	21	60.00%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	158e8189...	44100	2
2	4	11.43%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	89cad797...	48000	2
3	3	8.57%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	4baefb24...	44100	2
4	1	2.86%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	89cad797...	96000	2
5	1	2.86%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	4baefb24...	48000	2
6	1	2.86%	"Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"	158e8189...	48000	2
7	1	2.86%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	e8a01cca...	44100	2
8	1	2.86%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	4baefb24...	44100	10000
9	1	2.86%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	158e8189...	44100	32
10	1	2.86%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	158e8189...	44100	0

I don't know if it can be generalized to the majority of the TBB population but it seems that most users should have the same combination of Sample rate/Channel count/Buffer hash. However, differences can still be observed between sample rate (44100Hz/48000Hz/96000Hz) and max channel count (0/2/32/10000) and users without the most common values may be more prone to fingerprinting than others. I added the hash to see if there was a link between these attributes and the rendered audio but this needs more investigation as noted by #comment:26.

[gk]

Moving tickets to October.

[gk]

Moving tickets over to November.

[gk]

Moving tickets to December.

[gk]

#20369 is a duplicate (note the getClientRects() angle there, too, which should be part of #18500).

[gk]

Moving our tickets to January 2017

[gk]

Moving our tickets to Feb 2017.

[gk]

We got a pref to disable that "feature" with Firefox 52 ESR in ​https://bugzilla.mozilla.org/show_bug.cgi?id=1288359. We might want to use that for now and keep thinking harder about a better solution.

[lessgo]

Based on 418 fingerprints of the Tor Browser only from FPCentral ​https://fpcentral.irisa.fr/customStats :

N°	Count	Percentage	User-Agent	pxi_full_buffer_hash	vc_output.ac-sampleRate	ac-maxChannelCount
1	163	39.00%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	158e8189a3551fe4f2e564ac377b0f1e588a1ab3	44100	2
2	104	24.88%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	-	-	-
3	28	6.70%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	89cad797b11193226dd0d1e580c3e94578d71130	48000	2
4	26	6.22%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	e8a01ccac064d752db0ae902529124d13313b336	44100	2
5	21	5.02%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	a79e5e1e31619aee22a69786bc8cb6265fb30a0c	44100	2
6	16	3.83%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	158e8189a3551fe4f2e564ac377b0f1e588a1ab3	48000	2
7	14	3.35%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	4baefb2460306064e9f6482daa4031c2d0680077	44100	2
8	12	2.87%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	89cad797b11193226dd0d1e580c3e94578d71130	44100	2
9	10	2.39%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	158e8189a3551fe4f2e564ac377b0f1e588a1ab3	44100	0
10	4	0.96%	"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"	4baefb2460306064e9f6482daa4031c2d0680077	44100	10000

[gk]

#21984 is a duplicate.

[arthuredelstein]

Replying to gk:

We got a pref to disable that "feature" with Firefox 52 ESR in ​https://bugzilla.mozilla.org/show_bug.cgi?id=1288359. We might want to use that for now and keep thinking harder about a better solution.

I like this approach. Here's a patch that sets the pref to false. And we could keep this ticket open to work on a patch to homogenize the fingerprint instead in the future.

​https://github.com/arthuredelstein/tor-browser/commit/13017

[gk]

Moving review tickets to May.

[gk]

Pushed to tor-browser-52.1.0esr-7.0-2 with commit ff923c1609c6bc4d9dd3a8b60f684d7c410a7399. Leaving this ticket open for a real fix, though.