A Pixelscan timezone mismatch means the timezone your browser reports does not agree with where Pixelscan places your IP address, and the fix is to take the timezone from the proxy's exit rather than from your own computer. What we learnt is the part after that: one Pixelscan run is not enough to tell you whether the timezone was ever the problem. When we broke the timezone on purpose, the masking verdict landed on the one row where it was correct.
A FAIL that scrolled past
It started with our detector runner, which loads about fifty public detection pages in one profile and writes a report. One run put fail on the Pixelscan line, with "fingerprint inconsistent, masking detected". It wrote the report, exited 0, and twelve more rows scrolled past. Somebody reading the terminal caught it and asked whether we had noticed. We had not, because nothing in the process said a detector had failed.
So the first fix was to the runner. A fail now makes the run exit non-zero and is listed by name at the end. The other statuses do not: unreachable is the site's problem and unread is our extractor's. Only fail says that a detector read the profile and did not like it.
Pixelscan timezone mismatch, tested one field at a time
Then the question: was it the timezone? The exit was in Slovakia and the profile's timezone was Europe/Vienna, the same offset from UTC under a neighbouring country's name. That looked like a plausible trigger. So we kept one profile, changed only locale.timezone in place, and ran the honest value first and last as controls:
| Timezone | Against the exit | Pixelscan |
|---|---|---|
| Europe/Vienna | agrees (control) | fail: inconsistent, masking detected |
| America/New_York | deliberately wrong | fail: inconsistent, no masking |
| Asia/Tokyo | deliberately wrong | fail: inconsistent, no masking |
| Europe/Vienna | agrees (control) | pass: consistent, no masking |
Read the controls first. The same profile with the same value, minutes apart, answered fail and then pass. When the controls disagree, the rows between them measured nothing. And masking detected landed on a row whose timezone agreed with the exit, not on either row we had broken. The hypothesis that a Slovak exit under an Austrian zone name caused it was dead.
Every profile is drawn from one real computer, not from separate listsIn Mosaic: Machines that exist. GPU, screen, CPU and fonts from one real device. Free holds 3 profiles. Pro is $49 a month for any number.
Mosaic is a desktop app
Email yourself the link and open it on your computer.
How it works: Machines that exist
Three rounds of the same configuration
We then ran Pixelscan alone, three rounds, with nothing changed between them:
| Round | Pixelscan |
|---|---|
| 1 | fail: inconsistent, masking detected |
| 2 | pass: consistent, no masking |
| 3 | pass: consistent, no masking |
And the control that settles whether a verdict is about the profile at all: three paired rounds on an exit that agreed with the profile, our engine beside an untouched Google Chrome from the same machine. All six readings were the same: fail, inconsistent, no masking. On that afternoon "inconsistent" was something a stock Chrome earned too, and masking detected had appeared twice in about fifteen measurements without reproducing on the configuration that produced it. Neither was a finding about the profile, and any single round of those sweeps would have given a confident answer in whichever direction it happened to fall.
So the runner grew --rounds N and an outcome of its own, flaky, which counts as neither pass nor fail. Recording a disagreement as a failure sends the next person after a regression that does not exist. Recording it as a pass is worse.
The tool that told us to delete a defence
The same afternoon caught a second tool. Our GPU check brackets its sweep with the host's own chip at both ends and voids the run if the two disagree. That afternoon they agreed, and both failed:
| GPU claimed | Pixelscan |
|---|---|
| the host's own chip (control) | fail |
| a second Apple chip | fail |
| a third Apple chip | fail |
| the host's own chip (control) | fail |
Its conclusion was that the GPU pin was doing nothing and could stop constraining the draw. Nothing in those four rows says anything about the chip: Pixelscan was failing every configuration, an untouched Chrome included, so the experiment had no range to move in. The check now refuses to conclude unless the control passes, and exits with a code that says so.
What to do with your own timezone mismatch
Start with the boring check. Find where your proxy's exit is, compare it with the timezone your browser reports, and make them agree. In Mosaic a profile's timezone, language and geolocation are drawn for its proxy's measured exit, and with no proxy they follow the computer's own location. Then run Pixelscan three times, and once more in a plain Chrome on the same proxy. If the plain Chrome gets the same verdict, it is not a finding about your profile.
The bisect that did find a real cause, and a real fix, for Pixelscan's masking verdict is in Pixelscan's masking verdict, bisected to one surface. A scan that never finishes is a different symptom, covered in when Pixelscan never stops scanning. How CreepJS decides that a value is a lie, which is a different method again, is in what a CreepJS lie is, and the values the engine changes per profile are listed under real fingerprints.
