Tor Browser is supposed to be blocking the Web Audio API, to block Audio Context fingerprinting.
However Audio Fingerprint Test - Detect Browser Audio Processing Capabilities is showing a fingerprint value. This fingerprint matches what Firefox is showing, which based on how this fingerprint works makes sense because both browsers are firefox based (Except Tor should be blocking offline audio context)
Tor is on the Safest browser security setting. This is concerning for the purpose of the Tor Browser. Asking for help from community and maintainers to understand why this is happening, if it is happening for others as well
audio fingerprinting is equivalency of platform architecture, which cannot be spoofed/hidden
you can use TZP to check, scroll down to the audio section.
There are 20 audioContext keys - 16 are hardcoded the same for all gecko browsers - and the other four are controlled with RFP - to make everyone the same (except for ac-outputLatency which is equivalency of platform i.e windows/linux/mac/android - which cannot be spoofed/hidden)
For audio tests involving waves etc - entropy comes from 2 places
One is from ac-sampleRate which is an audioContext key protected by RFP - RFP always reports and uses 44100
The other source of entropy is Math - floating point differences: the math library can differ between platforms and architectures. Audio uses a subset of Math functions and a limited range. The floating point entropy in audio is therefore equivalency, or a subset if you like, of Math
RFP forces all audio In gecko, all audio (it’s not a RFP thing) now uses the same math library across all platform architectures reducing differences to what cannot be spoofed/hidden (i.e equivalency) - see below, RFP audio only returns one of three possible results
That’s great, but because audio math is equivalency of Math (JS API), we need to patch that as well, and RFP does do that
tl;dr - there is no entropy in audio with RFP, only equivalency of platform architecture which cannot be hidden or spoofed (i.e there are two too many ways to determine this and lying about it just causes problems) x86_64/amd_64 vs ARM64/aarch64 vs x86/i686/ARMv7