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