accept-language header leaks browser localization

added blog in Legacy / Trac component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac priority::high in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tbb-mobile in Legacy / Trac tbb-parity in Legacy / Trac type::defect in Legacy / Trac user-feedback in Legacy / Trac labels

Trac:
Description: A blog user mentions each request includes the chosen browser language. Do we normalize this on desktop such that we only send en-US regardless of the browser's localization?

Using https://wtfismyip.com/headers

With en-US as the browser locale:

host: wtfismyip.com
connection:
close user-agent: Mozilla/5.0 (Android 6.0; Mobile; rv:60.0) Gecko/20100101 Firefox/60.0
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-language: en-US,en;q=0.5
accept-encoding: gzip, deflate, br
upgrade-insecure-requests: 1

With ru-RU as the browser locale:

host: wtfismyip.com
connection: close
user-agent: Mozilla/5.0 (Android 6.0; Mobile; rv:60.0) Gecko/20100101 Firefox/60.0
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-language: ru,ru-RU;q=0.8,en-US;q=0.5,en;q=0.3
accept-encoding: gzip, deflate, br
upgrade-insecure-requests: 1

to

A blog user mentions each request includes the chosen browser language. Do we normalize this on desktop such that we only send en-US regardless of the browser's localization?

Using https://wtfismyip.com/headers

With en-US as the browser locale:

host: wtfismyip.com
connection: close
user-agent: Mozilla/5.0 (Android 6.0; Mobile; rv:60.0) Gecko/20100101 Firefox/60.0
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-language: en-US,en;q=0.5
accept-encoding: gzip, deflate, br
upgrade-insecure-requests: 1

With ru-RU as the browser locale:

host: wtfismyip.com
connection: close
user-agent: Mozilla/5.0 (Android 6.0; Mobile; rv:60.0) Gecko/20100101 Firefox/60.0
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-language: ru,ru-RU;q=0.8,en-US;q=0.5,en;q=0.3
accept-encoding: gzip, deflate, br
upgrade-insecure-requests: 1

I think what happens in desktop (with lang other than en-US) is that on first navigation there is the prompt asking whether to spoof to english, if the user accepts then it sets the privacy.spoof_english = 2 pref. Then, the pref listener in toolkit/components/resistfingerprinting/RFPHelper.jsm sets the intl.accept_languages = en-US,en. In Android I don't see privacy.spoof_english pref, and then even if set manually to 2, intl.accept_languages is not changed. I wonder what is failing here... Changing intl.accept_languages = en-US,en manually works, and then the accept-language header is spoofed correctly.

Replying to acat:

I think what happens in desktop (with lang other than en-US) is that on first navigation there is the prompt asking whether to spoof to english, if the user accepts then it sets the privacy.spoof_english = 2 pref. Then, the pref listener in toolkit/components/resistfingerprinting/RFPHelper.jsm sets the intl.accept_languages = en-US,en. In Android I don't see privacy.spoof_english pref, and then even if set manually to 2, intl.accept_languages is not changed. I wonder what is failing here... Changing intl.accept_languages = en-US,en manually works, and then the accept-language header is spoofed correctly.

Ah, thanks! That sounds like something we want on Android, too. It seems it was only implemented on Desktop (not surprisingly). I wonder what we should do on Android. Maybe we should start with always spoofing the header for now, and implement a better fix later?

Trac:
Keywords: N/A deleted, tbb-mobile added

Replying to sysrqb:

Replying to acat:

I think what happens in desktop (with lang other than en-US) is that on first navigation there is the prompt asking whether to spoof to english, if the user accepts then it sets the privacy.spoof_english = 2 pref. Then, the pref listener in toolkit/components/resistfingerprinting/RFPHelper.jsm sets the intl.accept_languages = en-US,en. In Android I don't see privacy.spoof_english pref, and then even if set manually to 2, intl.accept_languages is not changed. I wonder what is failing here... Changing intl.accept_languages = en-US,en manually works, and then the accept-language header is spoofed correctly.

Ah, thanks! That sounds like something we want on Android, too. It seems it was only implemented on Desktop (not surprisingly). I wonder what we should do on Android. Maybe we should start with always spoofing the header for now, and implement a better fix later?

I am inclined to say "no" as the usability issues are potentially quite severe. There are a bunch of ways to get the browser locale (we still have some open for desktop) even though header spoofing is active (see e.g. legacy/trac#30304 (moved)). So the benefit might not be as expected (this is not meant in the sense that we should not fix it because there are other ways to obtain the locale).

Trac:
Keywords: N/A deleted, tbb-parity added

Replying to gk:

Replying to sysrqb: [snip]

I wonder what we should do on Android. Maybe we should start with always spoofing the header for now, and implement a better fix later?

I am inclined to say "no" as the usability issues are potentially quite severe. There are a bunch of ways to get the browser locale (we still have some open for desktop) even though header spoofing is active (see e.g. legacy/trac#30304 (moved)). So the benefit might not be as expected (this is not meant in the sense that we should not fix it because there are other ways to obtain the locale).

Maybe we should add a warning/notification somewhere? Maybe we should check the current locale when the app starts and show a warning if locale != en-US? It makes me a little uncomfortable that we default to en-US, but I don't have a better answer right now.

From a usability perspective, I agree we should send the correct language header.