There aren’t plans to do so, as the CSS Color spec already anticipates this kind of mitigation. In the system color section <https://drafts.csswg.org/css-color/#css-system-colors> (apologies, I should’ve linked this in the I2S), it notes that UAs may return fixed values for system colors to mitigate fingerprinting risk. Blink returning a default system color when it’s unsafe to expose the user’s configured value (e.g. outside installed web apps and/or from non‑initial profiles) falls under this allowance.
On Friday, April 3, 2026 at 2:10:06 PM UTC-7 [email protected] wrote: > Thanks for making the change - Is there a plan to update the spec > accordingly? > On 4/3/26 3:04 p.m., 'Alexander Kyereboah' via blink-dev wrote: > > Hi all- > > As an update here, we have a CL > <https://chromium-review.googlesource.com/c/chromium/src/+/7705102> that > scopes availability of the system accent color across the board to the > initial profile in addition to installed web app contexts. This prevents > cross‑profile access to the underlying system value, addressing the > cross‑profile fingerprinting concern Jeff raised while still enabling the > intended installed‑app use cases. > Please let me know if this is sufficient, and if there are any additional > privacy concerns I can help address to move this scoping forward. > > On Monday, February 23, 2026 at 11:37:50 AM UTC-8 [email protected] > wrote: > >> Hey Alex, >> >> Sorry for the slow reply here. We discussed this at last week's API >> OWNERS and there is some hard-to-address privacy conern here, but there >> might be a way around if we only allow a single profile to ever access >> this. Will ping you offline to discuss. >> >> Best, >> >> Alex >> >> On Wednesday, February 18, 2026 at 4:39:34 PM UTC-8 >> [email protected] wrote: >> >>> 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/38246ca0-f698-4345-8835-f0ad928da6ccn%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38246ca0-f698-4345-8835-f0ad928da6ccn%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/0106b39f-ae10-44a7-ac2b-0cc5510200d1n%40chromium.org.
