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