I'm currently double-checking with Privacy to see if extensions being included in the scope of availability is viable from a privacy standpoint, will report back.
In regard to the quantizing the color combined with the installed app restriction, that's an interesting proposal! I remember when we initially brought forward the installed app restriction to be a possible web standard resolution, there was push back from different UAs and developers that didn't want to scope it and believed it should just be available. In addition, Firefox already exposes the system accent color. I feel any solution that pushes installed web app scoping as a web standard might see some struggle, but it could be worth bringing up in the GitHub Issue for further discussion. I do like the reduced granularity of theme colors. However, I feel that would remove the benefit of having native-like app styling for installed web apps if we no longer pick up the system color, at which point one of the main motivations of the feature becomes moot. On Tuesday, February 17, 2026 at 4:11:04 PM UTC-8 [email protected] wrote: > +1 to extensions having access if anyone does. > > I'm concerned about installed PWAs getting full access to this > fingerprinting bit. There are a _lot_ of colors, and on systems that infer > an accent color from a user-chosen background image, each person could have > a nearly-unique color. While installed apps deserve somewhat-elevated trust > (at least around access to OS-related features), we should still be trying > to prevent an app installed by one profile from learning that the same > person also has the same app installed in a different profile with a > different login. > > If I'm skimming https://github.com/w3c/csswg-drafts/issues/10372 > correctly, the conclusion is that tainting the accent color (using an > author-supplied color when the author tries to compute over the accent > color) isn't viable. Lea suggested quantizing the color to make it more > granular, and people seemed to reject that on the theory that it doesn't > completely solve the fingerprinting problem. However, it might solve it > enough to work in combination with the installed-app restriction. > > Browser profiles can also have attached theme colors, which could be used > instead of the system-wide accent color. For Chrome, this is most visible > on desktop (see the attached profile creation screen), but it could be > useful on phones too. At the limit, we could encourage users to assign a > different color to each website in each profile, which would completely > remove this fingerprinting risk. > > My concerns don't win over an approval from the privacy team, but it would > still be nice to double-check whether we can mitigate this to some extent. > > Jeffrey > [image: Chrome color picker.png] > > > > > On Tue, Feb 17, 2026 at 2:58 PM Daniel Herr <[email protected]> > wrote: > >> I'm saying that the color keywords and whatever related thing should all >> be exposed to extensions. And as a general rule, if a PWA can do something, >> a WebExtension should also be able to do it. The argument for only exposing >> to PWAs is fingerprinting, but extensions already have access to much >> stronger fingerprinting vectors, and with permissions the ability to >> identify the user without fingerprinting. So preventing extensions from >> being able to easily adapt style with system accent colors doesn't >> make sense. >> >> On Tue, Feb 17, 2026, 4:40 PM 'Alexander Kyereboah' via blink-dev < >> [email protected]> wrote: >> >>> *@danielher...* >>> *AccentColor* and *AccentColorText* are available only for installed >>> web apps, not extensions. Having *accent-color: auto* available in >>> extensions feels like a departure from the consistency we're trying to >>> achieve with this change. Could you give me a little bit of insight into >>> your reasoning for extensions being included? >>> >>> >>> *@vmp/vlad*Yes, this would effectively remove system colors for >>> non-installed web apps. >>> >>> The core fingerprinting concern is that exposing system accent color on >>> the open web gives every site access to a stable, user‑specific signal that >>> can be collected passively and reused across origins, which increases >>> fingerprinting surface. >>> Installed web apps are different because installation is an explicit, >>> user‑mediated action and creates a more trusted, origin-scoped context. >>> That significantly narrows the threat model, since access is no longer >>> available to arbitrary pages and the signal is only exposed where users >>> expect deeper OS integration (an installed app). So while installation >>> doesn’t eliminate fingerprinting risk entirely, it meaningfully reduces >>> scale and abuse potential. >>> However, we don't actually expose the `accent-color: auto` as values >>> that can be meaningfully queried, so the fingerprinting concerns don't >>> apply in the same way to form controls. This scoping is primarily about the >>> consistency of system colors across the web, since the *AccentColor* >>> and *AccentColorText* CSS keywords are subject to the fingerprinting >>> mitigations described above. The installed web app mitigation for the CSS >>> keywords was approved by Chromium Privacy review. >>> There's definitely usage of the default value on the web, but we don't >>> expect any significant regression, as other platforms don't expose system >>> accent color for form controls in the same capacity as Chromium, so it's >>> unlikely developers were relying on the default value in the first place. >>> (We actually got more accessibility bug reports and complaints when we >>> first enabled system color styling by default.) >>> >>> With regard to the currently open discussion, we don't foresee any >>> resolution soon. The discussion has found differing needs and security >>> requirements across UAs, with proposed alternatives generally being too >>> complex to justify broad implementation. Given that, we’ve found this >>> approach to be the most effective while staying within existing spec >>> requirements. Of course, if we eventually find a way in the GitHub issue to >>> completely un-scope system colors everywhere, it wouldn't be difficult to >>> implement at that time. >>> >>> Best, >>> Alex >>> On Tuesday, February 17, 2026 at 8:01:14 AM UTC-8 [email protected] >>> wrote: >>> >>>> Hey, am I correct in understanding that this essentially removes system >>>> colors as auto accent-colors on non-installed web applications? I have a >>>> naive question: can you comment on the significance of being installed vs >>>> not being installed as a mitigation for fingerprinting? My guess is that >>>> an >>>> installed web app already has elevated access to things like this. Is that >>>> correct? >>>> >>>> This is the default value so I assume that there is quite a bit of >>>> usage of this right now intentionally or otherwise, so this is likely to >>>> have a significant effect for users. At the same time it seems like a >>>> reasonable mitigation. https://github.com/w3c/csswg-drafts/issues/10372 >>>> seems to be under active discussion. Do you foresee any resolutions coming >>>> soon? >>>> >>>> Thanks, >>>> Vlad >>>> >>>> On Sat, Feb 14, 2026 at 1:24 AM Daniel Herr <[email protected]> >>>> wrote: >>>> >>>>> They should also be exposed to extensions. >>>>> >>>>> On Fri, Feb 13, 2026, 5:12 PM 'Alexander Kyereboah' via blink-dev < >>>>> [email protected]> wrote: >>>>> >>>>>> *Contact emails* >>>>>> [email protected] >>>>>> >>>>>> *Explainer* >>>>>> *N/A* >>>>>> >>>>>> *Specification* >>>>>> https://drafts.csswg.org/css-ui-4/#widget-accent >>>>>> >>>>>> *Summary* >>>>>> Currently, if the *accent-color* property for form controls is set >>>>>> to *auto*, they adopt the system accent color set by the user in >>>>>> their operating system. This happens in all contexts whether on the web >>>>>> or >>>>>> in an installed web application. Current feature state: >>>>>> https://chromestatus.com/feature/6548224737017856 >>>>>> *AccentColor* and *AccentColorText* CSS keywords, which also adopt >>>>>> the system accent color, pose a significant fingerprinting vector if >>>>>> exposed widely on the web. As such, they're currently planned to only be >>>>>> available in installed web app contexts. We want system accent color >>>>>> exposure to match across all vectors, so we should scope *accent-color: >>>>>> auto* to only be available in installed web app contexts as well. >>>>>> This introduces more consistent developer and user expectations for >>>>>> system >>>>>> colors and aligns with fingerprinting restrictions for >>>>>> *AccentColor[Text]*. >>>>>> >>>>>> *Blink component* >>>>>> Blink>CSS >>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> >>>>>> >>>>>> *Web Feature ID* >>>>>> accent-color <https://webstatus.dev/features/accent-color> >>>>>> >>>>>> *Motivation* >>>>>> Currently, system accent color features have differing scopes of >>>>>> availability. While *AccentColor[Text]* is planned to only be >>>>>> available in installed web apps, *accent-color: auto* uses system >>>>>> accent color everywhere. This leads to confusing signaling on when >>>>>> developers can expect system accent colors to be available, as well as >>>>>> unintended accessibility and UX side effects as form controls adopt >>>>>> colors >>>>>> on web sites that developers didn't expect. Scoping system accent color >>>>>> availability to installed web apps all up will provide more consistency >>>>>> in >>>>>> this feature intended to allow more native app like styling, while >>>>>> adhering >>>>>> to the fingerprinting restrictions that *AccentColor[Text]* is >>>>>> planned to be subject to (must not be exposed outside of installed web >>>>>> apps). >>>>>> >>>>>> *Initial public proposal* >>>>>> *No information provided* >>>>>> >>>>>> *Search tags* >>>>>> accent-color <https://chromestatus.com/features#tags:accent-color>, >>>>>> accent <https://chromestatus.com/features#tags:accent>, color >>>>>> <https://chromestatus.com/features#tags:color>, system accent color >>>>>> <https://chromestatus.com/features#tags:system%20accent%20color> >>>>>> >>>>>> *TAG review* >>>>>> This is a modification/fix for an existing approved feature. >>>>>> >>>>>> *TAG review status* >>>>>> Not applicable >>>>>> >>>>>> *Risks* >>>>>> >>>>>> >>>>>> *Interoperability and Compatibility* >>>>>> There is potential interoperability risk as WebKit exposes the system >>>>>> accent color completely un-scoped, while Firefox does not. Conversation >>>>>> around fingerprinting mitigation for *AccentColor*, which mentions >>>>>> how it should not have differing availability from accent-color: auto: >>>>>> https://github.com/w3c/csswg-drafts/issues/10372 >>>>>> >>>>>> *Gecko*: Positive ( >>>>>> https://github.com/mozilla/standards-positions/issues/1354) Emilio >>>>>> noted in the attached link that he sees no issues with this. >>>>>> >>>>>> *WebKit*: No signal ( >>>>>> https://github.com/WebKit/standards-positions/issues/613) In >>>>>> discussion. >>>>>> >>>>>> *Web developers*: No signals >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> *WebView application risks* >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> No, but implementing Finch feature flag just in case. >>>>>> >>>>>> >>>>>> *Debuggability* >>>>>> No additional functionality needed to debug this feature. >>>>>> >>>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>> No >>>>>> This is scoping an existing feature, which is currently being >>>>>> supported on Windows, Mac, Linux, and ChromeOS. Future support for >>>>>> Android >>>>>> is planned. >>>>>> >>>>>> *Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>> No >>>>>> There are no specific tests for this scoping fix. The underlying >>>>>> feature relies on the platform's accent color and necessitates a >>>>>> WebDriver >>>>>> extension to simulate the accent-color property accurately, making it >>>>>> difficult to test. However current WPT coverage for the underlying >>>>>> feature >>>>>> was not broken by this change. >>>>>> WPT tests listed for underlying feature: >>>>>> - https://wpt.fyi/results/css/css-ui/accent-color-parsing.html >>>>>> - >>>>>> https://wpt.fyi/results/css/css-typed-om/the-stylepropertymap/properties/accent-color.html >>>>>> >>>>>> - >>>>>> https://wpt.fyi/results/css/css-ui/animation/accent-color-interpolation.html >>>>>> >>>>>> *Flag name on about://flags* >>>>>> *N/A* >>>>>> >>>>>> *Finch feature name* >>>>>> >>>>>> *WebAppScopeSystemAccentColor* >>>>>> *Rollout plan* >>>>>> Will ship enabled for all users >>>>>> >>>>>> *Requires code in //chrome?* >>>>>> False >>>>>> >>>>>> *Tracking bug* >>>>>> https://issues.chromium.org/issues/481353056 >>>>>> >>>>>> *Estimated milestones* >>>>>> >>>>>> Shipping on desktop >>>>>> 147 >>>>>> >>>>>> *Anticipated spec changes* >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution >>>>>> may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> The fingerprinting mitigation for AccentColor and AccentColorText do >>>>>> not have widely agreed upon resolution: >>>>>> https://github.com/w3c/csswg-drafts/issues/10372 Depending on the >>>>>> results of that conversation, it's possible we might be able to un-scope >>>>>> this feature in the future. >>>>>> >>>>>> *Link to entry on the Chrome Platform Status* >>>>>> >>>>>> https://chromestatus.com/feature/5106043975761920?gate=4678080817922048 >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01a0f425-0740-4b13-b0f9-a552b2b247a5n%40chromium.org >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01a0f425-0740-4b13-b0f9-a552b2b247a5n%40chromium.org?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJSLZa2pLoNN8tkr9s_OGhHvTZmNL6_njFH-sQZa0hkyuibY-Q%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJSLZa2pLoNN8tkr9s_OGhHvTZmNL6_njFH-sQZa0hkyuibY-Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d49729a5-c9f8-464f-b59e-ff2a6c31ac85n%40chromium.org >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d49729a5-c9f8-464f-b59e-ff2a6c31ac85n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJSLZa0eTq1FumF37d8ZW_Rtpt4Vqzybk0cbhcfn6_7yxYftSg%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJSLZa0eTq1FumF37d8ZW_Rtpt4Vqzybk0cbhcfn6_7yxYftSg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1b3ad984-4ceb-4d6c-aadd-4273948f7631n%40chromium.org.
