Set window.navigator.hardwareConcurrency to a constant value
We should avoid leaking the amount of cores a user has available by asking window.navigator.hardwareConcurrency. Not sure which value we should give back and if we should return the same one for all users.
Activity
added TorBrowserTeam201705R in Legacy / Trac component::applications/tor browser in Legacy / Trac ff52-esr in Legacy / Trac owner::arthuredelstein in Legacy / Trac priority::medium in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac sponsor::4 in Legacy / Trac status::closed in Legacy / Trac tbb-7.0-must in Legacy / Trac tbb-fingerprinting in Legacy / Trac type::defect in Legacy / Trac labels
Note, there is legacy/trac#18559 (moved) where a probabilistic means is used to detect the number of cores.
-
Trac:
Description: We should avoid leaking the amount of CPUs a user has available by askingwindow.navigator.hardwareConcurrency. Not sure which value we should give back and if we should return the same one for all users.to
We should avoid leaking the amount of cores a user has available by asking
window.navigator.hardwareConcurrency. Not sure which value we should give back and if we should return the same one for all users. Replying to gk:
We should avoid leaking the amount of cores a user has available by asking
window.navigator.hardwareConcurrency. Not sure which value we should give back and if we should return the same one for all users. Of course, one! Are you sure asking to give workers of one site more than 1 core?Maybe, this can help:
// return the maximum number of cores that navigator.HardwareConcurrency returns pref("dom.maxHardwareConcurrency", 1);Replying to 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.
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1360039 for the Mozilla bug)
-
Replying to arthuredelstein:
Replying to 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.
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 (legacy/trac#18559 (moved)) regardless whether we give a uniform value back or not.
Replying to 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 (legacy/trac#18559 (moved)) 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 legacy/trac#18559 (moved) we could somehow restrict the use of cores to match the value of
window.navigator.hardwareConcurrencythat 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.-
Replying to arthuredelstein:
Replying to 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 (legacy/trac#18559 (moved)) 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 legacy/trac#18559 (moved) we could somehow restrict the use of cores to match the value of
window.navigator.hardwareConcurrencythat 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 (legacy/trac#22127 (moved)) for the more elaborate approach.
-
This is commit 29b3b7af on
tor-browser-52.1.0esr-7.0-2.Trac:
Resolution: N/A to fixed
Status: needs_review to closed mentioned in issue legacy/trac#22127 (moved)
moved from legacy/trac#21675 (moved)
added Bug label and removed 1 deleted label
added Fingerprinting label and removed 1 deleted label