Opened 2 years ago

Closed 2 years ago

#21675 closed defect (fixed)

Set window.navigator.hardwareConcurrency to a constant value

Reported by: gk Owned by: arthuredelstein
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting, ff52-esr, tbb-7.0-must, TorBrowserTeam201705R
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor4

Description (last modified by 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.

Child Tickets

Change History (16)

comment:1 Changed 2 years ago by gk

Note, there is #18559 where a probabilistic means is used to detect the number of cores.

comment:2 Changed 2 years ago by gk

Description: modified (diff)

comment:3 in reply to:  description ; Changed 2 years ago by cypherpunks

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);

comment:4 Changed 2 years ago by gk

Keywords: tbb-7.0-must added

Adding tickets to our 7.0 ticket list

comment:5 in reply to:  3 ; Changed 2 years ago by 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.

https://github.com/arthuredelstein/tor-browser/commit/21675

comment:6 Changed 2 years ago by arthuredelstein

comment:7 Changed 2 years ago by arthuredelstein

Keywords: 201704TorBrowserTeamR added
Status: newneeds_review

comment:8 Changed 2 years ago by arthuredelstein

Keywords: TorBrowserTeam201704R added; 201704TorBrowserTeamR removed

comment:9 Changed 2 years ago by arthuredelstein

Owner: changed from tbb-team to arthuredelstein
Status: needs_reviewaccepted

comment:10 Changed 2 years ago by arthuredelstein

Status: acceptedneeds_review

comment:11 in reply to:  5 ; Changed 2 years ago by gk

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.

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.

comment:12 in reply to:  11 ; Changed 2 years ago by 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 (#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.

comment:13 Changed 2 years ago by gk

Keywords: TorBrowserTeam201705R added; TorBrowserTeam201704R removed

Moving review tickets to May.

comment:14 Changed 2 years ago by cypherpunks

Locking firefox.exe to one core is easy. Also you get load of 2 cores in e10s by this and more than 4 cores in e10s-multi.

comment:15 in reply to:  12 Changed 2 years ago by gk

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 (#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.

comment:16 Changed 2 years ago by gk

Resolution: fixed
Status: needs_reviewclosed

This is commit 29b3b7af8e3b9528204ae49a396af80b3e4c4d61 on tor-browser-52.1.0esr-7.0-2.

Note: See TracTickets for help on using tickets.