[Feature Request] Investigate RFP/FPP compatibility — detect and handle conflicts with Firefox fingerprinting protections

[anthonysgro]

Context

When Firefox's privacy.resistFingerprinting (RFP) or Fingerprinting Protection (FPP with JSDateTimeUTC) is enabled, Firefox forces all timezone resolution to UTC at the Gecko/SpiderMonkey engine level. GeoSpoof's timezone overrides operate at the JS prototype level, which sits above this. The result is an inconsistency — some APIs report the spoofed timezone, others report UTC — and that inconsistency is itself a detectable fingerprint.

This is a fundamental architectural conflict: RFP says "force UTC at the engine level" while GeoSpoof says "force timezone X at the JS level." No amount of JS-level overriding can fully cover what Gecko does internally.

What needs investigation

We need to decide how (or if) GeoSpoof should handle this case. There are several possible approaches, each with tradeoffs:

Option A: Detect RFP/FPP and disable timezone spoofing

• RFP can be detected via browser.privacy.websites.resistFingerprinting from the background script
• FPP is harder — not exposed via WebExtension API, would need a heuristic (e.g. checking if the original getTimezoneOffset returns 0 when the user isn't in UTC)
• Show a warning in the popup when detected

Pros:

• Prevents the inconsistency that creates a unique fingerprint
• Geolocation spoofing still works fine (separate API, no conflict)
• Honest about what the extension can and can't do

Cons:

• Users lose timezone spoofing entirely when RFP/FPP is on
• FPP heuristic detection is fragile and could false-positive for users actually in UTC

Option B: Detect and force UTC as the spoofed timezone

• When RFP/FPP detected, override the spoofed timezone to UTC so JS-level and engine-level agree

Pros:

• No inconsistency between layers
• Geolocation spoofing still works

Cons:

• Timezone won't match the spoofed geolocation (user spoofs to Tokyo but timezone says UTC)
• Arguably worse than just not spoofing timezone at all

Option C: Do nothing, document the incompatibility

• Add a note in README/user guide that GeoSpoof is not recommended with RFP/FPP
• No code changes

Pros:

• No added complexity
• Users who run RFP/FPP are typically advanced enough to understand the tradeoff

Cons:

• Users who don't read docs will have a silently degraded experience

Option D: Detect and warn, let user choose

• Detect RFP/FPP, show a warning in the popup, let the user decide whether to keep timezone spoofing on

Pros:

• Respects user agency
• Transparent about the conflict

Cons:

• Most users won't understand the implications well enough to make an informed choice
• Adds UI complexity

Open questions

• Is the FPP heuristic reliable enough to ship, or should we only detect RFP (which has a proper API)?
• Should geolocation spoofing behavior change at all when RFP is detected, or only timezone?
• Are there other Gecko-level behaviors beyond timezone that RFP changes which conflict with our overrides?

[Thorin-Oakenpants]

The result is an inconsistency — some APIs report the spoofed timezone, others report UTC — and that inconsistency is itself a detectable fingerprint.

using RFP is the same as if your real timezone is Atlantic/Reykjavik (PS: it does not report UTC | PPS I should know as I came up with it and found the leaks and helped get them patched) - your spoofing here is no different than spoofing anyone's real timezone

--

my recommendation is not to bother to code around it - RFP is designed for Tor Browser, and FPP users who mess with targets deserve to burn in hell :) 🔥 If/when you add a per eTLD+1 site mechanism then this becomes a non issue - your aim is to circumvent geo blocks - spoofing on a few sites is not going to matter