# Browser fingerprint values inherited from the host > A browser fingerprint value inherited from the host is identical across two unrelated profiles and equal to the computer. That test found dark mode and more. Source: https://mosaicbrowser.com/blog/values-inherited-from-the-host ## The values every profile inherited from this Mac A browser fingerprint value inherited from the host is identical across two unrelated profiles and equal to the computer. That test found dark mode and more. ![Identical in two profiles and equal to this Mac](https://mosaicbrowser.com/covers/values-inherited-from-the-host.webp) A browser fingerprint value is inherited from the host when the profile reports this computer's own setting instead of one it was drawn with. In September 2026 we drew two profiles with nothing in common, opened the same probe page in each, and printed macOS's settings beside them. Six values came back identical in both profiles and equal to the Mac: dark mode, reduced motion, reduced transparency, the panel's gamut, the monitor count and the scrollbar width. Every profile on that machine was sending all six. ## Why a shared value is worse than a revealing one An inherited value is real, which is why nobody notices it. Open one profile and `prefers-color-scheme: dark` looks like any other dark-mode Mac. Open a second profile, drawn as a different machine with a different GPU and screen, and it says `dark` too, for no reason except that the Mac running both is set to dark. A site never has to work out which value came from the host. If it suspects ten accounts belong to one person, it looks for a field all ten agree on, and an inherited value is that field. ## Finding browser fingerprint values inherited from the host The question that started it was small: do profiles randomise dark mode? They did not. So we drew two profiles with different machines, screens and GPUs, loaded a local page in each that also asked for every client hint, and printed macOS's own settings beside them: ``` prefers-reduced-motion reduce reduce macOS: reduceMotion = 1 prefers-reduced-transparency reduce reduce macOS: reduceTransparency = 1 prefers-color-scheme dark dark macOS: Dark color-gamut p3 p3 a Liquid Retina XDR panel screen.isExtended false false one display scrollbar width 15 15 "Show scroll bars: Always" ``` The same values left in request headers too, as `Sec-CH-Prefers-Color-Scheme: dark`, `Sec-CH-Prefers-Reduced-Motion: reduce` and `Sec-CH-Prefers-Reduced-Transparency: reduce`. A site could read them without running any script. Dark mode was the least serious row. Reduced motion and reduced transparency are accessibility settings a small minority turns on, so every profile on this Mac carried a rare trait, and the same rare trait. 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) ## Four more, found the same week Running the same comparison against branded Chrome on this Mac turned up four values that were wrong the other way round, pinned or invented rather than inherited: - `Notification.permission` read `denied` on all 344 profiles. We forced it at launch to stop a macOS banner when every profile had its own bundle identifier; bundles later moved to one per window slot and the reason went with them, but the setting stayed. An unconfigured Chrome says `default`. It is now `privacy.blockNotifications`, off unless you turn it on, and pages read `default` again. - `color-gamut` said `p3` while `dynamic-range` said `standard`, because `--force-color-profile=display-p3-d65` moved one and not the other. A Mac with a ten-bit panel answers `high`. Our first replacement, `hdr10`, visibly washed out every page ([a canvas readback is not a rendering check](https://mosaicbrowser.com/blog/hdr10-washed-out) has the screen captures). - `AudioContext.outputLatency` was `0.010666666666666666` on a suspended context where branded Chrome 153 reads `0`, because patch `0112` answered before any audio had rendered. - The stored CPU architecture was the string `x86` on every desktop profile, on an Apple silicon Mac whose pages read `arm`. No switch moves that value and stock Chrome here says `arm` as well, so the record now stores the host's architecture and the repair corrected the old profiles. ## Two that looked inherited and were not The first pass also listed `performance.memory.jsHeapSizeLimit` and hardware HEVC decode. Both matched the host. Both were dropped once we ran the control, the machine's own Google Chrome on the same page: ``` stock Chrome 153.0.8010.52 perf.jsHeapSizeLimit 4395630592 the same number we report media.hevc true/true/true the same hardware decode ``` A host value is only a leak if it separates a profile from an ordinary browser on the same computer. Every Chrome on this machine reports that heap limit. Moving it would make our profiles the only browsers here that disagree with themselves. The browser accent colour was another false alarm: `rgb(0, 117, 255)` on every profile, which turned out to be a constant in Chromium itself, the same on every Chrome on macOS. Using [Google's own build as the control](https://mosaicbrowser.com/blog/the-control-is-googles-build) is how we tell these apart. ## What the profiles carry now Each of the six is drawn per profile. Dark mode comes up for 30% of profiles, which is nearer what Chrome actually sends than the four-in-five figure surveys report; reduced motion for 4%, reduced transparency for 2%. Where stock Chromium had a switch for a setting we used it. `screen.isExtended`, the `(color: N)` media query and overlay scrollbars had none, so they became patches `0142`, `0143` and `0144`. `buildPreferences` takes the profile's seed, not `Math.random`. A profile made before the change gets its values the first time the store reads it, and the same values on every launch after, which covered all 344 existing profiles without rewriting a file. ![A Mosaic profile fingerprint with screen, fonts, timezone and language drawn for the profile](https://mosaicbrowser.com/shots/fingerprint-detail.png) *Drawn per profile, from the profile's own seed* ## Run the comparison first It took one afternoon and found what a year of feature work had walked past. The question that started it was only whether profiles randomise dark mode. The sweep is now `check:inherited`, run after any change to how a profile launches. The same failure showed up in time zones a few weeks earlier, when [a profile in Austria claimed New York](https://mosaicbrowser.com/blog/austria-claimed-new-york). How the rest of a profile is drawn together is on [real fingerprints](https://mosaicbrowser.com/features/real-fingerprints), and the general idea is in [browser fingerprint](https://mosaicbrowser.com/glossary/browser-fingerprint). ## Questions ### What does it mean for a fingerprint value to be inherited from the host? The browser reports what the real computer says instead of what the profile claims. Every profile on that computer then shares the value, so a site can group them by it. ### How do you find inherited values? Make two profiles that share nothing, read the same surface in both, and compare with what the computer itself reports. A value identical in both profiles and equal to the machine is inherited. ### Is every value that matches the host a leak? No. If an ordinary Chrome on the same computer reports the same value, it does not separate a profile from a normal browser. The JavaScript heap limit and hardware video decode were two such cases in our sweep. ### Does Mosaic fix values like these for profiles that already exist? The display and accessibility preferences are drawn from each profile's own seed the first time they are read, so older profiles get a value without being rewritten, and the same value every launch after. ## Related [A canvas readback is not a rendering check](https://mosaicbrowser.com/blog/hdr10-washed-out): Forcing Chrome's colour profile to hdr10 lifted a page's dark background and dimmed its white on macOS. Four checks missed it; a screen capture did not. [The control that settles "is it our patches?"](https://mosaicbrowser.com/blog/the-control-is-googles-build): Unpatched Chrome for Testing got the same IPHey verdict as our engine, so our patches were not the cause. Its voice list still differs from Chrome's. [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. [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.    ## 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.