v149 · CSS · Privacy

Fingerprinting Explainer

Before Chrome 149, any page could read the user's OS accent color via getComputedStyle(el).backgroundColor on an element styled with background: AccentColor. That's a stable, per-user bit that aids fingerprinting. This page explains the attack, probes your browser, and shows how Chrome 149's web-app-scope restriction neutralises it.

Live probe — what AccentColor resolves to on this page
Click to probe…

How the fingerprinting attack worked

  1. 1
    Create a hidden element with background: AccentColor
    const el = document.createElement('div');
    el.style.cssText = 'position:fixed;top:-1px;left:-1px;width:1px;height:1px;background:AccentColor;';
    document.body.appendChild(el);
  2. 2
    Read the computed background color
    const color = getComputedStyle(el).backgroundColor;
    // → 'rgb(0, 120, 212)' ← user's actual OS accent
  3. 3
    Map to OS accent → narrow down OS / user identity
    The color narrows down the OS (Windows, macOS, Linux), and on Windows is user-configurable — giving distinguishable bits per user. Combined with other fingerprinting signals, it contributes to a persistent cross-site identity.

Fingerprinting bit value by context

Context AccentColor in Chrome <149 AccentColor in Chrome 149+ Fingerprinting risk
Regular browser tab Real OS accent color (varies per user) Fixed fallback (same for all users) 149+: Low — constant value
Installed PWA (web app scope) Real OS accent color Real OS accent color Acceptable — user installed the app intentionally
iframe (cross-origin) Real OS accent color Fixed fallback 149+: Low
Isolated origin trial or OT scope Real OS accent color Fixed fallback (unless PWA scope) 149+: Low

Timeline of the change

CSS Color 4 — AccentColor introduced
CSS system color keywords updated to include AccentColor / AccentColorText. Browsers expose the OS accent color for form control theming — useful for PWAs, risky on the open web.
Pre-Chrome 149 — real OS color exposed everywhere
Any web page, any iframe, any script could read the user's OS accent color. The value was stable per user session, OS-specific, and user-configurable on Windows — making it a useful fingerprinting signal.
Chrome 149 — scoped to web app context
AccentColor on regular pages resolves to a fixed browser-defined fallback. Only installed PWAs (running inside their declared scope) receive the real OS accent color — because the user has already made a deliberate install decision for that context.
Developer impact — minimal for most sites
Sites using accent-color: auto for form controls see the system-default value, which is visually acceptable. Sites that need real theming for PWA use cases work exactly as before when installed.

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗