#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 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. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21675#comment:12> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs