IPHey's score moved with the address, not the browser

IPHey's score changes from run to run even when nothing about the browser does. We measured an unmodified, branded Google Chrome on one Mac over one afternoon and got 100, 100, 70 and 0. Same binary, same machine, same settings. So the number tracks the exit and the moment of the read, and the thing worth reading on that page is whether the BROWSER card names the browser.

Four scores from one Chrome

We had spent hours chasing a number. Our profiles scored MX 90 and we treated 100 as a browser's natural state, the target any honest Chrome would hit. Then we ran the control we should have run first: Google's own Chrome, untouched, several times in a row.

run 1   100
run 2   100
run 3    70   SOFTWARE  "Click here to see"  (real Chrome, flagged)
run 4     0   read taken before the page finished

The 70 is the useful one. Real Chrome got a red SOFTWARE card on a run where nothing about Chrome had changed. Whatever IPHey weighed on that run, it was not the browser binary.

"Chrome scores 100" had been three observations treated as a constant. We already had a rule for this, written after other live sites disagreed with themselves: one reading of a third-party verdict is not evidence, so take several rounds and call a disagreement flaky. We had built a whole investigation on a number that broke that rule.

How it works: Machines that exist

The 0 was our probe, not IPHey

The zero deserves its own line, because it nearly turned into a finding. IPHey renders its page as a template first and fills the cards in afterwards. A quick script that read the page with a regular expression over its text caught one browser on the template and the other on the finished page. Every card on one side read Temporary value, beside a 0 MX SCORE.

That looks exactly like a catastrophic result, and it is a probe reading a placeholder. Our detection runner reads IPHey through an extractor that waits for the named cards, and that is the one we use now. A regex over a page that draws a template and then fills it will compare the template and report the difference with complete confidence.

Why the IPHey score changes with the address

The score moves with the exit because half of what IPHey checks is whether the browser agrees with the address. We saw that directly when we ran our engine and Google's Chrome for Testing side by side on the same US residential exit, in the same minute:

card        ours                 Chrome for Testing
BROWSER     red                  red
LOCATION    green, US            red, masked or inconsistent
HARDWARE    fine                 fine
SOFTWARE    fine                 fine
MX SCORE    90                   80

The only card the two disagreed on was LOCATION, and the scores were ten points apart. The untouched browser's timezone and geolocation were the Mac's, in Austria, and the address was American. Ours matched, because a Mosaic profile takes its timezone, language and geolocation from the exit it browses through. Branded Chrome on an Austrian exit, where the Mac's own settings and the address agree, was the browser that scored 100.

The exit itself also carries history. A residential address can already sit in a detector's list as a proxy, which we measured on a Wichita exit in the residential IP several detectors already knew. A score that includes the address inherits whatever the address has done before you got it.

The card that did not move

Across every run, one thing stayed the same: the BROWSER card.

ours    BROWSER  "Click here to see"   the browser cannot be named
stock   BROWSER  Chrome                named

FingerprintJS said the same thing in its own way: it could not name our browser, and it named Chrome. That is a rendered identification, a yes or a no that the address did not change, and it is the thing we should have been fixing from the start instead of the score.

It also turned out to be about our build rather than our profiles. The first real gap behind it was the speech voice list, 199 voices in Chrome against 180 in any unbranded Chromium, written up in 199 voices. The last was the Widevine module handing over a device certificate in the clear, in one key for every profile.

How we read IPHey now

1. Run a control browser on the same exit, in the same minute, and read it first.
2. Take several rounds. A row whose verdict differs between rounds is flaky.
3. Read the cards by name, after the page has filled them.
4. Treat the BROWSER card as the browser's result and the score as the browser plus the address plus the moment.

How the runner keeps a site that was down, a page it could not read and a real failure apart is in running 49 fingerprint tests unattended.