A profile in Austria claimed New York

On 29 September 2026 a profile with no proxy, made on a computer in Austria, came out with the timezone America/New_York. A browser location that does not match the IP is the first thing a consistency check looks at, and this one was off by an ocean. The cause was one lookup at app start that failed and was never tried again.

Why a no-proxy profile has to match this computer

A profile with no proxy does not browse from anywhere special. It leaves from the operator's own address, the same one every other app on the machine uses. So its timezone, language and geolocation have to describe that address, or the page sees an Austrian IP beside a clock set to New York.

That comparison costs a site almost nothing. It already has the IP; reading the timezone is one line of script. It is the cheapest contradiction there is, which is why we draw every profile for its exit, proxy or not (how the rest of the machine is drawn to match is on real fingerprints).

The code was already there

None of this was missing. A function resolved the computer's own address, another handed it to the generator, and a create with no proxy was drawn for it. Straight after a fresh start we made six profiles and got de-AT six times, each one reporting a match.

The flaw was when it ran. The lookup happened once, at app start, and nobody waited for it. If that single request failed, the cached answer stayed empty for as long as the app was open. A laptop waking before its wifi, a geolocation service rate-limiting us, an app launched on a train: any of those was enough.

With nothing cached, the generator fell through to its last resort, a table of locales weighted by share of web traffic. That table leans American.

How it works: Machines that exist

Reproducing it

We pointed the lookup at a dead port and made six profiles on the same machine:

Europe/Paris  America/New_York  America/New_York
America/Chicago  Europe/Dublin  Europe/Berlin

Six profiles, six countries, one computer. That is not a weak match. Two draws that disagree with each other cannot both describe one address, so none of them did.

It got worse when we read the response. Every one of the six reported exitMatch: { matched: true }. The branch for profiles with no proxy returned that value as a literal, beside a comment saying the store would pair it with the machine's resolved exit later. It never did. The API told the caller a profile had been pinned to a measured address while its location was being drawn at random.

What we changed

Three changes, all in the code that resolves the direct exit.

1. The create resolves the address itself instead of trusting that start-up already did. Creating a profile behind a proxy already waits for that proxy's exit, on the grounds that nothing is waiting on a create. The same holds with no proxy.
2. A failed lookup is retried, at most once a minute. Retrying per profile would turn one dead network into hundreds of eight-second timeouts in a batch of 500.
3. When the address genuinely cannot be found, the profile takes the computer's own timezone, never the table. A machine that cannot reach a geolocation service still knows what its clock is set to.

Run again with the lookup still dead, the same six creates gave Europe/Brussels six times, which is that machine's setting. Each came back matched: false, with a reason saying the timezone came from the computer rather than a measured address. We would rather report an honest "not measured" than a match that never happened.

A cache filled once is a guess

Nothing at the call site looked wrong. Whenever anyone tested it, it returned a good answer, because they tested on a machine whose start-up lookup had worked. A value fetched once and read for the life of the process stops being a measurement the moment that one fetch fails, and nothing tells you when that happened.

The fix generalises past timezones. Resolve where the value is used. Retry a failure on its own clock, not per item. And when the answer is unknown, fall back to something true about the machine, then label it as that, so nothing downstream mistakes it for a measurement.

When browser location does not match IP: check the profile

The leak test runs from inside the profile's own page. It prints the exit address the page sees, the timezone it reads, and whether the two agree. A no-proxy profile should show this computer's address and its local timezone; a profile behind a proxy should show the proxy's.

The same mismatch is how accounts on one computer end up looking related, which is the subject of keeping accounts from getting linked. What the timezone is one part of is in browser fingerprint, and why profiles stay on this computer at all is on local-first.