Bug #16029

Tor Browser leaks locale in HTTP_ACCEPT Headers

Added by anonym 2018-10-03 18:48:12 . Updated 2018-10-24 16:57:58 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Target version:
Start date:
2018-10-03
Due date:
% Done:

100%

Feature Branch:
bugfix/16029-fix-spoof-english+force-all-tests
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

Using Panopticlick, we get this HTTP_ACCEPT Headers using the default US English locale:

text/html, */*; q=0.01 gzip, deflate, br en-US,en;q=0.5 


but this with French:

text/html, */*; q=0.01  gzip, deflate, br fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3

In the non-English Tor Browsers when used outside of Tails you are asked about whether you want to leak this (for a localized web experience). But I guess we still want to spoof as US English for all?


Subtasks


Related issues

Blocks Tails - Feature #15506: Core work 2018Q4: Foundations Team Resolved 2018-04-08

History

#1 Updated by anonym 2018-10-03 18:48:37

#2 Updated by anonym 2018-10-03 18:48:55

  • Priority changed from Normal to Elevated

This should probably be elevated.

#3 Updated by anonym 2018-10-03 19:15:19

The issue is also present in Tails 3.9, so not a regression in Tails 3.9.1 with Tor Browser 8.0.2.

#4 Updated by anonym 2018-10-03 19:39:33

So the spoofing has been uplifted from Torbutton to Firefox. The pref is privacy.spoof_english, with (from Tor Browser sources, browser/app/profile/firefox.js):

// 0 - will prompt
// 1 - don't spoof
// 2 - spoof


So we should set it to 2… but it already is according to about:config in both Tails 3.9 and 3.9.1 (picked German in the Greeter).

Those settings do what they are supposed to in Tor Browser outside of Tails, but when set to 1 or 2 they are always “User set” (user_pref(...)), but in Tails we change the default to 2. We’ve seen buggy prefs before that behave differently for the same value depending if they are set via a default or user set.

#5 Updated by intrigeri 2018-10-04 14:00:34

  • related to deleted (Feature #15506: Core work 2018Q4: Foundations Team)

#6 Updated by intrigeri 2018-10-04 14:00:41

#7 Updated by intrigeri 2018-10-04 20:35:16

  • Assignee set to segfault

segfault, do you want this one? I think anonym is right and we should try turning this one into a user_pref().

#8 Updated by segfault 2018-10-08 14:04:40

  • Description updated

#9 Updated by segfault 2018-10-09 20:43:38

  • % Done changed from 0 to 10
  • Feature Branch set to bugfix/16029-fix-spoof-english

I pushed a commit to set privacy.spoof_english as a user_pref, now building to see if that changes anything

#10 Updated by intrigeri 2018-10-10 14:52:01

FYI most automated tests involving Tor Browser are tagged fragile so they won’t run on Jenkins unless your branch’s name has the +force-all-tests suffix.

#11 Updated by segfault 2018-10-13 11:13:56

  • Feature Branch changed from bugfix/16029-fix-spoof-english to bugfix/16029-fix-spoof-english+force-all-tests

intrigeri wrote:
> FYI most automated tests involving Tor Browser are tagged fragile so they won’t run on Jenkins unless your branch’s name has the +force-all-tests suffix.

Thanks, I added the suffix

#12 Updated by segfault 2018-10-14 15:01:26

  • Status changed from Confirmed to In Progress

Applied in changeset commit:f464d91697ec3b4932e697daf43fb80f9be4faea.

#13 Updated by segfault 2018-10-14 17:53:29

So, simply adding

user_pref("privacy.spoof_english", 2);

to

config/chroot_local-includes/etc/tor-browser/profile/prefs.js

did not work, the HTTP_ACCEPT headers still include the non-EN locale.

#14 Updated by segfault 2018-10-14 17:56:49

  • Assignee deleted (segfault)

I don’t know what else to try and I have enough on my 3.10 plate for now, so I’m unassigning me for now

#15 Updated by intrigeri 2018-10-20 10:44:22

  • Target version changed from Tails_3.10.1 to Tails_3.11

Same here, not doable for 3.10 :/

Let’s allocate this work during the next FT meeting.

#16 Updated by segfault 2018-10-20 18:57:37

I took a look at the code today. The only place I could find where the spoofing is applied is here, in LanguagePrompt.jsm. There it seems like the spoofing is only applied if the preference is changed, so it doesn’t matter what the value is when firefox is started.

This is consistent with the behavior I see: If I manually change the setting to 1 and then back to 2, the spoofing is enabled.

I also noticed that when the spoofing is applied, it actually only sets two other preferences. I guess if we would set these in config/chroot_local-includes/etc/tor-browser/profile/prefs.js, we could enable the spoofing again.

#17 Updated by segfault 2018-10-20 19:18:24

  • Assignee set to intrigeri
  • QA Check set to Ready for QA

segfault wrote:
> I also noticed that when the spoofing is applied, it actually only sets two other preferences. I guess if we would set these in config/chroot_local-includes/etc/tor-browser/profile/prefs.js, we could enable the spoofing again.

I also tried to change these settings in config/chroot_local-includes/usr/share/tails/tor-browser-prefs.js, but had no effect. It only works if they are set in config/chroot_local-includes/etc/tor-browser/profile/prefs.js. I pushed a commit which does that.

#18 Updated by intrigeri 2018-10-20 20:06:45

  • Target version changed from Tails_3.11 to Tails_3.10.1

#19 Updated by segfault 2018-10-20 21:36:14

Built and tested, seems to work

#20 Updated by intrigeri 2018-10-21 08:59:38

  • % Done changed from 10 to 60

… and Jenkins is happy about it. Will quickly build & test manually in combination with Bug #16067 and then I’ll merge!

#21 Updated by intrigeri 2018-10-21 09:45:17

  • Status changed from In Progress to Fix committed
  • Assignee deleted (intrigeri)
  • % Done changed from 60 to 100
  • QA Check changed from Ready for QA to Pass

Congrats for the investigation and for finding a solution!

#22 Updated by segfault 2018-10-22 11:56:33

  • Status changed from Fix committed to In Progress

Applied in changeset commit:76efb36745c918ede22eb6ed70d97c5244a681a8.

#23 Updated by intrigeri 2018-10-24 16:57:58

  • Status changed from In Progress to Resolved