1924087 - SVG Switch Element leaks language even with spoof language

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Fatih Kilic [:fkilic]]

This is an interesting one, because it looks like Firefox still sends un-spoofed version intl.accept_languages. So, a user might have privacy.spoof_langugages set to 2, but they would still send real intl.accept_languages. This isn't the case with TB, as they seem to lock that pref.

Comment 1

[Fatih Kilic [:fkilic]]

Attachment: Bug 1924087: Check language spoofing in SVG's switch element. r?tjr

Comment 2

[Thorin [:thorin]]

(In reply to Fatih Kilic from comment #0)

... intl.accept_languages. This isn't the case with TB, as they seem to lock that pref.

TB doesn't lock this pref at all.

Anyway, confirmed TB doesn't seem to be affected

• demo on https://developer.mozilla.org/en-US/docs/Web/SVG/Element/switch
• TB with de app lang, no spoof_english = Hallo
• TB with de app lang + spoof_english = Howdy!

FF132 beta

• es (es-ES) app lang, nothing else = Hola!
• es app lang, RFP enabled, spoof english enabled = Howdy!

Can't replicate. Might be live reload - TB forces a restart, and in FF I did one anyway. Also in FF resetting spoof_english does not reset intl.accept = caused a year+ long regression in TB and needs addressing upstream - there's a ticket somewhere

Comment 3

[Fatih Kilic [:fkilic]]

TB doesn't lock this pref at all.

Interesting, I couldn't change it in about:config, it reverted back for some reason.

Can't replicate

Interesting. When you use a es app lang, does it also set intl.accept_languages to es?

Comment 4

[Thorin [:thorin]]

I couldn't change it in about:config, it reverted back for some reason

pier added some special magic and code to make sure things are what they should be (on toggle, on startup, etc) - but it's totally editable

When you use a es app lang, does it also set intl.accept_languages to es

yes, but when you choose to spoof_english, it changes to english - that's the whole purpose, and if you undo spoof english it should revert it (but FF doesn't - nasty nasty bug ... ask pier :) )

Comment 5

[Thorin [:thorin]]

so I built a neat PoC (will share later) and AFAICT this only uses languages e.g. navigator.languages - it is not app language specific at all. So the problem lies in intl.accept_languages in Firefox - we fixed that problem in TB

Comment 6

[Thorin [:thorin]]

Attachment: PoC.html

PoC

• gets navigator.languages (lower cases them)
• concats 661 more languages
  • https://searchfox.org/mozilla-central/source/intl/icu/source/data/lang/en.txt#44
• dedupes and sorts this array
• builds a content string from the array for the svg element and set this as it's innerHTML
• walks each node and checks for BBox
• compares navigator.languages (sorted, lowercase) vs detected systemLanguages (automagically sorted and lowercased)

This should be enough to

• show that navigator.languages (not app lang) is what drives this
• detect extensions changing languages - i.e they should always match

unless I'm missing something

Comment 7

[Thorin [:thorin]]

Attachment: example.png

so if you add/remove items from Settings>Choose your preferred language for displaying pages - this in turn alters intl.accept_languages which is reflected in the test

Comment 8

[Robert Longson [:longsonr]]

Per https://www.w3.org/TR/SVG2/struct.html#ConditionalProcessingSystemLanguageAttribute

Evaluates to "true" if one of the language tags indicated by user preferences is a case-insensitive match of one of the language tags given in the value of this parameter, or if one of the language tags indicated by user preferences is a case-insensitive prefix of one of the language tags given in the value of this parameter such that the first tag character following the prefix is "-".

In practice Firefox follows BCP47 language matching.

Comment 9

[Pier Angelo Vendrame]

(In reply to Thorin [:thorin] from comment #4)

I couldn't change it in about:config, it reverted back for some reason

pier added some special magic and code to make sure things are what they should be (on toggle, on startup, etc) - but it's totally editable

When you use a es app lang, does it also set intl.accept_languages to es

yes, but when you choose to spoof_english, it changes to english - that's the whole purpose, and if you undo spoof english it should revert it (but FF doesn't - nasty nasty bug ... ask pier :) )

We think the double list of languages (app languages vs. accepted languages) is hard to get, and it becomes a footgun when protecting from fingerprinting.
So, for Tor Browser we dropped the support for customizing intl.accepted_languages and we reset it to the default value (that depends on the app language) whenever spoof English is off.
In this way, we remove any potential entropy of differences between the app language (which can be detected with form validation messages, for examples) and the languages announced by the browser in HTTP headers and in navigator.languages.

Notice that intl.accepted_languages is a complex preference: it isn't a string, it's a reference to a property value from localization files (chrome://global/locale/intl.properties).
If I remember correctly, the problem was that the code that disabled spoof English used to reset intl.accepted_languages to the string value it evaluated to in that moment. The result was that changing the app language after that didn't update intl.accepted_languages.
Also, there was a race condition between RFPTarget and the preferences UI.
So, eventually we decided to lock it as a matter of fact (by setting the value we want at startup and by observing its changes), even though it isn't shown as locked because RFPHelper needs to change it to work.

Finally, we have also another patch about languages (see Bug 1746668).

Comment 10

[Thorin [:thorin]]

Fun fact ... if intl is blank, navigator languages is populated with your locale :)

Side note: my PoC's language list, I forgot to replace underscores with hyphens - e.g. en_us should be en-us. But that's not required for this issue, but rather to expose extension fiddling

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c7245091cbfc
Check language spoofing in SVG's switch element. r=tjr,longsonr

Comment 12

[Thorin [:thorin]]

Sorry, but can you explain what this is doing and why we need it? SVG switch does not leak anything IIUIC as it uses intl.accepted_languages - so there is nothing specifically to do here with SVG and switch. The problem does not exist in TB and if it does in FF then this is not the way

Comment 13

[Fatih Kilic [:fkilic]]

I mean are you suggesting that we revert this patch? I'm not sure what else I could do about it.

IMO, this patch doesn't do a lot since intl.accepted_languages is already being sent with http requests, but it is also nice that we place some bits about language spoofing so that if in the future things change about how language is selected for SVG elements, then whoever doing the change will be aware of spoofing requirement.

Comment 14

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/c7245091cbfc

Comment 15

[Thorin [:thorin]]

Sorry for the noise ... Just comment it IMO. I'm not the engineer, but I see zero point to any of this except adding a comment.

It's already controlled, automatically with intl.accepted_languages and that's where you check for failures. The spoof_english part of the patch doesn't achieve anything different. What if in future en-US languages changed, we now have a footgun. What if in future we can spoof any language: we've talked about it at tor project - i.e use any app language, but request web content as if the app language was another.

Why are we hardcoding the string? FYI, android behaves differently (something about secondary languages, which is a long-time bugzilla issue). Currently android en-US (no RFP) only returns en-US (my phone is en-US platform language as well), so if an android user with RFP decides to spoof_english they now look completely different to other android en-US users - IIUIC. To be fair, this is already the case - but now we have the string in multiple places

As for the test we don't need one - but at a bare minimum I would checking for all languages that are expected because in it's current state spoof_english could change to just en and the test would still pass.

I just don't think this patch or test is necessary, but a comment wouldn't hurt. Instead we should investigate getting the correct expected spoof_english intl string per platform (desktop vs mobile? and I assume platform language doesn't affect it), and set it once somewhere to be used where needed.

sorry if I sound like I'm ranting/condescending - not intended :)