*@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.
