1728741 - navigator.hardwareConcurrency capped at 16

Status: RESOLVED FIXED

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

Description

[dangeredwolf]

Attachment: Output for Edge 95, Chrome 93, Firefox 91.0.2, on Arch Linux x86_64

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36

Steps to reproduce:

Run navigator.hardwareConcurrency and examine output

Actual results:

On Firefox Linux, it reported the number of physical instead of the number of logical cores.

(This effect may also occur on macOS, but for likely unrelated reasons, see Bug 1630089)

Expected results:

On Firefox Windows, Chromium browsers on Windows or Linux, it will report as the number of logical cores.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[dangeredwolf]

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #1)

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[dangeredwolf]

WHATWG spec also calls for reporting the number of logical processors, in addition to other vendor implementations
https://html.spec.whatwg.org/multipage/workers.html#dom-navigator-hardwareconcurrency-dev

Comment 4

[dangeredwolf]

In doing further testing I found this does not seem to affect Intel CPUs. It only affected my AMD Ryzen system and does not effect Intel. I am not sure if it is only certain CPU generations (Mine is Zen 2) or if it is for all AMD CPUs.

Comment 5

[dangeredwolf]

Sorry, I think I misdiagnosed the issue before. I have done some additional testing and found that it caps to 16 cores regardless of OS and hardware configuration. As long as you have more than 16 logical processors, it will always report 16, including on Windows. Chromium-based browsers will report the real number of logical processors.

Comment 6

[dangeredwolf]

You seem to be able to configure the maximum in about:config. Still, the default configuration goes against WHATWG recommendations.

Comment 7

[Robert Longson [:longsonr]]

Presumably WONTFIX for the reasons outlined in bug 1286895

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

https://searchfox.org/mozilla-central/rev/55e8eba74b60b92d04b781f7928f54ef76b13fa9/modules/libpref/init/all.js#4241
Some background also in bug 1008453

tjr might have an opinion, but I don't quite see why the limit 16.
If I read the code correctly, https://hg.mozilla.org/mozilla-central/rev/feb0e93ac30d#l5.13 was used as the limit, then
it was removed and then later
https://hg.mozilla.org/mozilla-central/rev/1a91a95d5db4#l5.34 was introduced.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1728741, increase max navigator.hardwareConcurrency, r=tjr

Comment 10

[Tom Ritter [:tjr]]

I have an opinion =)

Increasing the max (possible) reported count will make a minority of users' fingerprints more unique. Yes, fingerprinting is a problem and it's hard to fix that problem, but where we can we shouldn't make the problem worse. So I think the question to ask before we do it is: Why?

Do we have an example of a somewhat-common website that is made significantly better by telling them the user has e.g. 32 cores instead of 16?

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Changing severity to S3 because this looks like not a critical problem for most users. Feel free to set other values if I'm wrong.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Based on https://caniuse.com/hardwareconcurrency webkit either reports 2 or 8 or the feature is disabled altogether.

Comment 13

[Gian-Carlo Pascutto [:gcp]]

Do we have an example of a somewhat-common website that is made significantly better by telling them the user has e.g. 32 cores instead of 16?

I'm analyzing chess games on lichess.org and Chrome is about 50% faster because it correctly reports 24 cores, whereas we cap to 16. This is made worse because this is an Alder Lake system and Linux misschedules the 16 threads to 8 real cores (instead of 16).

Comment 14

[Gian-Carlo Pascutto [:gcp]]

In the same context and usage, the analysis engine there is limited to 32MB of memory usage because we don't support navigator.deviceMemory (Chrome allows up to 1GB) - I assume for similar fingerprinting concerns. But it does lead to those sites being crippled/slower in Firefox.

Comment 15

[Thorin [:thorin]]

that sounds like an easy perf win

• add a deviceMemory in navigator shim and always report e.g. 512MB for desktop and e.g. 256MB for android (made up values), noting that we can't hide the platform

hardwareConcurrency

• I think we could tailor RFP to use a different value for android - returning 2 is low, IDK if that affects perf
• what are the ramifications of raising the floor here and limiting to a smaller set while still raising the ceiling, e.g. values must be 4, 8, 16, 24 - what happens to 1 or 2 core machines
  • and adjust RFP accordingly

FYI: hardware stats show - https://data.firefox.com/dashboard/hardware

 1 core:  2.14%
 2 core: 49.54%
 4 core: 35.03%
 6 core:  8.17%
 8 core:  3.81%
 other :  1.31%

Comment 16

[Tom Ritter [:tjr]]

FWIW; this bug is not really about RFP. We can do whatever we want with RFP and keep the static value at 2 - this bug is about changing the value for the pref that defines what we cap the processor count to for normal operation.

I can't speak to device memory at the moment; that's over in Bug 1629868. I don't know why we haven't implemented it; I've not been privy to any discussions about it RE fingerprinting or anything like that.

Given that we got our example of something that would really benefit from this; I think it's reasonable to land this. Again; this doesn't affect RFP or Tor.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4b982ccfadae
increase max navigator.hardwareConcurrency, r=tjr

Comment 18

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/4b982ccfadae

Comment 19

[Cristian Tuns]

Backed out for causing Bug 1745425

• Backout link

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

Unfortunately bug 1745425 still occurs if hardwareConcurrency is changed.