Opened 3 years ago

Last modified 5 months ago

#13017 needs_review task

Determine if AudioBuffers/OfflineAudioContext are a fingerprinting vector

Reported by: mikeperry Owned by: arthuredelstein
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Critical Keywords: tbb-fingerprinting-os
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

TicketStatusOwnerSummaryComponent
#20369closedtbb-teamPersistence between Firefox and the Tor Browser for getClientRects and AudioContext fingerprint.Applications/Tor Browser

Change History (49)

comment:1 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201409 added

comment:2 Changed 3 years ago by mikeperry

Keywords: tbb-easy added

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.

comment:3 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201409Easy added; TorBrowserTeam201409 removed

comment:4 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201410 added

comment:5 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201410Easy added; TorBrowserTeam201409Easy removed

comment:6 Changed 3 years ago by mikeperry

Keywords: TorBrowserTeam201410 removed

comment:7 Changed 3 years ago by mikeperry

Keywords: tbb-fingerprinting-os added; tbb-fingerprinting TorBrowserTeam201410Easy removed

comment:8 Changed 2 years ago by gk

Keywords: ff38-esr added; ff31-esr removed
Summary: Determine if AudioBuffers are a fingerprinting vectorDetermine if AudioBuffers/OfflineAudioContext are a fingerprinting vector

comment:9 Changed 2 years ago by mikeperry

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 2 years ago by mikeperry

Keywords: TorBrowserTeam201508 added; TorBrowserTeam201507 removed

comment:11 Changed 2 years ago by mikeperry

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 16 months ago by mo

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. "

https://audiofingerprint.openwpm.com/

comment:13 Changed 16 months ago by mo

Severity: BlockerNormal

comment:14 Changed 16 months ago by arthuredelstein

Cc: arthuredelstein added

comment:15 Changed 16 months ago by cypherpunks

Priority: MediumVery High
Severity: NormalCritical

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.

Last edited 16 months ago by cypherpunks (previous) (diff)

comment:16 in reply to:  15 ; Changed 16 months ago by gk

Priority: Very HighMedium
Severity: CriticalNormal
Status: newneeds_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 in reply to:  16 Changed 16 months ago by cypherpunks

Priority: MediumVery High
Severity: NormalCritical

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 ...

Last edited 16 months ago by cypherpunks (previous) (diff)

comment:18 in reply to:  15 Changed 16 months ago by 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

comment:19 Changed 16 months ago by gk

Keywords: TorBrowserTeam201605 added
Owner: changed from tbb-team to arthuredelstein
Status: needs_informationassigned

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

comment:20 Changed 16 months ago by 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.

comment:21 Changed 16 months ago by isis

Cc: isis added

comment:22 Changed 16 months ago by 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.

Last edited 16 months ago by cypherpunks (previous) (diff)

comment:23 Changed 16 months ago by 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.

comment:24 Changed 16 months ago by mcs

Cc: mcs brade added

comment:25 Changed 16 months ago by 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).

comment:26 in reply to:  25 Changed 16 months ago by 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...

Version 0, edited 16 months ago by cypherpunks (next)

comment:27 Changed 16 months ago by 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.

comment:28 Changed 16 months ago by gk

Keywords: TorBrowserTeam201606 added; TorBrowserTeam201605 removed

comment:29 Changed 16 months ago by 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.

comment:30 in reply to:  29 Changed 16 months ago by 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.

Last edited 16 months ago by cypherpunks (previous) (diff)

comment:31 Changed 15 months ago by gk

Keywords: tbb-easy removed

comment:32 Changed 15 months ago by gk

Keywords: TorBrowserTeam201607 added; TorBrowserTeam201606 removed

comment:33 Changed 14 months ago by gk

Keywords: TorBrowserTeam201608 added; TorBrowserTeam201607 removed

Moving items to August 2016.

comment:34 Changed 14 months ago by 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).

comment:35 Changed 13 months ago by gk

Keywords: TorBrowserTeam201609 added; TorBrowserTeam201608 removed

Tickets for September.

comment:36 Changed 13 months ago by 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°CountPercentageUser-Agentpxi buffer hashac-sampleRateac-maxChannelCount
12160.00%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"158e8189...441002
2411.43%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0" 89cad797...480002
338.57%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0" 4baefb24...441002
412.86%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0" 89cad797...960002
512.86%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0" 4baefb24...480002
612.86%"Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0" 158e8189...480002
712.86%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0" e8a01cca...441002
812.86%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0" 4baefb24...4410010000
912.86%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0" 158e8189...4410032
1012.86%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0" 158e8189...441000

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 12 months ago by gk

Keywords: TorBrowserTeam201610 added; TorBrowserTeam201609 removed

Moving tickets to October.

comment:38 Changed 11 months ago by gk

Keywords: TorBrowserTeam201611 added; TorBrowserTeam201610 removed

Moving tickets over to November.

comment:39 Changed 10 months ago by gk

Keywords: TorBrowserTeam201612 added; TorBrowserTeam201611 removed

Moving tickets to December.

comment:40 Changed 9 months ago by gk

Cc: zevnull RobinLinus added

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

comment:41 Changed 8 months ago by gk

Keywords: TorBrowserTeam201701 added; TorBrowserTeam201612 removed

Moving our tickets to January 2017

comment:42 Changed 8 months ago by gk

Keywords: TorBrowserTeam201702 added; TorBrowserTeam201701 removed

Moving our tickets to Feb 2017.

comment:43 Changed 6 months ago by gk

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 6 months ago by lessgo

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

CountPercentageUser-Agentpxi_full_buffer_hashvc_output.ac-sampleRateac-maxChannelCount
116339.00%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"158e8189a3551fe4f2e564ac377b0f1e588a1ab3441002
210424.88%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"---
3286.70%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"89cad797b11193226dd0d1e580c3e94578d71130480002
4266.22%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"e8a01ccac064d752db0ae902529124d13313b336441002
5215.02%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"a79e5e1e31619aee22a69786bc8cb6265fb30a0c441002
6163.83%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"158e8189a3551fe4f2e564ac377b0f1e588a1ab3480002
7143.35%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"4baefb2460306064e9f6482daa4031c2d0680077441002
8122.87%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"89cad797b11193226dd0d1e580c3e94578d71130441002
9102.39%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"158e8189a3551fe4f2e564ac377b0f1e588a1ab3441000
1040.96%"Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"4baefb2460306064e9f6482daa4031c2d06800774410010000

comment:45 Changed 5 months ago by gk

Cc: Sampei added

#21984 is a duplicate.

comment:46 Changed 5 months ago by gk

Keywords: tbb-7.0-must added

comment:47 in reply to:  43 Changed 5 months ago by arthuredelstein

Keywords: TorBrowserTeam201704R added; TorBrowserTeam201702 removed
Status: assignedneeds_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 5 months ago by gk

Keywords: TorBrowserTeam201705R added; TorBrowserTeam201704R removed

Moving review tickets to May.

comment:49 Changed 5 months ago by gk

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.

Note: See TracTickets for help on using tickets.