The values every profile inherited from this Mac

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.

How it works: Machines that exist

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 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 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.

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. How the rest of a profile is drawn together is on real fingerprints, and the general idea is in browser fingerprint.