Intent to Ship: Web app scope system accent color

[Alexander Kyereboah]

Contact emails

akyer...@microsoft.com

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

Web Feature ID

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, accent, color, system accent color

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?

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.

[Daniel Herr]

They should also be exposed to extensions.

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01a0f425-0740-4b13-b0f9-a552b2b247a5n%40chromium.org.

[Vladimir Levin]

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJSLZa2pLoNN8tkr9s_OGhHvTZmNL6_njFH-sQZa0hkyuibY-Q%40mail.gmail.com.

[Alexander Kyereboah]

@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

[Daniel Herr]

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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d49729a5-c9f8-464f-b59e-ff2a6c31ac85n%40chromium.org.

[Jeffrey Yasskin]

+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

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJSLZa0eTq1FumF37d8ZW_Rtpt4Vqzybk0cbhcfn6_7yxYftSg%40mail.gmail.com.

[Alexander Kyereboah]

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.

[Alex Russell]

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