[tor-bugs] #21675 [Applications/Tor Browser]: Set window.navigator.hardwareConcurrency to a constant value
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Apr 27 07:02:54 UTC 2017
#21675: Set window.navigator.hardwareConcurrency to a constant value
-------------------------------------------------+-------------------------
Reporter: gk | Owner:
| arthuredelstein
Type: defect | Status:
| needs_review
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-fingerprinting, ff52-esr, | Actual Points:
tbb-7.0-must, TorBrowserTeam201704R |
Parent ID: | Points:
Reviewer: | Sponsor:
| Sponsor4
-------------------------------------------------+-------------------------
Comment (by gk):
Replying to [comment:5 arthuredelstein]:
> Replying to [comment:3 cypherpunks]:
> > Maybe, this can help:
> > {{{
> > // return the maximum number of cores that
navigator.HardwareConcurrency returns
> > pref("dom.maxHardwareConcurrency", 1);
> > }}}
>
> This pref works, but seems to require a Firefox restart. I suggest we
use this pref for now and then in Firefox add a better live behavior once
the resistFingerprinting pref is available in Workers.
>
> https://github.com/arthuredelstein/tor-browser/commit/21675
Assuming this really gets traction and developers start to check this
attribute to deliver better performance to users I was wondering whether
we should follow the bucket approach here instead: we could then do
something like giving back 1 core if there are less than 4 cores
available, and 4 cores if there are more than 3 but less than 8 and 8 if
there more than 7. Is that worth the trade-off? Keep in mind that there is
a probabilistic approach possible (#18559) regardless whether we give a
uniform value back or not.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21675#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list