344 profiles said "denied": one value, everywhere

Notification permission is a fingerprint the moment it is the same everywhere. In September 2026 we found Notification.permission reading denied on all 344 profiles on our build Mac, while an unconfigured Chrome says default. No single profile looked strange on its own. Together they all shared one uncommon value, which is exactly what a site needs to group accounts.

How notification permission becomes a fingerprint

Two calls report the state without asking the user anything. Notification.permission returns default, granted or denied. navigator.permissions.query({ name: 'notifications' }) returns prompt, granted or denied. Neither shows a dialog, so any script can read them on page load.

A fresh browser that nobody has configured says default and prompt. denied means somebody refused: the person, an administrator's policy, or a setting. That is not rare in itself. It becomes a signal when it arrives on every account a site suspects of being run from one place.

How it works: Machines that exist

Why we forced it

The setting came from our launcher. Each launch wrote the notifications content setting as blocked into the profile's preferences, and the reason was a real one when it was written.

macOS greets every app identity it has not seen before with a banner, once and for ever, saying that app's notifications "may include alerts, sounds and icon badges". Early on, each Mosaic profile ran under its own app bundle with its own identifier, so every new profile risked one more of those banners. Blocking notifications for every launch stopped the browser from asking macOS at all.

Then the bundles changed. They became one per window slot instead of one per profile, which caps the banners at five for the life of an install. The reason for blocking was gone. The cost was not, and nobody re-read the sentence that justified it.

The exemption that hid it

We have a sweep for this class of fault. It draws two profiles that share nothing, reads the same values in both, and reports anything identical that should not be. The notification row was in it, reading denied in both halves, and it sat on the list of expected matches with a six-word excuse: "blocked on purpose; see preparePreferences".

That excuse was true. It was blocked on purpose. The purpose had expired, and the exemption had no way to notice. An exemption is only worth as much as someone re-reading its reason.

The fault also runs in the opposite direction from the one we usually look for. We had spent the week finding values that leaked in from the host, like the dark-mode and accessibility settings the computer itself had turned on. This one did not leak in. We pinned it, the same across the whole population and different from stock Chrome. A site reads both cases the same way.

What changed

Blocking notifications is a privacy setting now, privacy.blockNotifications, and it is off by default. We measured the result through the app, on a profile launched the ordinary way:

Notification.permission                        "default"
permissions.query({name: 'notifications'})     "prompt"
macOS registered notification bundles          68 before, 68 after

The last line is the reason the original block existed. With window-slot bundles, launching a profile no longer registers anything new with macOS, so the banner it was there to prevent does not arrive.

The rule we took from it

Before a value is pinned across every profile, compare it with what a stock Chrome of the same version on the same machine reports. If they differ, the pin is a fingerprint, whatever it was meant to prevent. A geolocation that answered once was a value that behaved like no real device. This one behaved like no real population.

Where the rest of a profile's values come from is on real fingerprints, and what a site can read without a prompt is listed in browser fingerprint. The same habit, checking the profile against what it claims, is how we found a profile in Austria claiming New York.