1360039 - Spoof navigator.hardwareConcurrency = 2 when privacy.resistFingerprinting = true

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Arthur Edelstein [:arthur]]

navigator.hardwareConcurrency exposes private information about the user's computer in content scripts and content workers. When privacy.resistFingerprinting is set to true, we should always return the value "1".

In Tor Browser, I have proposed we do this by setting "dom.maxHardwareConcurrency" to "1" (see https://trac.torproject.org/21675). But a change in the value of this pref seems to be applied only after Firefox is restarted. So I would propose waiting for the value of privacy.resistFingerprinting to be propagated to workers (bug 1217238), and then we can make the effect "live".

Comment 1

[Chris Peterson [:cpeterson]]

According to the Firefox Hardware Report, 69% of Firefox users have 2 cores. Only 4% have 1 core. To make resistFingerprinting=true users appear less unique, we should consider spoofing navigator.hardwareConcurrency as 2 cores instead of 1.

https://metrics.mozilla.com/firefox-hardware-report/#goto-cpu-and-memory

Comment 2

[KOLANICH]

BTW, have you found a suitable way to overcome https://github.com/oftn-oswg/core-estimator ?

Comment 3

[Chris Peterson [:cpeterson]]

I have a patch for this bug.

Comment 4

[Chris Peterson [:cpeterson]]

Attachment: Bug 1360039 - Spoof navigator.hardwareConcurrency = 2 when privacy.resistFingerprinting = true.

Trackers use navigator.hardwareConcurrency as yet another source of entropy to fingerprint users. The Firefox Hardware Report says 70% of Firefox users have exactly 2 cores. When the privacy.resistFingerprinting pref is set, we want to blend into the crowd so spoof navigator.hardwareConcurrency = 2 to reduce user uniqueness. This pref was added in bug 1345322 for the Tor uplift project.

https://metrics.mozilla.com/firefox-hardware-report/#goto-cpu-and-memory

Review commit: https://reviewboard.mozilla.org/r/136410/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/136410/

Comment 5

[Chris Peterson [:cpeterson]]

Here is a Try run. None of the test failures are related to navigator.hardwareConcurrency. The updated navigator.hardwareConcurrency tests passed on all platforms.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0ece719517d4a67e1496b212e10b7c0e893106fa

Comment 6

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Comment on attachment 8864748 [details]
Bug 1360039 - Spoof navigator.hardwareConcurrency = 2 when privacy.resistFingerprinting = true.

https://reviewboard.mozilla.org/r/136410/#review139730

Comment 7

[Chris Peterson [:cpeterson]]

Thanks!

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a88c73f843dc
Spoof navigator.hardwareConcurrency = 2 when privacy.resistFingerprinting = true. r=qdot

Comment 9

[Arthur Edelstein [:arthur]]

Sorry I'm late to this.  This spoofs navigator.hardwareConcurrency for chrome calls, too, correct? It would be nice if we could somehow restrict spoofing to content.

Also, is calling nsContentUtils::ShouldResistFingerprinting() from worker threads OK? It seems like maybe we should be using Atomic<bool> so the compiler knows our intentions. Although I guess bools are already atomic so I'm not sure about the technicalities here.

Comment 10

[Chris Peterson [:cpeterson]]

(In reply to Arthur Edelstein [:arthuredelstein] from comment #9)
> Sorry I'm late to this.  This spoofs navigator.hardwareConcurrency for
> chrome calls, too, correct? It would be nice if we could somehow restrict
> spoofing to content.

RuntimeService::ClampedHardwareConcurrency() is only called from Navigator.cpp and WorkerNavigator.cpp. I don't see any browser chrome code calling navigator.hardwareConcurrency today, but it would be affected by privacy.resistFingerprinting if it did. It looks like RuntimeService.cpp could check if it is called by chrome code.

> Also, is calling nsContentUtils::ShouldResistFingerprinting() from worker
> threads OK? It seems like maybe we should be using Atomic<bool> so the
> compiler knows our intentions. Although I guess bools are already atomic so
> I'm not sure about the technicalities here.

nsContentUtils::ShouldResistFingerprinting() just returns a static bool, so it should be safe to call on worker threads. Whether we want to allow, architecturally, worker threads to call nsContentUtils functions is another question. dom/workers/RuntimeService.cpp already #included nsContentUtils.h before my patch.

Comment 11

[Iris Hsiao [:ihsiao]]

https://hg.mozilla.org/mozilla-central/rev/a88c73f843dc

Comment 12

[Chris Peterson [:cpeterson]]

Clearing needinfo about Chrome workers. That investigation is on my backlog, but I don't know when I will get to it..

Comment 13

[Tom Grabowski [:TomGrab]]

This was verified on the following Nightly build: 58.0a1 (2017-10-20) (64-bit)
OS: MacOS Sierra 10.12.6

Steps to reproduce:
1. Open a new tab.
2. Open Console tab in Developers Tools
3. Type this in console and press Enter: window.navigator.hardwareConcurrency (make sure this returns value different than 2; if the value is 2, you need to find a different computer that has number of cores different than 2)
4. Open another tab, and go to about:config
5. Find privacy.resistFingerprinting parameter and change it from false to true
6. In the first tab with the console, type the same command again: window.navigator.hardwareConcurrency

Expected result:
The returned number should be 2

Actual result:
The same as expected result.

Comment 14

[Tom Grabowski [:TomGrab]]

Marking it back as RESOLVED. We are going to test this on more operating systems before marking this as VERIFIED.