timezone problems

[Thorin-Oakenpants]

I'm only going to talk about timezones in this issue - and whilst "dates" are used here, I'm not going to touch on the huge mountain of problems with dates you have (all your to*String etc patches don't even come close to fixing everything) which is for another day, if at all.

some of these [timezone problems] you cannot fix, and even if you didn't leak real values (mismatched values already show you are tampering), you are still leaking a tampering fingerprint ⚠️ via prototype and proxy changes - ⚠️ in fact you are leaking the extension name

timezone name

• you didn't think about Temporal,. did you
• ⚠️**you fail 2 of 3 tests**

i am in Iceland (via RFP == super robust, I know cuz I'm part of it) but spoofing as Tokyo

timezone offset

• this test is the current offset
• the control date is not a test, it's the date I expect you to return based on your timezonename
• not all tests are in here, just enough to prove the point, e.g. I am not using getTimezoneOffset
• ⚠️**you fail 6 of 8 tests** where you leak the real timezone offset and the other two are detected as known "lies" (underlined and faint grey)
• I can definitively say what is a lie because the other methods you have no way to stop them leaking
  • which allows me to return your actual real timezone offset to the fingerprint and what methods you lied about is also recorded in a separate fingerprint

timezone offsets

• this is a set of timezone offsets at specific points in time: 8 days is all that is needed to create (currently, in gecko) 339 unique hashes for all supported (and known) timezonenames
• ^ see https://arkenfox.github.io/TZP/tests/timezones.html - and hit [ combine years]
• ⚠️**you fail 8 of 9 tests** - 8 of them match expected Atlantic/Reykjavik
• getTimezoneOffset differs because it has been tampered with

for this, and timezonename, I don't bother to determine which one is correct - so I don't record what methods are tampered with (which is a fingerprint) or return the real value - instead I just return "lies"

That said, it's not that hard to do (the logic can get a little messy so I haven't bothered, yet). The only reason I have this problem, is because I test so many methods. My point is, you can expect the real value to be recorded (given any script can do that)

timezone offsets - tokyo

this is the real tokyo (gecko ships with IANA tzdata)

here's your fake tokyo (IDK what you are using)

This creates several problems

• ⚠️ for many/most timezonenames, you are creating an adversarial fingerprint - i.e e9b05295 does not exist in the real world
  • ⚠️ because of that, that fingerprint is "rare" - you are making people "unique" so to speak
• and depending on how/where you get your IANA tzdata from
  • ⚠️ you need to be in sync with what ships in gecko, because changes happen all. the . time and fingerprints vary across firefox releases
  • I am not an extension developer, but surely everything you need is already there

prototype / proxy

I don't even need to test timezone etc to know that you could be tampering with it - here's what's directly exposed in the BoM (browser object model) and the specific things they failed

I scrolled down to the bottom, so the top is cut off - the cut off items are Date.getTimezoneOffset, Date.toDateString, Date.toLocaleDateString

• with the other 5 shown below, that's ⚠️ 8 APIs/functions tampered with, with specific test failures each - this is also a fingerprint (and is collected)

extension name leaked

🔥 see pic above

---

have fun trying to fix all of this (hint, you can't) :)

edit: typos

[anthonysgro]

This makes me discouraged and sad but I will try to address this as best I can

[anthonysgro]

I appreciate you bringing this up though, thank you. I absolutely underestimated the privacy-community's knowledge on this issue and I have learned a lot! After digesting this, it reinforces my position that this extension is not a replacement for FPP/RFP/fingerprinting and privacy hardening. Using it in conjunction with those tools can conflict and expose your session.

However, the primary use case of this extension has always been geo-restriction bypass and control over consistent geolocation spoofing for development purposes. Content restriction checks typically compare your IP geolocation against your browser's reported timezone and location APIs. They're not running deep prototype inspection or fingerprint hashing. The extension works as intended for that use case.

I can address most of these issues like the extension name leaking in the bundled output, missing Temporal API coverage, incomplete Date getter overrides, and some offset inconsistencies. These improvements will make the spoofing more robust for the geo-bypass use case.

I can also add documentation that GeoSpoof is a geo-restriction tool, not an anti-fingerprinting tool so that users are aware of the limitations and use cases more clearly.

[Thorin-Oakenpants]

I absolutely underestimated the privacy-community's knowledge on this issue

no you didn't - that's just me - i'm a FPing expert (or so i'm repeatedly told) - almost everyone else gets it wrong and are idjuts on the subject including all those browser forks claiming hardening (they are all doing it wrong)

the primary use case of this extension has always been geo-restriction bypass

then disable it by default and users need to add sites to an allowlist (i.e limit the "damage" to where the user has to do it) - and don't spoof anything unless the user is behind a VPN/proxy - otherwise you are not achieving anything except "damage"

[Thorin-Oakenpants]

timezone offset ..... I can definitively say what is a lie because the other methods you have no way to stop them leaking

the temporal ones you could patch, but lastModified values I am 99.99% sure you can't since they are timestamp strings

[anthonysgro]

how did you even find this repo? just wondering lol, i appreciate the security/privacy audit

[Thorin-Oakenpants]

I drink and I know things

edit

and if it may or does affect FPing I investigate because knowledge is power - I want to know what the pitfalls were, what mistakes were made etc so I can exploit them - because that tells me how to do it correctly

I keep an eye on PG forum ( @dngray is an acquaintance and I abuse him every other day in a private repo, he loves it) and do a few judicious searches from time to time on google to spot the few articles I might miss - plus I scan r/firefox - of course this excludes all the other sources such as papers, working groups, hackernews etc

disclosure: I do not work for anyone, but am funded (since Nov 2024) as a contractor to keep researching - I participate, disclose bugs/issues, and help mozilla and tor browser (since 2018 I think) and mullvad browser (since it started as an offshoot from tor browser). I am a Tor Project core contributor - https://www.torproject.org/about/people/

but enough about me - tell me more about that crypto stash you have

[anthonysgro]

Cmon man lol. Well... alright then

[anthonysgro]

Anyway thx for the issue, I'll do what I can. I agree a whitelist is probably the best way forward for this to be considerate of blast radius privacy issues for anyone that has them

[anthonysgro]

Alright, back with an update. New fixes in v1.14.0 I'll put on the add-on store tonight (available now in releases tab):

Timezone name / Temporal: Temporal.Now is now overridden. timeZoneId(), plainDateTimeISO(), plainDateISO(), plainTimeISO(), and zonedDateTimeISO() all return/use the spoofed timezone. I completely missed this before.

Timezone offset consistency: All Date API overrides now derive components from a single unified path per engine, so every API (getTimezoneOffset, toString, toTimeString, toDateString, all get* getters) produces one consistent hash for any timezone at any year.

Timezone offsets IANA tzdata: The extension no longer does its own offset arithmetic. All offsets and date components are resolved through the browser's native Intl.DateTimeFormat, which uses the engine's own shipped IANA tzdata (gecko's bundled data on Firefox, ICU on Chrome). This should mean that there are no adversarial footprints in the timezone offsets.

Prototype / proxy: Overrides use method shorthand (no prototype, no [[Construct]]), toString returns [native code], stack traces are cleaned up to avoid leaking extra frames. Iframes are patched synchronously on access and DOM insertion.

Extension name leak: There were console.error calls in dev builds lol. I stripped them out during the vite builds so this is not an issue anymore

--

Alright phew, one last thing, as you know, a content script/extension can never fully eliminate fingerprint inconsistencies if you are changing your timezone etc. So I will make a note in the readme that that for the strictest privacy needs you'll need to use Tor/MullVad Browser. As you can see the 4 detectable lies in the screenshots that remain:

I guess to truly fix these you could maybe change your system clock to your target timezone? Not sure, I didn't try it. Anyway, feel free to retest and externally verify any of the above, I'm welcome to issues anytime. Thanks again for your thorough look earlier :)

[Thorin-Oakenpants]

I'll test it later, your extension is great for me to pick apart - thanks. I've actually been working on multiple improvements in my timezone metrics - will likely take a few days (or even a week). More robust logic, more tests etc, And more lie catching.

click for some boring details

TZP records a fingerprint of prototype/proxy checks but I am loathe to use it to determine lies (and rarely do so) because it doesn't always mean the extension altered the value - but sometimes I just want to stick to extensions spoofing (they are not fit for fingerprint resistance purposes and I want to illustrate this), and/or I want stability in the results (stability has many meanings here and TZP is not designed to be stable in every scenario), and/or it may be the only way to determine truthfulness. Instead I rely on type checking (I throw a `TypeError`), mathematical proofs (such as known canvas pixel values, or expected domrect measurements etc), expected results and result ranges (I thrown an `InvalidError`), and techniques to expose mismatches (which are adversarial) by getting the same thing in as many ways possible - which actually causes me a headache sometimes, as in "which one is the real one" (game theory does not cut it here - been down that road).

There's a lot of stuff I haven't added lie logic to, and a lot that I have, I just simply return the metric as "untrustworthy" (and record the lie methods) rather than try and bypass

That said, Imma gonna ramp up exposure of tampering here given it probably needed an overhaul and your extension is perfect for testing - that and thinking about it over the last 4 or 5 days I've come up with a lot of potential leads and ideas

challenge accepted (PS 99.9999% sure you still can't hide the BoM tampering, I'm just not 100% sure what you've done - will explain when I test and post back)

[Thorin-Oakenpants]

also PS: the entire thing leaks in service workers (not actually tested) - there's only so much you can do (some extensions kill service workers in a misguided attempt to protect themselves and just cause websites to break for users). As a tool to help circumvent geo blocks though this is fine - i.e you're not trying to solve an fingerprinting with an impossible solution (it requires browser engineering)

[Thorin-Oakenpants]

i haven't even uploaded my changes - which a this point was hardening some checks and some refactoring - so my local copy is even "worse". notice how without my changes (which includes more timezone name lie detection), I already detect it as a lie even though all 3 are the same

I am on my real timezone (not spoofing as RFP) but I fail to see how/why that would make a difference. timezone_offsets (plural) comes up mixed because only offsetNanoseconds matches real-world tokyo - all the others have the fractional values returned as integers

e2f4f1bd fake tokyo

"1879": [-558, -558], "1952": [-540, -540], "1976": [-540, -540], "2025": [-540, -540]}

8cf2143d - real-world tokyo

{
  "1879": [-558.9833333333333, -558.9833333333333],
  "1952": [-540, -540],
  "1976": [-540, -540],
  "2025": [-540, -540]
}

which is weird because in your picture they were all real-world results

BoM tampering - hmmm, interesting - not seeing it manifest where I thought it might with your changes - usually you can see the position of properties change (usually after a constructor or expected result) such as in window or function properties, or in element properties and so on - I mean even the existence of uBO (disabled for the web page) still alters the BoM fingerprint - this is not my area of expertise so will dig further

edit: forgot the pic

[anthonysgro]

What browser are you using? On Firefox + spoofing tokyo I am successfully getting all timezone offsets on the correct tokyo. I also tested on LibreWolf with the same results. Mullvad funny enough doesn't even let me spoof timezone (it comes up as Atlantic/Reykjavik).

[Thorin-Oakenpants]

What browser are you using?

FFbeta - its the only one I stuck the extension on. I'll see what happens in stable and nightly. It could be a change upstream

[Thorin-Oakenpants]

btw in windows at least, you can just change your OS timezone and Firefox auto-magically detects the change (not sure when they added a listener) - I didn't even need to reload TZP, just hit the re-run button for the region section (which is not good practice as a tester, I always tend to close existing tabs and use a new fresh page load)

anyway, it definitely isn't upstream - here's tokyo for realsies (system set to that)

Can you add some comprehensive debugging/logging (behind an extension option) so we can diagnose issues like this - thanks