# Pixelscan false positive: stock Chrome, 3 in 20 > A Pixelscan false positive, measured: an untouched Google Chrome read 'Masking detected' on 3 of 20 runs. Our fresh profiles read it once in 74. Source: https://mosaicbrowser.com/blog/pixelscan-masks-stock-chrome ## Pixelscan calls a stock Chrome masked 3 times in 20 A Pixelscan false positive, measured: an untouched Google Chrome read 'Masking detected' on 3 of 20 runs. Our fresh profiles read it once in 74. ![3 in 20: Stock Chrome, masked 3 times in 20, beside a screenshot: a profile fingerprint in Mosaic: GPU, screen, fonts, timezone and language matched to the exit](https://mosaicbrowser.com/covers/pixelscan-masks-stock-chrome.webp) A Pixelscan false positive is easy to produce: run Google's own browser through it enough times. In September 2026 we ran an untouched Google Chrome through Pixelscan's fingerprint check 20 times on one Mac. It came back clean 16 times, said "inconsistent, Masking detected" 3 times, and gave no verdict once. Over the same weeks, fresh Mosaic profiles on that Mac read masked once in 74 runs. We ran that control because "it sometimes gets detected" needed an answer, and the verdict alone could not tell us whose fault it was. ## What we were trying to settle Pixelscan is built to catch anti-detect browsers. It cross-checks a fingerprint against the IP and against itself and names what it thinks does not fit. When it flags one of our profiles, we want to know whether the profile is wrong or the site is in a mood. Everything below was measured on one macOS host with no proxy on any row. Our only saved exit had run out of bandwidth, and we said so in the notes instead of working around it. Half of what a consistency scanner measures is whether the IP agrees with the timezone and the language, so a run with no proxy is the plainest case it gets. ## Our profiles first We started with the library. Every profile on the machine went through `auditFingerprint`, the same audit the profile editor draws: 45 profiles, 0 problems, 0 warnings. Then the population the generator makes now. Fresh profiles were created through `POST /profiles`, started, read and deleted by id, and we read all five of Pixelscan's cards each time, not only the headline: ``` 8 profiles x 3 rounds 24/24 clean 3 profiles x 3 rounds, pinned mba13-m4 9/9 clean 20 profiles x 1 round 20/20 clean 3 Android profiles x 2 rounds 6/6 clean ``` Those profiles covered fifteen different Apple chips across M1, M2, M3 and M4, including Pro, Max and Ultra. One observation in 74 came back masked, on a profile drawn as `mba13-m4`. That same device then passed nine runs in a row and two more in a later sweep. ![A Mosaic profile's fingerprint: GPU, screen, fonts, timezone and language drawn together](https://mosaicbrowser.com/shots/fingerprint-detail.png) *Each profile is drawn from one real device record* 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) ## Then stock Chrome, which is the whole point The control was a Google Chrome with nothing changed: off-screen but headed, a fresh profile directory every run, the same machine and the same address, the same five cards read the same way. ``` stock Chrome, 20 runs 16 clean, 3 "inconsistent, Masking detected", 1 no verdict ``` So Pixelscan called Google's own browser masked about once in every six runs that gave a verdict, and called our profiles masked about once in seventy. Whatever that verdict was measuring on those runs, it was not something Mosaic does. Our rule for this case is short: a verdict that a stock browser of the same major version also produces is not a finding about the profile. We had been bitten by skipping this step before. Four rounds of configuration bisection went into an earlier Pixelscan result before anyone launched a stock browser at it, which took under a minute and settled it. ## The half that was ours "Sometimes it gets detected" turned out to have two answers. The reproducible one was a platform claim. A profile claiming a different desktop OS from the computer it ran on failed every time, and Pixelscan's own readout printed the reason in its font row. A profile claiming macOS on our Mac showed 159 fonts, starting "Al Bayan, Al Nile, Al Tarikh". One claiming Linux showed a single font, Abyssinica SIL. Pixelscan probes the fonts of the platform the browser claims, and the fonts that answer are the ones installed on the real machine. No switch in the engine reaches them. That is why the profile editor shows a caution when a profile claims a different desktop OS from the computer's own, and why the strongest match is always the OS your computer runs. The other half, the occasional masked verdict, was the site disagreeing with itself, and it did so more often for stock Chrome than for us. ## Two harness bugs we found by reading every card Neither was a fingerprint problem, and both would have given us a confident wrong answer. The card reader matched Pixelscan's menu. Looking for the word "Fingerprint" in the page text finds the site's navigation, "Fingerprint Check" and "Checkers", long before it finds the result card. Six clean profiles were reported as six failures with the fingerprint card reading "Checkers". A detector that fails every configuration is usually measuring your extractor, and this one was measuring a menu. The reader now cuts the page down to the scan section first. The headline paints in two steps. It passes through "Your Browser Fingerprint is" with the verdict word not yet drawn, and a poller that only waited for "scanning" to disappear caught that frame. One run in twenty scored a failure with all five cards clean underneath it. The wait is now for the verdict word itself. ## How to tell a Pixelscan false positive from a real problem If Pixelscan flags a profile once, run it again before changing anything. If it flags it every time, read the cards: the useful ones name a cause, such as a font list that does not belong to the claimed platform. And if you can, run a stock Chrome of the same version from the same machine beside it. If that gets the same verdict, the verdict is about the site or the setup, not about the profile. Mosaic's fingerprint values are changed in C++ inside Tesseract Chrome, our own Chromium, so every page, frame and worker reads the same machine; why we built it that way is in [why we built our own Chromium](https://mosaicbrowser.com/blog/why-we-built-our-own-chromium). Each profile is drawn whole from one device record, which is what [real fingerprints](https://mosaicbrowser.com/features/real-fingerprints) covers. For which values a page can read in the first place, see [what a browser fingerprint is](https://mosaicbrowser.com/glossary/browser-fingerprint). Not every flag is about the fingerprint at all: one DevTools command is enough to flip another detector on its own, which is in [Runtime.enable detection](https://mosaicbrowser.com/blog/runtime-enable-detection). ## Questions ### Can Pixelscan give a false positive? Yes. In September 2026 we ran an untouched Google Chrome through Pixelscan's fingerprint check 20 times on one Mac, with a fresh profile directory each time. It read 'inconsistent, Masking detected' on 3 of those runs. ### How do I tell a Pixelscan false positive from a real problem? Run the same check several times, and run a stock Chrome of the same version from the same machine and address beside it. A verdict that comes and goes, and that stock Chrome also gets, is not about your profile. One that repeats and names a cause is. ### What made Pixelscan flag Mosaic profiles every time? A profile claiming a different desktop OS from the computer it ran on. Pixelscan reads the font list of the claimed platform, and the fonts come from the real machine: 159 fonts for a macOS claim on our Mac, one for a Linux claim. ### Did these runs use a proxy? No. Our only saved exit had run out of bandwidth, so every row was measured from the same home connection. That pairing matters, because part of what Pixelscan scores is whether the IP agrees with the timezone and language. ## Related [Why we built our own Chromium instead of injecting JavaScript](https://mosaicbrowser.com/blog/why-we-built-our-own-chromium): Mosaic changes fingerprint values in C++ inside its own engine. Three measured differences between Chrome and plain Chromium explain why that matters. [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. [Browser fingerprint: what a site can read about your machine](https://mosaicbrowser.com/glossary/browser-fingerprint): A browser fingerprint is the set of values a site reads about your browser and computer, which together recognize you without cookies. What goes into one. [Runtime.enable flips a detector, so we don't call it](https://mosaicbrowser.com/blog/runtime-enable-detection): Runtime.enable detection, measured: one DevTools command turned a clean Mosaic profile into isBot=true on deviceandbrowserinfo. We removed all five calls.     ## 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.