Opened 4 years ago
Last modified 13 months ago
#13017 new task
Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector
Reported by: | mikeperry | Owned by: | arthuredelstein |
---|---|---|---|
Priority: | High | Milestone: | |
Component: | Applications/Tor Browser | Version: | |
Severity: | Major | Keywords: | tbb-fingerprinting |
Cc: | arthuredelstein, isis, mcs, brade, zevnull, RobinLinus, Sampei | Actual Points: | |
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
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
Child Tickets
Ticket | Status | Owner | Summary | Component |
---|---|---|---|---|
#20369 | closed | tbb-team | Persistence between Firefox and the Tor Browser for getClientRects and AudioContext fingerprint. | Applications/Tor Browser |
Change History (51)
comment:1 Changed 4 years ago by
Keywords: | TorBrowserTeam201409 added |
---|
comment:2 Changed 4 years ago by
Keywords: | tbb-easy added |
---|
comment:3 Changed 4 years ago by
Keywords: | TorBrowserTeam201409Easy added; TorBrowserTeam201409 removed |
---|
comment:4 Changed 4 years ago by
Keywords: | TorBrowserTeam201410 added |
---|
comment:5 Changed 4 years ago by
Keywords: | TorBrowserTeam201410Easy added; TorBrowserTeam201409Easy removed |
---|
comment:6 Changed 4 years ago by
Keywords: | TorBrowserTeam201410 removed |
---|
comment:7 Changed 4 years ago by
Keywords: | tbb-fingerprinting-os added; tbb-fingerprinting TorBrowserTeam201410Easy removed |
---|
comment:8 Changed 4 years ago by
Keywords: | ff38-esr added; ff31-esr removed |
---|---|
Summary: | Determine if AudioBuffers are a fingerprinting vector → Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector |
https://developer.mozilla.org/en-US/docs/Web/API/OfflineAudioContext may leak audio processing capabilities.
comment:9 Changed 4 years ago by
Keywords: | tbb-5.0a TorBrowserTeam201507 added |
---|
Tag the set of things we should have implemented before a full 5.0 launch, and add them to the July radar.
comment:10 Changed 4 years ago by
Keywords: | TorBrowserTeam201508 added; TorBrowserTeam201507 removed |
---|
comment:11 Changed 4 years ago by
Keywords: | ff38-esr tbb-5.0a TorBrowserTeam201508 removed |
---|
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.
comment:12 Changed 3 years ago by
Severity: | → Blocker |
---|
"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. "
comment:13 Changed 3 years ago by
Severity: | Blocker → Normal |
---|
comment:14 Changed 3 years ago by
Cc: | arthuredelstein added |
---|
comment:15 follow-ups: 16 18 Changed 3 years ago by
Priority: | Medium → Very High |
---|---|
Severity: | Normal → Critical |
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.
comment:16 follow-up: 17 Changed 3 years ago by
Priority: | Very High → Medium |
---|---|
Severity: | Critical → Normal |
Status: | new → needs_information |
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?
comment:17 Changed 3 years ago by
Priority: | Medium → Very High |
---|---|
Severity: | Normal → Critical |
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 ...
comment:18 Changed 3 years ago by
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
comment:19 Changed 3 years ago by
Keywords: | TorBrowserTeam201605 added |
---|---|
Owner: | changed from tbb-team to arthuredelstein |
Status: | needs_information → assigned |
Okay, we take a closer look and get to the bottom of it.
comment:20 Changed 3 years ago by
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.
comment:21 Changed 3 years ago by
Cc: | isis added |
---|
comment:22 Changed 3 years ago by
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
andLinux B
both had35.14587543532252
Windows
had35.145139578345606
Fingerprint using DynamicsCompressor (hash of full buffer)
Linux A
andLinux B
both had12a8c630cab33ce196f223822f4d23c59717abeb
Windows
had14b5e50593a946dbf54923aeefec7682156ea46c
Fingerprint using OscillatorNode
Linux A
,Linux B
andWindows
all had a different unique fingerprint.
Fingerprint using hybrid of OscillatorNode/DynamicsCompressor method
Linux A
,Linux B
andWindows
all had a different unique fingerprint as well.
Hope this helps.
comment:23 Changed 3 years ago by
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.
comment:24 Changed 3 years ago by
Cc: | mcs brade added |
---|
comment:25 follow-up: 26 Changed 3 years ago by
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).
comment:26 Changed 3 years ago by
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!
comment:27 Changed 3 years ago by
I have two points for further experimentation either here or #13018:
- 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)
- 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.
comment:28 Changed 3 years ago by
Keywords: | TorBrowserTeam201606 added; TorBrowserTeam201605 removed |
---|
comment:29 follow-up: 30 Changed 3 years ago by
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
.
comment:30 Changed 3 years ago by
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.
comment:31 Changed 3 years ago by
Keywords: | tbb-easy removed |
---|
comment:32 Changed 3 years ago by
Keywords: | TorBrowserTeam201607 added; TorBrowserTeam201606 removed |
---|
comment:33 Changed 3 years ago by
Keywords: | TorBrowserTeam201608 added; TorBrowserTeam201607 removed |
---|
Moving items to August 2016.
comment:34 Changed 3 years ago by
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).
comment:35 Changed 2 years ago by
Keywords: | TorBrowserTeam201609 added; TorBrowserTeam201608 removed |
---|
Tickets for September.
comment:36 Changed 2 years ago by
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.
comment:37 Changed 2 years ago by
Keywords: | TorBrowserTeam201610 added; TorBrowserTeam201609 removed |
---|
Moving tickets to October.
comment:38 Changed 2 years ago by
Keywords: | TorBrowserTeam201611 added; TorBrowserTeam201610 removed |
---|
Moving tickets over to November.
comment:39 Changed 2 years ago by
Keywords: | TorBrowserTeam201612 added; TorBrowserTeam201611 removed |
---|
Moving tickets to December.
comment:40 Changed 2 years ago by
Cc: | zevnull RobinLinus added |
---|
comment:41 Changed 2 years ago by
Keywords: | TorBrowserTeam201701 added; TorBrowserTeam201612 removed |
---|
Moving our tickets to January 2017
comment:42 Changed 2 years ago by
Keywords: | TorBrowserTeam201702 added; TorBrowserTeam201701 removed |
---|
Moving our tickets to Feb 2017.
comment:43 follow-up: 47 Changed 2 years ago by
Keywords: | ff52-esr added |
---|
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.
comment:44 Changed 23 months ago by
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 |
comment:46 Changed 22 months ago by
Keywords: | tbb-7.0-must added |
---|
comment:47 Changed 22 months ago by
Keywords: | TorBrowserTeam201704R added; TorBrowserTeam201702 removed |
---|---|
Status: | assigned → needs_review |
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
comment:48 Changed 22 months ago by
Keywords: | TorBrowserTeam201705R added; TorBrowserTeam201704R removed |
---|
Moving review tickets to May.
comment:49 Changed 22 months ago by
Keywords: | ff52-esr tbb-7.0-must TorBrowserTeam201705R removed |
---|
Pushed to tor-browser-52.1.0esr-7.0-2
with commit ff923c1609c6bc4d9dd3a8b60f684d7c410a7399. Leaving this ticket open for a real fix, though.
comment:50 Changed 13 months ago by
Keywords: | tbb-fingerprinting added; tbb-fingerprinting-os removed |
---|---|
Priority: | Very High → High |
Severity: | Critical → Blocker |
Status: | needs_review → new |
comment:51 Changed 13 months ago by
Severity: | Blocker → Major |
---|
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.