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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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, TorBrowserTeam201705R            |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor4
-------------------------------------------------+-------------------------

Comment (by gk):

 Replying to [comment:12 arthuredelstein]:
 > Replying to [comment:11 gk]:
 >
 > > 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.
 >
 > I like this idea. It also suggests to me that to mitigate the attack in
 #18559 we could somehow restrict the use of cores to match the value of
 `window.navigator.hardwareConcurrency` that we report. So to match the
 policy in your example, we would allow the use of 1 core if there are less
 than 4 cores available, and allow 4 cores to be used if there are more
 than 3 and less than 8, etc. I'm not sure how easy it would be to do this
 in practice, but it would give a consistent core count with the patch
 here, so we can claim to actually hide the number.

 OKay. Given the time-constraints for getting Tor Browser 7.0 out I'll take
 the patch you have right now and opened a ticket (#22127) for the more
 elaborate approach.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21675#comment:15>
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