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