LGTM3 On Wed, Apr 8, 2026 at 11:00 AM Daniel Bratell <[email protected]> wrote:
> LGTM2 > > /Daniel > On 2026-04-04 23:22, Mike Taylor wrote: > > Thanks - that addresses my concern. LGTM1 > On 4/3/26 5:47 p.m., 'Alexander Kyereboah' via blink-dev wrote: > > There aren’t plans to do so, as the CSS Color spec already anticipates > this kind of mitigation. In the system color section > <https://drafts.csswg.org/css-color/#css-system-colors> (apologies, I > should’ve linked this in the I2S), it notes that UAs may return fixed > values for system colors to mitigate fingerprinting risk. Blink returning a > default system color when it’s unsafe to expose the user’s configured value > (e.g. outside installed web apps and/or from non‑initial profiles) falls > under this allowance. > > On Friday, April 3, 2026 at 2:10:06 PM UTC-7 [email protected] wrote: > >> Thanks for making the change - Is there a plan to update the spec >> accordingly? >> On 4/3/26 3:04 p.m., 'Alexander Kyereboah' via blink-dev wrote: >> >> 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 >>>>> [image: 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> >> . >> >> -- > 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/0106b39f-ae10-44a7-ac2b-0cc5510200d1n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0106b39f-ae10-44a7-ac2b-0cc5510200d1n%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/101b864a-9512-493a-806d-5f808ba2a3b8%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/101b864a-9512-493a-806d-5f808ba2a3b8%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/8e7cf8bc-d7b6-4893-a09e-83c4de106561%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8e7cf8bc-d7b6-4893-a09e-83c4de106561%40gmail.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/CAFUtAY_VT5-j5v8soDGfyw4%3DrUb0_J486-zoEZp4axsscGnZaQ%40mail.gmail.com.
