Closed Bug 1984333 Opened 8 months ago Closed 8 months ago

Bump Spoofed Processor Count

Categories

(Core :: Privacy: Anti-Tracking, task, P3)

Product:
Core
Component:
Privacy: Anti-Tracking
Type:
task

Tracking

()

Status:
VERIFIED FIXED
Milestone:
144 Branch
Tracking Flags:
Tracking Status
firefox143 --- verified
firefox144 --- verified

People

(Reporter: fkilic, Assigned: fkilic)

References

Details

Attachments

(1 file, 1 obsolete file)

Bug 1984333 - Spoof CPU cores to 4, or 8 if the machine has 8+ cores. r?timhuang
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
Details | Review

Due to regressions in 1978414, we are going to explore ways of bumping the spoofed CPU cores.

Attachment #9508451 - Attachment description: Bug 1984333 - Bump spoofed CPU cores to 4. r?timhuang → Bug 1984333 - Spoof CPU cores to 4, or 8 if the machine has 8+ cores. r?timhuang

see also Bug 1957254 where RFP (and FPP can follow it's own rules) we are waiting on some telemetry to decide what to spoof per platform

See Also: → 1957254

(In reply to Thorin [:thorin] from comment #2)

see also Bug 1957254 where RFP (and FPP can follow it's own rules) we are waiting on some telemetry to decide what to spoof per platform

I checked the data per OS. Except for OSX, the most popular is 4 then 8. On OSX, the most popular is 8 then 4. I asked it on IRC but maybe it got lost. I'll update the 4 to 8 for OSX for RFP.

I'll update the 4 to 8 for OSX for RFP

To clarify

  • FPP: return 4 else return 8 if real processor count is 8 or higher
  • RFP
    • currently all = 2
    • proposed: return 8 on mac else return 4

right? Did you know there's something about logical cores vs physical on macs? And they report double or something? IANAE on processors

I also don't know a lot about CPU cores, but the data is based on what we report to the web, so to me, returning 8 makes sense whether it reports twice or not.

And yes, FPP will still stick to reporting 8 if cores >= 8, else 4. RFP is also correct, return 8 on mac else 4.

based on what we report to the web

depends on how you collected the data - it's all relative. Bug 1630089 resolve incomplete

proposed: return 8 on mac else return 4

I'd be happy with that in Bug 1957254 (or here if it's easier) and hopefully backported for ESR for Tor Browser

cc'ing pier

Our collection uses the same method as navigator.hardwareConcurrency.

system report says 6 efficiency 6 performance. firefox reports 12 on my machine and so does chrome. safari reports 8 though.

I'd be happy with that in Bug 1957254 (or here if it's easier)

I updated the patch to 8 after the comment #2. So, here is easier hahaha

Interesting, Safari, by default, does what we are doing. And as an added privacy, they do 1 + random(min: 0, max: 63) based on privacy settings

Pushed by chorotan@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/036edae43444 https://hg.mozilla.org/integration/autoland/rev/f35bac84cb1d Revert "Bug 1984333 - Spoof CPU cores to 4, or 8 if the machine has 8+ cores. r=timhuang" on request by fkilic

thank you!

Flags: needinfo?(fkilic)

system report says 6 efficiency 6 performance. firefox reports 12 on my machine and so does chrome. safari reports 8 though

I wonder if safari is spoofing, otherwise that seems weird, but IANAE! Good to see us matching blink, yay - so that old bug must have been resolved since? IIUIC, good to know the collected data is the same as reported, so we're all good :) Thanks

edit: ugh, just read comment 8 re safari spoofing

yeah safari is spoofing. my message about it got lost between all my pushes and reverts etc.

1 + random(min: 0, max: 63)

sorry for the noise, but I just want to say that Brave goes all in on their farbling, and now it seems as if Safari is also going down this road. I hope we don't. I get it to an extent - the more randomized items, the greater the chance a script becomes naive (and swallows the poisoned metric). This is one metric that is very hard to determine by any other means (especially with timing protections), so it's a good choice if there ever was one (excluding canvas/webgl where that is the only solution). I also get it in the sense that since the random seed per session etc is all engineered, why not use it liberally - Brave does this and I have to say, many if not most of their randomness can easily be reversed (not necessarily meaning the protection is exposed - e.g. random fonts allowed is a hardcoded list in Brave, but fonts themselves are still limited). I keep seeing the same errors and pitfalls with randomizing across all three engines - and even when they get it right (no leaks), it can still be detected and is often not benign - e.g. what would you think of 41 or 27 or 63 processors on a mac - utter nonsense (and I would think macs have a limited set of real world values anyway) - we (mozilla) can be smarter than that

Yeah I agree. I mean when you look at fingerprint js for example, their code is mostly like the following (I obviously made this code up but it is similar):

function getCPUCount() {
  if (webkit) {
    // WebKit lies about cpu core count, so don't include it.
    return -1;
  }
  ....
}

Since the point of "fingerprintable metric" inclusion is whether an engine lies or not (i.e. doesn't matter if it randomizes or returns the same value, in the end, it is useless), it doesn't matter if you return a hardcoded value or randomize it to a value from 0 to 999 bajillion. So, for web compat at least, it makes more sense to return values that make sense.

I would communicate this to Tom specifically though (not that he is against it or anything, but the decision making is more on him)

scripts don't even have to be stable - fingerprints are not hashes, they're objects full of data and metrics can be weighted/discarded/changed on the backend

it doesn't matter if you return a hardcoded value or randomize it to a value from 0 to 999 bajillion

that's what we (or I) call an advanced script - that is the randomizing is detected, so it is in essence now a stable metric - e.g. EFF has a lot to answer for, they claim randomizing is the bees knees and base their quality of protection on how many items are randomized - they did this as Brave started farbling everything (not saying they did this FOR brave, but because of Brave) - but then they undermine their message by detecting the randomizing and showing how trivial it is to do that - and then fail to convey this to the users - they have done a lot of damage with this along with their numbers for entropy and information bits

Since the point of "fingerprintable metric" inclusion is whether an engine lies or not

I think the easiest way to explain this is: the point of FPing protection is to protect the real value: doesn't matter how it does it in order to achieve that. But then there are other considerations, such as compat or triggering fraud/bot protection (non benign values), or code complexity and other risks.

There are very few things I would randomize (canvas, webgl's readpixels is probably it), as it's all detectable - case in point, see safari and processors. It simply isn't worth the complexity or risk :)

/end of noise (hopefully)

Attachment #9508925 - Attachment is obsolete: true
Regressions: 1984784

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

Status: ASSIGNED → RESOLVED
Closed: 8 months ago
status-firefox144: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 144 Branch

something broke unless I am missing something (my real value is 8: windows platform)

  • beta 143 with ETP strict returns 2
  • nightly built from https://hg.mozilla.org/mozilla-central/rev/6a6ff28c88f1730bd60a0d8a4427591501841f03
    • with ETP strict: returns 8
    • expected 4
Flags: needinfo?(fkilic)

nvm - got it in the next update

Flags: needinfo?(fkilic)

Just to be clear, with ETP strict (privacy.fingerprintingProtection = True), on a platform with cores >= 8, we'll return 8, else we'll return 4. With RFP (privacy.resistFingerprinting = True) however, we'll return 4 (except for OSX, on OSX we'll return 8)

actually in my haste and tiredness I checked RFP in comment 22

Am still not sure with this for FPP: "on a platform with cores >= 8, we'll return 8, else we'll return 4" - does this apply to mac as well - i.e we can have 4 core macs ? please advise

does this apply to mac as well - i.e we can have 4 core macs ? please advise

Yep! It is the second most popular cpu count on macs (8 is the first place) (at least within firefox users)

Comment on attachment 9508451 [details]
Bug 1984333 - Spoof CPU cores to 4, or 8 if the machine has 8+ cores. r?timhuang

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: This feature is riding the trains to release and we want to ensure web compatibility when it reaches there.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce:
    In Release: Set privacy.fingerprintingProtection.overrides to +NavigatorHWConcurrency and try to reproduce the original behavior in Bug 1984132 ETP Strict Mode.
    If it can be reproduced, then test Beta after the patch and confirm its fixed.
    If it can't be reproduced in Release, no no verification is needed.
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): It will change behavior for all users in ETP Strict/PBM modes but it's reporting higher numbers and everyone knows higher numbers are better so everything should be better?
  • String changes made/needed:
  • Is Android affected?: Yes
Attachment #9508451 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Blocks: 1984132
Blocks: 1982336
Flags: in-testsuite+

Comment on attachment 9508451 [details]
Bug 1984333 - Spoof CPU cores to 4, or 8 if the machine has 8+ cores. r?timhuang

Approved for 143.0b8.

Attachment #9508451 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Duplicate of this bug: 1957254
See Also: 1957254 →

Hi, Tom,
Please provide us some steps to reproduce in order to verify this issue on Firefox for Android.
Thank you!

Flags: needinfo?(tom)

Go to https://ritter.vg/misc/ff/hardwareConcurrency.html in Normal browsing mode with no ETP, and note the processor count.

Enable ETP Strict, and revisit with ETP enabled and it should be either 4 (if the original number was <8) or 8 (if the original number was >= 8.

Flags: needinfo?(tom)
QA Whiteboard: [uplift][qa-ver-needed-c144/b143]
QA Contact: cgeorgiu

Would it be possible to uplift this to ESR as well?
It doesn't apply cleanly because of some FPP targets currently missing in ESR 140, but otherwise it works as expected.

Verified on the latest Firefox for Android Nightly 144.0a1 from 9/3, with a Samsung Galaxy S24 (Android 15).
Loading https://ritter.vg/misc/ff/hardwareConcurrency.html displays number 10 with ETP on Standard, and 8 with ETP set to Strict.
Verified also on Beta 143.0b8 with a Samsung Galaxy Z Fold4 (Android 14) device.
Loading https://ritter.vg/misc/ff/hardwareConcurrency.html displays number 8 with ETP on Standard, and 8 with ETP set to Strict.

Flags: qe-verify+

Do we need to uplift Bug 1984919 alongside? For beta and also towards esr, if we uplift there too. Because it does fix ITEM_VALUE(NavigatorHWConcurrencyTiered,74) not matching the regex and therefore not getting applied?

Flags: needinfo?(tom)

(In reply to Pier Angelo Vendrame from comment #32)

Would it be possible to uplift this to ESR as well?
It doesn't apply cleanly because of some FPP targets currently missing in ESR 140, but otherwise it works as expected.

We cannot uplift this patch because we don't want to change FPP behaviors; but we could uplift a RFP-only version of the patch.

Flags: needinfo?(tom)

Sounds good to me, thanks!
Otherwise, if it's a problem we can cherry-pick it directly downstream, as you prefer 😊.

(In reply to Mira Lobontiu (Android QA) from comment #33)

Verified on the latest Firefox for Android Nightly 144.0a1 from 9/3, with a Samsung Galaxy S24 (Android 15).
Loading https://ritter.vg/misc/ff/hardwareConcurrency.html displays number 10 with ETP on Standard, and 8 with ETP set to Strict.
Verified also on Beta 143.0b8 with the same device.
Loading https://ritter.vg/misc/ff/hardwareConcurrency.html displays number 8 with ETP on Standard, and 8 with ETP set to Strict.

Sorry - if you tested with the same device, you should not be getting different values for ETP Standard in Normal Browsing Mode if both Nightly and Beta have the patch. Could you confirm?

Flags: needinfo?(mlobontiuroman)

Sorry, I forgot to add the second device for Beta, it was a Samsung Galaxy Z Fold4 (Android 14).
I'll update my previous comment.

Flags: needinfo?(mlobontiuroman)

This has also been verified as fixed on desktop with Windows 11, macOS 28, and Ubuntu 22.04 using the latest Nightly 144.0a1 and Beta 143.0b8. I followed the STR from comment 26.

Previously, I was able to reproduce the issue with an affected Nightly build (2025-08-01).

Status: RESOLVED → VERIFIED
QA Whiteboard: [uplift][qa-ver-needed-c144/b143] → [uplift][qa-ver-done-c144/b143]
status-firefox143: fixed → verified
status-firefox144: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: