# IPHey Unreliable on normal Chrome? Read which card > IPHey Unreliable on a normal Chrome is usually the exit. Our profile and a stock Chrome both got MX 90, for a browser signal and a location signal. Source: https://mosaicbrowser.com/blog/iphey-same-score-different-signal ## Same IPHey score, opposite reasons IPHey Unreliable on a normal Chrome is usually the exit. Our profile and a stock Chrome both got MX 90, for a browser signal and a location signal. ![90: Both scored 90. Only one was about the browser., beside a screenshot: a Mosaic leak test: every surface a site reads, checked from inside the profile page](https://mosaicbrowser.com/covers/iphey-same-score-different-signal.webp) When a normal Chrome scores Unreliable on IPHey, the cause is almost always the connection, and the red card says which. We learned the more expensive half of that lesson by trusting the number. Our profile and an untouched stock browser both came back Unreliable, MX 90/100, and our test runner told us to ignore the row. The two verdicts had nothing to do with each other. ## What the runner printed Mosaic's detection runner can run every detector twice, once through a profile and once through a stock browser as a control. Any row where the two agree is reported as not our problem, because a verdict an untouched browser also earns is not a finding about the profile. For IPHey, on 18 September 2026, it printed this: ``` row ours stock iphey attention attention <- same 1 non-passing row answered identically for an untouched browser: iphey. Those are not findings about the profile. Do not chase them. ``` Both browsers had scored Unreliable, MX 90/100. Read the cards, though, and they did not agree at all: ``` ours Browser · Detected an inconsistent browser fingerprint control Location · Detected masked or inconsistent location data ``` ## Two 90s with different causes IPHey's score is built from five cards: Browser, Location, IP address, Hardware, Software. A red card costs points, and as these two rows show, different red cards can cost the same points. The 90 on its own does not say which card. The control's red card was location. That is about the exit, a residential address whose own reputation and geography IPHey did not like, and it is expected and uninteresting. A location card belongs to the exit that browser left from, and nothing guaranteed the two runs had left from the same one. A location signal on one of them says nothing about the other. Ours was a browser signal: IPHey reading our engine and deciding the fingerprint did not hang together. That is the one kind of finding Tesseract Chrome exists to remove, and the runner had just told us not to chase it. 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) ## Why the comparison missed it The line that decided "same" read the status band and nothing else: ``` row.status === row.control.status ``` Both rows were `attention`, so the comparison called them equal. It had no way to see that one attention was about a browser and the other about an address. A detector that folds five causes into one score will produce collisions like this all the time, and a comparison on the score treats every collision as agreement. ## The fix: compare the signal, not just the band The runner now compares the signal as well. It takes the first 120 characters of each row's detail, lowercases them, collapses whitespace and replaces every run of digits with `N`. The digits go because a visitor id or a count of checks moving is not a different verdict. Anything else differing is a different verdict. A row is dismissed only when the band and the signal both match. When the band matches and the signal does not, it is printed as its own case: ``` iphey attention attention <- same band, different signal ``` and listed under the comparison as something to read, not something to skip. We chose to err that way on purpose. A false alarm here costs one person reading two detector cards. A false dismissal costs the finding, because a row the tool says to ignore is a row nobody opens again. An alarm gets investigated; a dismissal gets believed. ## What the browser signal turned out to be The comparison had one job, to stop us ignoring the row. Following it took longer, through the Chrome version, through the difference between branded Chrome and unbranded Chromium, and finally to the Widevine module sending a per-install device certificate in the clear. That story, with every wrong turn in it, is in [IPHey's "(whale)" signal](https://mosaicbrowser.com/blog/iphey-whale-signal). ## Reading IPHey on your own Chrome If your everyday Chrome says Unreliable, open the card that is red before anything else. - **Location or IP red** with a green browser card means the connection: a VPN, a proxy, a DNS resolver somewhere else, or an address with a history. Turn the VPN off and re-run; if it goes green, that was it. - **Browser red** on a stock Chrome is rarer and worth a second run, because live detectors disagree with themselves. We measured untouched Chrome at 100, 100, 70 and 0 in one afternoon, the 0 a reading taken before the page had finished ([IPHey's score moves on unmodified Chrome](https://mosaicbrowser.com/blog/iphey-score-moves) has the cards behind each). - **Comparing two browsers**, send both through the same exit in the same minute and compare which card is red and the sentence on it. The number alone matched for us when nothing else did. How our runner tells a failed profile from a dead page or a broken extractor, across the whole catalogue, is in [automating fingerprint tests](https://mosaicbrowser.com/blog/automating-fingerprint-tests). ## Questions ### Why does IPHey say Unreliable on a normal Chrome? Usually because of the connection, not the browser. A VPN, a proxy, a DNS resolver in another country or an address with a poor reputation each turn a card red, and the headline drops to Unreliable on an untouched Chrome. The red card names which. ### Does the same IPHey score mean the same problem? No. We measured two browsers at Unreliable, MX 90, one flagged for an inconsistent browser fingerprint and the other for masked or inconsistent location data. Same number, unrelated causes. ### How should I compare a profile with a control browser on IPHey? Compare the signal as well as the band. Write down which card is red and its sentence for both browsers, and send both through the same exit in the same minute, or a location signal from one exit will be read as a finding about the other. ### Is a location signal on IPHey my browser's fault? Not by itself. Location data being masked or inconsistent is a property of the exit and how it agrees with the browser's timezone and language. Fix the pairing first, then read the browser card. ## Related [IPHey's score moves on unmodified Chrome. Read the card.](https://mosaicbrowser.com/blog/iphey-score-moves): A low IPHey MX score is the sum of five cards. Untouched Chrome scored 100, 100, 70 and 0 in one afternoon, so the red card tells you more than the number. [IPHey's "(whale)" signal, and what it was really about](https://mosaicbrowser.com/blog/iphey-whale-signal): IPHey's inconsistent browser fingerprint (whale) looked like a version problem. We followed it through branding and JavaScript to a Widevine certificate. [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. [IPHey's score moved with the address, not the browser](https://mosaicbrowser.com/blog/iphey-score-moves-with-address): 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. [Chrome opens connections before your test starts](https://mosaicbrowser.com/blog/chrome-preconnects-before-you-measure): We counted 1, 0 and 0 CONNECTs in three launches and thought Chrome was bypassing the proxy for HTTPS. Our counter was reset after Chrome had started. [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 IPHey's location card can be greener on a profile than on Chrome](https://mosaicbrowser.com/blog/iphey-location-card): On one US exit in one minute, stock Chrome got IPHey's masked or inconsistent location data and our profile got green. The difference was the timezone. [A spoof that answers once: the geolocation bug we shipped](https://mosaicbrowser.com/blog/geolocation-answered-once): A geolocation spoofing timeout we shipped: the first getCurrentPosition got the exit's coordinates, every later call failed with code 3. One latch was to blame. ## 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.