# IPHey score changes: 100, 100, 70, 0 on one Chrome > IPHey score changes even on an untouched Chrome: 100, 100, 70 and 0 in one afternoon. The score follows the exit and the moment; the browser card does not. Source: https://mosaicbrowser.com/blog/iphey-score-moves-with-address ## IPHey's score moved with the address, not the browser IPHey score changes even on an untouched Chrome: 100, 100, 70 and 0 in one afternoon. The score follows the exit and the moment; the browser card does not. ![70: Branded Chrome, one Mac, one afternoon: 100, 100, 70, 0](https://mosaicbrowser.com/covers/iphey-score-moves-with-address.webp) 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. Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: Machines that exist](https://mosaicbrowser.com/features/real-fingerprints) ## 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](https://mosaicbrowser.com/blog/residential-ip-detected-as-proxy). 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](https://mosaicbrowser.com/blog/chromium-speech-voices). The last was the Widevine module handing over a device certificate in the clear, in [one key for every profile](https://mosaicbrowser.com/blog/widevine-device-certificate). ## 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](https://mosaicbrowser.com/blog/automating-fingerprint-tests). ## Questions ### Why does my IPHey score change between runs? Because a large part of it is about the address and the moment, not the browser. An unmodified Google Chrome on our Mac scored 100, 100, 70 and 0 in one afternoon, with nothing about the browser changed between runs. ### What does a 0 on IPHey mean? In our runs, the 0 was a reading taken before the page had finished. IPHey draws its cards as placeholders first and fills them in, so a read that comes too early sees the template and a zero score. ### What should I read on IPHey instead of the score? The BROWSER card. Across every run it either named the browser, as Chrome, or said it could not. That answer did not move with the address, and it was the one that pointed at a real difference. ### How many IPHey runs are enough? More than one, with a control browser on the same exit in the same minute. If the runs disagree with each other, the honest label is flaky, which is neither a pass nor a fail. ## Related [Running 49 fingerprint tests unattended, and what that takes](https://mosaicbrowser.com/blog/automating-fingerprint-tests): To automate browser fingerprint testing, tell a failed profile from a dead site, an unreadable page and your own bug. Our runner names each across 49 rows. [199 voices: how a speech list tells Chromium from Chrome](https://mosaicbrowser.com/blog/chromium-speech-voices): speechSynthesis.getVoices() lists 199 voices in Google Chrome on our Mac and 180 in any unbranded Chromium. A page reads the difference in one call. [Widevine device certificate privacy: one key for every profile](https://mosaicbrowser.com/blog/widevine-device-certificate): Widevine device certificate privacy needs a Google-signed browser. Without it, the first licence message is 1704 bytes where Chrome sends 2. [The residential IP several detectors already knew](https://mosaicbrowser.com/blog/residential-ip-detected-as-proxy): A residential proxy can be detected as a proxy because it is one. On one Wichita exit, FingerprintJS and incolumitas never loaded in three rounds. [A Russian exit and a profile speaking Mexican Spanish](https://mosaicbrowser.com/blog/accept-language-and-proxy-country): A profile matched to a Russian exit kept sending es-MX in Accept-Language. Leaving the language alone was right. Saying nothing about it was the bug. [We broke the timezone on purpose and Pixelscan liked it better](https://mosaicbrowser.com/blog/pixelscan-timezone-sweep): We changed only the timezone on one profile behind a Slovak exit. Pixelscan flagged masking on the Vienna row, the correct one, and the controls disagreed. [The RTT client hint, read off the wire](https://mosaicbrowser.com/blog/rtt-on-the-wire): ECT, RTT and Downlink headers behind a proxy, measured: a claimed round trip moved JavaScript to 300 and left the RTT header at 50. So we claim neither. [Why hCaptcha gives some browsers a puzzle every time](https://mosaicbrowser.com/blog/hcaptcha-image-challenge-every-time): hCaptcha's challenge is its score. A puzzle every time usually means blocked cookies, a crowded VPN exit or a browser whose values disagree with each other. ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. 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.