Set privacy.resistFingerprinting.testing.setTZtoUTC as a defense-in-depth

See https://bugzilla.mozilla.org/show_bug.cgi?id=1709867#c21 - we're changing how to spoof the timezone to make way for fine-grained control of that aspect of RFP. On Nightly we by default have changed the behavior of RFP. Tor Browser should flip this pref to true to keep the old behavior until we are certain their are no leaks. This will be landing on Nightly soon, so eventually it will ride to Release and affect Android.

@tom

We would really appreciate it if you let us know if you find any way to leak the real timezone when privacy.resistFingerprinting is true and privacy.resistFingerprinting.testing.setTZtoUTC is false

wait, wot? when you land all this, I assume RFP will no longer have any hooks into timezone protection - right. So the test would be RFP = true and RFP.setTZtoUTC = true. Or is this an interim check to make sure the new pref when off doesn't interfere with current RFP TZ (which we won't keep so why test?) I'm confused

The only current tests for TZ are

same for everyone

• resolved options (Intl.DateTimeFormat) for the actual name
• numeric: offsets (we use an array of known dates that produce max entropy [1] - 430+ buckets)
  • date.parse
  • gettime
  • e.g. GMT and UTC will return the same [1]

timezone name can vary per regional locale

• timezone name manifests in date/time strings/tests
  • I am not sure if UTC has some locale diffs here, probably not if it follows timeZoneName - until I know for sure I can't reconcile date strings with TZ checks
• timeZoneName options (long/short/long generic/etc): there is no entropy regardless of locale with UTC AFAICT - built a bunch of Intl PoCs that tested over a thousand supported locales and the timeZoneName one looped that with 430+ supported timezones in gecko

here's a pic - not on live TZP

Q: can the UI use operating system ... to format dates, times, numbers, and measurements. option (intl.regional_prefs.use_os_locales) affect timezonename formatting?

when you land all this, I assume RFP will no longer have any hooks into timezone protection - right.

No. We will be changing our timezone protection implementation, but we will still be spoofing your timezone to UTC. It's just the 'how' that's changing. RFP.setTZtoUTC=true is the old way, RFP.setTZtoUTC=false is the new way. We want to make sure there are no leaks with RFP.setTZtoUTC=false.

So the test would be RFP = true and RFP.setTZtoUTC = true. Or is this an interim check to make sure the new pref when off doesn't interfere with current RFP TZ (which we won't keep so why test?)

We made the RFP.setTZtoUTC pref so we can keep around the old implementation for Tor. This way Tor doesn't have to switch to the new implementation until we're confident there are no leaks.

Q: can the UI use operating system ... to format dates, times, numbers, and measurements. option (intl.regional_prefs.use_os_locales) affect timezonename formatting?

I don't know, but I bet it can.

RFP.setTZtoUTC=true is the old way, RFP.setTZtoUTC=false is the new way

well that explains it... I read it the other way round and was like WTF :scratch_head:

I don't know, but I bet it can

can we please get an RFP patch to always read intl.regional_prefs.use_os_locales as false - it's very high entropy if users flip it (yeah, I know TB can lock the pref, but upstream is better and don't leave us FF users hanging): default is false and assuming the OS formatting isn't exactly the same as Intl (and why would it be) it will make any user who flips it stick out like a sore thumb

can we please get an RFP patch

FYI: 1823580 Act as though intl.regional_prefs.use_os_locales is false when RFP is enabled

added Android Fingerprinting labels

added FF115-esr label

@tom Android is on the ESR + security backport train so we shouldn't have to worry about this until the ESR115 transition begins in a few months.

so why are we still subjecting Firefox users to version spoofing on android? sigh - I though when we went though all issue of removing desktop from version spoofing (for compat reasons) that Tor Project wanted android to stay because it was using release?

https://bugzilla.mozilla.org/show_bug.cgi?id=1769022#c13

wait, there is no android ESR? Do you mean TBA is using fenix 102 as a base?

@thorin Correct there is no Android ESR. Since the 102 esr transition we've switched to keeping Android on Firefox/Geckoview ESR 102 and backporting security fixes for android-components and fenix from the Rapid Release train. This has mostly worked/been relatively painless but we may go back to the old ways (keeping up with Rapid Release each month) now that we have more people to actually do the required auditing and build system update work.

added Roadmap::Future label

added Feature label

We would really appreciate it if you let us know if you find any way to leak the real timezone when privacy.resistFingerprinting is true and privacy.resistFingerprinting.testing.setTZtoUTC is false

I compared FF111 RFP + use_english vs Nightly with RFP + use_english (and new setTZtoUTC as false) I used date/time/formatting sections of TZP and my new local TZP which is a little different

Results are almost identical - there is a formatting diff with compactSign in trillions (whic is only in my new local super-awesome TZP) e.g. 7,000 trillion vs 7000 trillion - but that be a diff in Intl in Ff111 vs FF113 - and isn't to do with timezone

---

Nightly: comparing old vs new methods (and restarts in between) - i.e RFP on and test1 new pref false, test2 new pref true - identical - which confirms the formatting diff is to do with ICU changes

So, so far nothing leaks any more than it did before, at least in Intl/JS - in en-US

marked this issue as related to #41496 (closed)

mentioned in issue #42289 (closed)

added Linux label

removed Feature label

added Bug label

removed Roadmap::Future label

added Doing label

removed Android label

removed Linux label

added All Platforms label

assigned to @pierov

mentioned in merge request !926 (merged)

marked this issue as related to #42327

removed Doing label

added Backport label

marked this issue as related to tor-browser-build#41094 (closed)

marked this issue as related to tor-browser-build#41095 (closed)

added Backlog label

@richard what's our target for backporting here? 13.0.11 (check after nightly) or 13.0.12 (check after alpha)?

Let's aim for 13.0.12.

marked this issue as related to tor-browser-build#41100 (closed)

marked this issue as related to tor-browser-build#41099 (closed)

marked this issue as related to tor-browser-build#41086 (closed)

removed the relation with tor-browser-build#41099 (closed)

marked this issue as related to tor-browser-build#41087 (closed)

removed the relation with tor-browser-build#41086 (closed)

removed the relation with tor-browser-build#41087 (closed)

marked this issue as related to tor-browser-build#41099 (closed)

Moved to 13.0.13.

It was 13.0.12 after alpha (13.5a6), but 13.0.11 was the emergency release for domain fronting, so 13.0.12 is going out before 13.5a6.

added Next label and removed Backlog label

changed title from Set {--}privacy.resistFingerprinting.testing.setTZtoUTC{- to true on Android-} to Set privacy.resistFingerprinting.testing.setTZtoUTC as a defense-in-depth.

changed title from Set privacy.resistFingerprinting.testing.setTZtoUTC as a defense-in-depth. to Set privacy.resistFingerprinting.testing.setTZtoUTC as a defense-in-depth

Backports: 59d59b87, 5c690113, mullvad-browser@aba1e5a0.

closed

removed Next label