A timezone that disagrees with the exit address

It requires no fingerprinting library, no machine learning and no third-party service. Any request already carries the address. Intl.DateTimeFormat().resolvedOptions() returns the timezone in one call. A geolocation database lookup of the address is a table read.

That is the whole check. A browser reporting a European timezone on a South American address does not need to be analysed. It has volunteered a contradiction.

And it is not just the identifier. The offset is visible in every Date a page constructs, in the Date header comparison a script can make against a server response, and in any timestamp the page sends back.

Most tools in this category present the timezone as a dropdown next to the other fingerprint settings. Pick a country. Pick a timezone. Pick a language. They sit in a list, they are all optional, and they are all the operator's problem.

That is backwards, and it is backwards in a way that guarantees mistakes at scale. When you have four profiles you will get all four right. When you have sixty, and eleven of them changed endpoint last month because the provider rotated a pool, some of them are now describing a timezone from the wrong continent, and nothing anywhere will tell you which ones.

The value should not be chosen. It should be derived, from the only piece of evidence that actually determines it.

Before a profile launches, Ward's relay dials the upstream proxy and reads back the address the traffic will exit from. If that fails, the launch refuses rather than opening a window that would browse from the operator's own address.

That probe is doing double duty. It is the safety check, and it is also the input the timezone is generated against. The profile's timezone comes from where it will actually appear to be, not from a list.

The chain is four steps and each one is a table lookup:

proxy exit country (ISO 3166-1 alpha-2)
  -> country-to-zone map in the device catalogue  -> IANA zone
  -> representative coordinates for that zone
  -> jittered by the profile's own seed           -> the position it reports

The coordinates hang off the zone rather than off the country deliberately. The country-to-zone map already exists and is the thing an operator would refresh; a second country-keyed table would be two sources of one fact, and the failure mode of two sources of one fact is that they disagree six months later. It also means a timezone the operator types by hand resolves to a position with no extra data.

What that costs, plainly: the map names one city per zone, so a profile exiting from Hamburg reports Berlin's coordinates. That is a person who has not corrected their browser's idea of where they are, which is ordinary. The contradiction the chain exists to prevent is the other one - a German address reporting a New York clock.

The knock-on effects are worth spelling out:

1. A profile cannot contradict its own proxy. Not by default, not by mistake, and not after a provider rotated the pool.
2. The locale follows the same source. Language and locale are generated from the exit address too, and then the operator's explicit override is applied on top if they set one. Somebody deliberately running an English-language profile from a Warsaw exit is a completely ordinary person; somebody accidentally running a Warsaw timezone from a São Paulo exit is a mistake.
3. The interface language is a separate decision from the fingerprint. This is a subtle one and it was measured the hard way. The browser's own interface language switch is what navigator.language reports when there is no override countermanding it - and a profile whose language surface is set to report truthfully forbids that override. Deriving the interface language from the fingerprint therefore made a live launch with a truthful language policy report the generated locale instead of the real one. The two are separate inputs to a launch for exactly that reason.

Everything above describes a derivation that exists in the launch path and can be read in the source. One half of it has not been exercised against a paid endpoint on the machine this was written on.

The refusal half is proven: a profile pointed at a dead port is refused rather than opened, and the relay has been shown not to fall back to a direct connection across eleven different ways of breaking an upstream. The success half - a real credentialed endpoint, a real exit address coming back, and a site confirming that address is the one it sees - has never been run here, because it needs a subscription this project does not have.

So read the claim precisely. The timezone a profile reports is derived from whatever country the probe returns; that is code, and it is checkable. That the probe returns the right country through a commercial residential pool is a thing this journal has not yet watched happen, and it will say so on the day it does.

Deriving the timezone removes a contradiction. It does not make a session indistinguishable from an ordinary one, and this site never says otherwise.

There is a stronger version of this check that a site can run and that no profile manager can answer: comparing the reported timezone against behaviour over time. An account whose activity clusters in one part of the day, from an address whose local time makes that pattern unusual, is describing a person who does not exist. Nothing in a settings panel fixes that, because the value being measured is not a value, it is a habit.

The honest position is that coherence is necessary and not sufficient. Getting the timezone right removes the free catch. What remains is everything that takes real work to detect, and those are the checks that decide outcomes.