Enhance resist fingerprinting: Disable web audio (API) by default when privacy.resistFingerprinting is enabled
Categories
(Core :: Security, enhancement)
Tracking
()
People
(Reporter: Tom25519, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
I set privacy.resistFingerprinting to true in about:config, and did a test on https://coveryourtracks.eff.org
Actual results:
When web audio is enabled (dom.webaudio.enabled=true), the result is:
AudioContext fingerprint
35.7383295930922
Bits of identifying information: 2.73
One in x browsers have this value: 6.63
When it disabled (dom.webaudio.enabled=false), the result is:
AudioContext fingerprint
not available
Expected results:
dom.webaudio.enabled should be set to false when privacy.resistFingerprinting is enabled
I prefer randomize the fingerprint (if possible) rather than disable the web audio (API).
|
||
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Web Audio' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
(In reply to Johann Hofmann [:johannh] from comment #3)
Tom, is there already a bug for Web Audio + RFP?
No, I couldn't search a exiting bug with webaudio + fingerprinting.
|
||
Comment 5•4 years ago
|
||
There is not actually. It, along with the Math leakage I suppose, are well known enough to us that we never filed a bug.
Tor has not chosen to disable it; so we would not do that unless they wanted to change the behavior. Randomizing the calculations would not be effective unless we also randomized the underlying Math algorithms (sin(), tan(), etc)
I think it would be more valuable to ship a fixed floating point library for Tor Browser to use than to do the randomization, personally, but I'm afraid neither is something we have bandwidth to work on at the moment.
|
||
Comment 6•4 years ago
|
||
(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #5)
Tor has not chosen to disable it
I think that's a typo. Tor Browser set dom.webaudio.enabled to false
In terms of Firefox, I think for now that enforcing disablement of webaudio is not needed, and creates more problems that solutions. For example, it would break video conferencing. Canvas does as well, but at least that has a site exception.
The entropy from audio (a limited set and range of math functions) and math is not huge: not that we shouldn't do something about it. Can steven or someone run an experiment to gauge how many distinct values there are and what possible equivalency exists: in all my tests I've only ever seen two audio results (not counting audioContext keys) across all browsers. Or maybe set one up on ritter.vg and ask for submits: note some audio tests require user gestures
|
|
||
Comment 7•2 years ago
|
||
Because we will be fixing the webaudio fingerprint in Bug 1358149, I do not think we need to do this.
Description
•