[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #21675 [Applications/Tor Browser]: Set window.navigator.hardwareConcurrency to a constant value



#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs