FYI: 2510: webaudio

[Thorin-Oakenpants]

This is just so I can outline my reasons for moving 2518 2510 to RFP alts and making it inactive within that section

webaudio results within Firefox, AFAICT, are very low, if they exist at all on desktop

There are essentially two parts: one that does not require user gestures (offlineAudioContext), and one that does (AudioContext). But given that it's not exactly hard to elicit a user gesture, we could probably ignore that distinction except to say that scripts don't like to hang around waiting for user gestures IMO and be dependent on them

---

🔻 offlineAudioContext

takes a wave (sine, triangle) at volume zero, at a set frequency and other variables and fingerprints it. This explains it nicely

What causes entropy here is supposed to only be math libraries used and floating points. It is not supposed to touch the hardware. The webaudio API uses a limited set of math functions with a limited range. Any entropy here is almost certainly already present elsewhere (math)

I say supposed to, but it has been shown that chromium browsers results are affected by the CPU (or something), despite using the same method, calculations, math libraries etc across all platforms.

124.04344884395687 : chromeOS 84
124.04347527516074 : windows + android10
124.04347721464    : chromeOS 89
124.04347657808103 : macOS BigSur 11.3 + ungoogled chromium
124.0434806260746  : macOS 11
124.08074500028306 : android 7, 9
124.08075528279005 : android 10+11

I've personally seen the fingerprint change after a kernel update on android (that's my android10 results above). In testing math entropy, I (and others) can't seem to find any in chromium

Firefox and chromium implement webaudio different math libraries and how they calculate things: e.g.

• Chromium computes this using fdlibm::pow,
• final_playback_rate *= fdlibm::pow(2, detune_->FinalValue() / 1200);
• while Firefox uses the C++ stdlib's exp2
• float computedPlaybackRate = aPlaybackRate * exp2(aDetune / 1200.f);

chromium even includes a test in-tree for checking that the webAudio fingerprint matches a hardcoded one

• https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/webaudio/webaudio_browsertest.cc

On the flip side

• Firefox has math entropy, see this which is OS dependent - and you can't hide your OS. There is some entropy in Linux distros and in windows at least 32bit builds on a 64bit system throws differences (but why do that?). Android is the worst offender here, and this repo is not about android
  • in other words, linux (two), windows (effectively one) and mac (one) math entropy is low. Android is a mess
• HOWEVER Firefox doesn't seem to have any webaudio entropy along these lines: because webaudio uses a limited set of math functions and limited ranges
  • I have seen Mac, lots of Linux VM's, a number of bare metal Linux from other users, multiple Windows tests, and android (limited due to device access) all return the same values

This is practically the reverse of what chromium shows. Chromium seems to be affected by hardware, but FF isn't: but chromium has no math entropy, while FF does.

Anyway, the fact remains that FF entropy from webaudio seems unlikely for desktop, and if it does exist it will be a very few possible results (not that each result has equal users). A disabled webaudio API is going to be much more fingerprintable than not disabling it

---

🔻 AudioContext

This has two aspects: one is keys, the other is computational, and relies on some reported key values AFAIK. RFP covers at least two of these keys: ac-outputLatency is calculated per OS, and ac-sampleRate is returned as 44100

Much less data to go on from my perspective, but with RFP enabled, I haven't seen any different values aside from the RFP ones across platforms, and not in the computation hashes.

Note: Android (without RFP) is wonky: 1612093 and returns different values on each run .. but we don't care about android parity here

---

🔻 real-world study

title: Who Touched My Browser Fingerprint?: A Large-scale Measurement Study and Classification of Fingerprint Dynamics
url: https://dl.acm.org/doi/10.1145/3419394.3423614
pdf: https://yinzhicao.org/fpmeasurement/imc20.pdf

interesting static values' distinct groups

• font list 115k
• user agent 41k
• ...
• pixel ratio 2k
• language list 1.2k
• audio 114 <-- (23 of those were unique)

AFAICT, that audio test is about audioContext keys, if you read the paper. The point is that audio is one of the lowest entropy items around, and that's not even when you factor in the browser and OS (which you can't hide)

---

🔻 tl;dr

Generally speaking, we value security over privacy/tracking over fingerprinting. But even from a FPing perspective, disabling the API is going to be much worse: e.g. out of 200+mn desktop users, how many would disable webaudio? A tiny percentage of less than 1% is my educated guess. Not to be confused with Tor Browser, which can do what it likes for an enforced set of users.

Also, keep in mind that RFP randomized canvas (which almost all FP scripts use), and that most scripts are (for now) naive, and thus swallow that random poison pill. Arkenfox doesn't claim to defeat advanced scripts, but an enabled webaudio is going to be less identifying than a disabled one.

There is also the usability factor, of one less item to flip or troubleshoot

---

🔻 FYI

test: https://arkenfox.github.io/TZP/tzp.html#audio
note: I'm going to totally destroy that test and replace it, so don't get too attached to it

The fingerprint, with RFP on is as follows. offlineAudioContext should be the same across platforms AFAICT, but AudioContext may differ per platform (which is just equivalency since you cannot hide your OS, not entropy)

windows

offlineAudioContext
 getChannelData : e7db5be25cc724e6a5b7bb842170131dcf7a8598
copyFromChannel : e7db5be25cc724e6a5b7bb842170131dcf7a8598
            sum : 35.7383295930922

AudioContext
                     audioContext : 351a1ada89f7dafbd8a38f1e09f67505578c9442 [20 keys]
                   OscillatorNode : 247e9af1788fd5dca82f2139619cc7bd7e3be6ea
OscillatorNode/DynamicsCompressor : c01a57eaf6ffa6bed3e5dbf3fbb56873cfd02581

feel free to post you results and OS info, especially if they differ

[2glops]

Firefox 89.0.1 (64-bit) Linux Debian

offlineAudioContext
getChannelData : 4460bdcbe1cb161b6f9bd804565c8ecbaa2c4da6
copyFromChannel : 4460bdcbe1cb161b6f9bd804565c8ecbaa2c4da6
sum : 35.73833402246237

AudioContext
audioContext : fdb6f2cb10e8f42e073ef8b99345d739986ec390 [20 keys]
OscillatorNode : 247e9af1788fd5dca82f2139619cc7bd7e3be6ea
OscillatorNode/DynamicsCompressor : d7db6f9e9102bc7989a56dc42ab48cd9a1be60b2

All differs from Windows except OscillatorNode on AudioContext

[Thorin-Oakenpants]

Thanks.

• offline: There's some math entropy in Linux distros. and this is likely it. I'll know more when I rebuild the audio test and get some recorded data.
• audio keys: they will differ per OS (linux, adroid etc) due to ac-outputLatency: it'll be interesting to see if any of the other 18 keys differ
• OscillatorNode: yeah that seems stable (with RFP)
• DynamicsCompressor: IDK. RFP certainly changes it but not sure if the result (regardless of RFP) is just equivalency

[rusty-snake]

FWIW: Same results with Firefox 89.0; 64-bit; Fedora 34; glibc 2.33

[Thorin-Oakenpants]

@rusty-snake : do you mean same results as I listed in OP?

I was going to say something about 2glop's debian result, as the math entropy shows Fedora and Debian to be the same [1]. But I pinky swear from memory that I've been given a Fedora audio result before that matched Windows (at least on offlineAudio and keys) .. but since I can't find it, I thought I would just shut up and wait til I get some recorded data - so that just makes me wonder what else if anything can touch the result (e.g. like chromium)

[1] code FF30: Linux 64bit: Debian (Buster) Fedora (v32), Manjaro (20.1), MX Linux: all FF80+

[rusty-snake]

@rusty-snake : do you mean same results as I listed in OP?

Same as @2glops

[Thorin-Oakenpants]

Same as @2glops

Ahh OK. That makes more sense. It's equivalency already leaked in math

[Thorin-Oakenpants]

FYI: also for #1216

paper: A Study of Feasibility and Diversity of Web Audio Fingerprints
link: https://arxiv.org/abs/2107.14201
pdf: top right
study: March-May 2021

Looking at section C: Breakdown of Audio FPs by user agents, I count the following for Firefox

• they used HTTP headers for browser info, and we can assume no-one lied
  

So the bottom four items are "new" methods they tested which overall looks increased entropy. TBH, I thought android would yield a lot more. So that's about it.

The TZP test is basically the one used in the wild by most scripts, based on OpenWMP. FWIW it's not as sophisticated as it could be, and I've even seen a win/linux match which is either a missed result, or simply not defined enough - edit: that is the Dynamics Compressor type of test. I'm going to be rebuilding the audio test on TZP, so this is where I'll be heading - seven tests for a combined FP

The good news is that webaudio FPing may soon be resolved with RFP, fingers crossed. Until then looks like (not sure what they are all combined) windows is potentially the worst at 6 results (5 win and 1 win/mac), mac at 3 or 4, linux at 3, and android at 2.

[Thorin-Oakenpants]

The above paper's entropy for Firefox is solely for user-gesture-required AudioContext

I contacted the authors, and got their test code and data. Their test also collected the offlineAudioContext - which requires no user gestures - the one where you get a sum like 35.73833402246237 - but that data was missing in their dump they shared, because that's not what they analyzing. So I asked them for it. I got it. I analyzed it. Here's the gecko results

// android
   // 2 results
      35.7499681673944

// windows
   // 20 results: NT 6.1/6.2/6.3/10.0; v68-88"
      35.7383295930922

// mac 
   // 7 results: 10.10, 10.11, 10.12, 10.13, 10.15; v78-88
      35.7383295930922  <- same as windows
   // 1 result: 11.2; v86
      35.73833039775491
   // 1 result: hybrid values whatever that means mac 10.15; v87
      35.73833039775491  <-- same as other mac value
      35.7383295930922    <-- same as windows

// linux
   // 3 results: ubuntu v72-88"
      35.73833402246237
   // 1 result: ubuntu v77"
      35.74996018782258

in other words: 5 buckets (although linux and android tests are a bit sparse to say the least), and mostly OS equivalency

      35.7383295930922 // mac/windows
      35.73833039775491 // mac
      35.73833402246237 // linux
      35.74996018782258 // linux
      35.7499681673944 // android