# IPHey masked or inconsistent location data, explained > 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. Source: https://mosaicbrowser.com/blog/iphey-location-card ## Why IPHey's location card can be greener on a profile than on Chrome 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. ![1 card: Same exit, same minute: the location card went our way, beside a screenshot: the Mosaic sidebar with profiles running, each with its own window](https://mosaicbrowser.com/covers/iphey-location-card.webp) IPHey shows "masked or inconsistent location data" when the place your browser describes does not agree with the place your IP address comes from. We saw it on Google's own unmodified Chrome for Testing 153, browsing through a US residential exit. Our profile, through the same exit in the same minute, got a green location card. The browser was nearly the same. The pairing was not: our profile's timezone and geolocation had been moved to the exit, and stock Chrome's had not. ## The run, with a control on the same exit Our detector runner has a `--control` mode. It launches an untouched stock browser beside the profile, so we can tell whether a verdict belongs to us or to every Chromium. For a long time that control had no proxy. It was comparing two browsers and two countries at once, which tells you nothing about either. So we relayed the control through the profile's own proxy. Both browsers left from the same US residential exit, a minute apart: ``` card our profile (Tesseract 153) Chrome for Testing 153 headline Unreliable Unreliable BROWSER red, inconsistent red, inconsistent fingerprint (whale) fingerprint (whale) LOCATION green, United States red, masked or inconsistent location data (light) HARDWARE Everything is fine Everything is fine SOFTWARE Everything is fine Everything is fine MX SCORE 90 80 ``` Most of that table is the two browsers agreeing. The BROWSER card was red on both, with the same `(whale)` label byte for byte. That is a separate story, and it ended at the Widevine module rather than at anything on this card. It is told in [IPHey's whale signal](https://mosaicbrowser.com/blog/iphey-whale-signal). Hardware and software were fine on both. The location row is the one where they differ, and stock Chrome is the one that loses. 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) ## What "masked or inconsistent location data" compares A consistency scanner looks up your IP address and gets a country, a region and a timezone. Then it asks the browser where it thinks it is. Three answers are cheap to read: - the timezone, from `Intl.DateTimeFormat().resolvedOptions().timeZone` and the clock offset; - the geolocation answer, if the page asks for it; - the language, from `navigator.languages` and the `Accept-Language` header. A stock browser behind a proxy answers all three about the computer it runs on. Our Mac is in Austria, so a stock Chrome on it reports a European timezone while its traffic comes out in the United States. The proxy moved the address and nothing else. That gap is what "masked or inconsistent location data" names, and IPHey tagged this one `(light)`. This is also why a VPN on its own leaves the card red. It is the same mechanism with a different tunnel. ## Why the profile's card was green By default, when a Mosaic profile launches, the app looks up where its proxy actually exits and brings the profile into line before the browser starts. Timezone and geolocation move to the exit. The browser applies the timezone itself, so every page, frame and worker reads the same zone. The geolocation answer is a point near the exit's coordinates. The match allows half a degree, roughly 55 km, which is about as precise as an IP geolocation database is anyway. The language follows the exit only on a profile that has never run. `Accept-Language` goes out on every request, so changing it under a logged-in session is a change the site sees. On this run the timezone and the geolocation agreed with the United States, and IPHey's card said so. On the one card where a profile can do better than an untouched browser, ours did. Nothing was hidden from IPHey. Both browsers came from the same address and IPHey could see that plainly. The profile simply told the same story as its exit. ## A scanner grades the pairing The useful lesson is about what this kind of detector measures. IPHey's location card is not a grade for the browser. It is a grade for the browser together with the address it browses from. The same Chrome binary should get a green card on a home connection in Vienna, and it got a red one behind a US proxy. Two things follow when you read a result: 1. A run without a proxy scores the location card well by construction, because the computer's timezone matches the computer's own address. A green card there says nothing about how a profile will do behind a proxy. 2. A control that does not share the exit cannot settle a location question. Ours could not for as long as it had no proxy. IPHey's verdicts also move between loads of one unchanged profile. The causes we found, and why we now take several rounds before believing a score, are in [IPHey's score moved with the address](https://mosaicbrowser.com/blog/iphey-score-moves-with-address). ## When the location card goes red on a profile A profile can still get the red card. The usual cause is a match made against the wrong address. One version of that bug, a lookup that failed once and was never retried, is in [a profile in Austria claimed New York](https://mosaicbrowser.com/blog/austria-claimed-new-york). The other common cause is a proxy that rotated to a new country after the profile was matched, which the next launch puts right as long as the profile still matches its exit on launch, the default. A profile drawn for its exit from the start, with timezone, language and geolocation chosen together, is what [real fingerprints](https://mosaicbrowser.com/features/real-fingerprints) covers. The leak test reads the exit address and the timezone from inside the profile's own page, so you can check the pairing before IPHey does. ## Questions ### What does IPHey's masked or inconsistent location data mean? It means the location your browser describes does not agree with the location of your IP address. The usual cause is a proxy or VPN in one country and a browser timezone, and geolocation, still set to the computer's own. ### Will a VPN fix IPHey's location card? Not by itself. A VPN moves the IP address and leaves the browser reporting your computer's own timezone, so the two disagree. That is the case IPHey's card is written to catch. ### Does a green location card mean IPHey cannot tell I use a proxy? No. It means the browser's description of where it is agrees with the address. In the run described here the overall verdict was still Unreliable, for a reason on a different card. ### How does Mosaic keep the location consistent? By default, at every launch it looks up where the profile's proxy actually exits and moves the timezone and geolocation to match before the browser starts. The language moves too, but only on a profile that has never been used. ## Related [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. [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. [A profile in Austria claimed New York](https://mosaicbrowser.com/blog/austria-claimed-new-york): Browser location does not match IP: a no-proxy profile made in Austria claimed New York. One failed lookup was never retried, and a table filled the gap. [Machines that exist: fingerprints drawn from real hardware](https://mosaicbrowser.com/features/real-fingerprints): Mosaic draws each profile's GPU, screen, CPU, memory and fonts from one real device, so the parts of a fingerprint agree with each other and with the host. [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. [Same IPHey score, opposite reasons](https://mosaicbrowser.com/blog/iphey-same-score-different-signal): 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. [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. [Header order is a fingerprint, and a tunnel cannot touch it](https://mosaicbrowser.com/blog/chrome-header-order-through-a-proxy): Sites read the order of Chrome's HTTP headers as well as their values. Through a CONNECT tunnel a relay carries ciphertext, so it cannot reorder a thing. ## 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.