Javascript reveals your CPU cores number (even with a CPU override option) as we can see here :
So I found out an option to fake this, in about:config, limit "dom.workers.maxPerDomain" to the number that you want (0 = no threads (Tor displays no threads with these websites)) and restart Firefox.
EDIT : This thing has been integrated only since the 48 version of Firefox, I tested with the 47 version and it displays no threads, like Tor. (there is no line "Hardware Concurrency" in browserleaks while there is one in the 48)
So if you're using a useragent that displays a version prior to 48, you should logically put 0.
Hmm. It sounds like the dom.workers.maxPerDomain might actually affect Firefox's performance.
Tor Browser has this settings at 20 but probably just spoofs it to the sites.
The user agent MAY report fewer than the number of actual logical processors to reduce the efficacy of fingerprinting.
https://wiki.whatwg.org/wiki/NavigatorCores#Privacy_considerations
Somewhat related: #13027 (Make WebWorkers use spoofed navigator.* useragent values)
I don't think dom.workers.maxPerDomain is the answer here, as Tor Browser also has it at 20. What is the proper method to deter this fingerprinting?
dom.workers.maxPerDomain set to 0 is an incorrect choice.
Deterring methods
Like https://github.com/pyllyukko/user.js/issues/128 it's Webworkers that test your browser. These scripts ignore the webpage CSP and
you can limit them by injecting CSP Policies, like explained here.
I don't know yet if Request Policy has similar features.
What is the proper method to deter this fingerprinting?
privacy.resistFingerprinting [FF55+ .. only 7 more weeks to go, hang in there!!]
** spoof navigator.hardwareConcurrency as 2 (FF55+)
This spoof *shouldn't* affect core chrome/Firefox performance
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1360039
They use 2 since that is the most common metric - https://metrics.mozilla.com/firefox-hardware-report/
Meanwhile: DON'T use this one - fairly sure (and not just me) that this will cripple/affect performance - imagine having 16 cores and being limited to 2 [we could of course be wrong about this - I've never tested e10s with this pref etc, but now 54 is here, maybe someone could have a play]
/* 2514: spoof (or limit?) number of CPU cores (also see 2699f) (FF48+)
* [WARNING] *may* affect core chrome/Firefox performance, will affect content.
* Highly recommended to leave this (dom) and use 2699f (navigator)
* [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1008453
* [2] https://trac.torproject.org/projects/tor/ticket/21675
* [3] https://trac.torproject.org/projects/tor/ticket/22127
* [4] https://html.spec.whatwg.org/multipage/workers.html#navigator.hardwareconcurrency ***/
// user_pref("dom.maxHardwareConcurrency", 2);
Meanwhile ... https://bugzilla.mozilla.org/show_bug.cgi?id=1333933 which was going to enforce pref values for privacy.resistFingerprinting, has been dropped effectively in favor of enforcing it in code (see the first code snippet above re ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1360039). This ticket listed dom.maxHardwareConcurrency as one of the prefs to flip.
So .. all in all, if anyone has 55, enable privacy.resistFingerprinting, make sure dom.maxHardwareConcurrency is at default, enable e10s .. set process numbers if needed ... and test a) spoofed value = 2 b) cores/processes used is not affected
Since latest versions of Tor Browser, the default value of dom.maxHardwareConcurrency is set to 1, maybe now we should do so for Firefox?
Since latest versions of Tor Browser, the default value of dom.maxHardwareConcurrency is set to 1, maybe now we should do so for Firefox?
Thanks for bumping. It's done now. Commit 2a5aa109f71b2805ed18cb14f444fc48363e6dcc also relates 馃槤
This should IMO be 2, not 1. This is not the Tor browser, it is Firefox and you cannot hide that. The best metric is 2 (most common) and will have less impact on FF itself. RFP also uses 2.
The best metric is 2 (most common) and will have less impact on FF itself. RFP also uses 2.
Fixed in f625e4aae8adfd9de355b32db6b84c23de10442b. Thanks!
Most helpful comment
privacy.resistFingerprinting [FF55+ .. only 7 more weeks to go, hang in there!!]
They use 2 since that is the most common metric - https://metrics.mozilla.com/firefox-hardware-report/
Meanwhile: DON'T use this one - fairly sure (and not just me) that this will cripple/affect performance - imagine having 16 cores and being limited to 2 [we could of course be wrong about this - I've never tested e10s with this pref etc, but now 54 is here, maybe someone could have a play]
Meanwhile ... https://bugzilla.mozilla.org/show_bug.cgi?id=1333933 which was going to enforce pref values for privacy.resistFingerprinting, has been dropped effectively in favor of enforcing it in code (see the first code snippet above re ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1360039). This ticket listed
dom.maxHardwareConcurrencyas one of the prefs to flip.So .. all in all, if anyone has 55, enable
privacy.resistFingerprinting, make suredom.maxHardwareConcurrencyis at default, enable e10s .. set process numbers if needed ... and test a) spoofed value = 2 b) cores/processes used is not affected