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/1bdbd938-d28c-4e8f-84f7-03da62bac755n%40chromium.org.
