2046186 - Apply the AccentColor / Highlight / SelectedItem standin on macOS

Status: NEW

(Core :: Privacy: Anti-Tracking, enhancement)

Description

[Tom Ritter [:tjr]]

Firefox on macOS exposes the user's real OS accent color, selection background, and selected-content background to web content via the AccentColor, Highlight, and SelectedItem CSS system-color keywords. Safari (WebKit) already returns a static color for these keywords; Firefox on Windows already returns a brand-color standin for AccentColor for the same fingerprinting reason. Firefox on macOS does not, and the resulting values carry several bits of stable per-user fingerprint signal. This proposes extending the existing brand-color standin to cover the macOS case.

Background

The CSS Working Group has an open issue (csswg-drafts#10372, "Mitigating fingerprinting for AccentColor/AccentColorText") that explicitly recommends: "Prevent getComputedStyle() from returning the actual system color; return either a fixed fallback or alternative value."

• Safari (WebKit) already does this — returns a static color rather than the real OS value.
• Firefox on Windows already does this for AccentColor / AccentColorText via the brand color #0060DF (widget::sDefaultAccent).
• Firefox on macOS does not — content reads the real values directly.

On macOS, three different NSColor APIs feed Firefox's resolution of these CSS keywords:

• NSColor.controlAccentColor → CSS AccentColor
• NSColor.selectedTextBackgroundColor → CSS Highlight
• NSColor.selectedContentBackgroundColor → CSS SelectedItem

These are separate APIs returning separate values; standing in one does not affect the others. All three currently reach content unmitigated.

Measured fingerprint surface

Across 2.22M deduped macOS clients in the user-characteristics ping (March–April 2026):

CSS keyword	Shannon entropy	Distinct values
AccentColor	1.17 bits	60
Highlight	2.41 bits	14,901
SelectedItem	2.72 bits	1,325

AccentColor is well-bounded (macOS's controlAccentColor returns one of ~24 named accents). The real fingerprint surface is Highlight and SelectedItem, which mix in additional state: macOS version drift, Increase Contrast / Reduce Transparency accessibility settings, display color profile, and wallpaper-derived "multicolor" accents introduced in macOS Sonoma. These values are stable per user across page loads and sessions (getComputedStyle() returns the source color directly, not a per-page blend).

Joint information across the three keywords is roughly 5 bits before correlation, less after — but the entropy is real and persistent, and a fingerprinter can read it through any of three CSS keywords.

Proposed fix

Apply the existing Firefox brand-color standin (widget::sDefaultAccent = #0060DF, widget::sDefaultAccentText = #FFFFFF) on macOS to the six accent-family CSS system colors:

• AccentColor / AccentColorText
• Highlight / HighlightText
• SelectedItem / SelectedItemText

Implementation lives in widget/nsXPLookAndFeel.cpp, in the function that gates which ColorIDs receive the standin (ShouldUseStandinsForNativeColorForNonNativeTheme) and the supporting sNonNativeThemeStandinColors set. Two pieces of work:

1. Add the four Highlight / HighlightText / SelectedItem / SelectedItemText ColorIDs to sNonNativeThemeStandinColors. This is platform-independent and gives the same protection on every platform that goes through this path.
2. Flip the widget.non-native-theme.use-theme-accent pref default to false on macOS (it's currently false on Windows, true elsewhere). This makes the existing accent special-case fire on macOS, standing in AccentColor / AccentColorText the same way it does on Windows.

Preserve the existing accessibility bypass: when mUseDocumentColors is false (High Contrast / forced-colors mode), the standin should be suppressed and the real OS values pass through. This is the same condition the Windows standin already honors.

What does NOT change

• Firefox's own chrome (tabs, address bar, menus, toolbar) continues to render the real macOS accent. The standin only affects the values web content can read; chrome-side LookAndFeel calls bypass it.
• Sites that explicitly set their own colors are unaffected.
• High Contrast / accessibility users continue to see real OS values, the same as on Windows today.

Compatibility note

Sites that style content using the AccentColor, Highlight, or SelectedItem CSS system-color keywords will see #0060DF (brand blue) instead of the macOS accent in those elements. This matches the existing experience for the same sites in Safari, and the existing experience on Windows. Real-world incidence is low — most sites use explicit color values rather than system-color keywords.

Comment 1

[Tom Ritter [:tjr]]

% unique (Darwin)	FPJS V2	Signifyd
Baseline (P3)	41.67%	39.07%
+ accent standin	35.21%	31.73%
Δ unique	−6.45 pp (−15.5%)	−7.35 pp (−18.8%)

This change has a significant impact on the percentage of people who are unique.