Sorry, I shouldn't have shared the UMA numbers but luckily those numbers were wrong so please ignore them. Regardless, from internal metric data, the impact should be very low.
On Wed, Oct 21, 2026 at 12:14 PM Darwin Yang <[email protected]> wrote: > That's a good point! We don't expect much use and looking at the latest UMA > data <http://uma/p/chrome/timeline?sid=a520566d7db7e348ab795fe27a70cdc1>, > we see about 17 events (aggregated across 7 days) at peak. We attribute > most of this (if not all) to developers working with us on improving SPC > who are asking for this feature; therefore, the impact of this change > should be minimal. > > > Cheers, > Darwin Yang > > On Wed, Oct 21, 2026 at 11:30 AM Alex Russell <[email protected]> > wrote: > >> Thanks, Darwin. >> >> Vlad pointed out that this change to increase strictness implies some new >> or additional breakage for sites. Do we have a sense for how often that >> will trigger? Do we have any UMA data that would give us a sense for the >> maximum extent of potential breakage? I.e., what's the risk? >> >> Best, >> >> Alex >> >> On Tuesday, October 20, 2026 at 7:35:08 AM UTC-7 Darwin Yang wrote: >> >>> Hi Alex, >>> >>> Both before and after the change, developers can populate an optional >>> `locale` data field with their preferred languages. Before this change, the >>> UA could use this language information however it wanted. This resulted in >>> UAs generally ignoring this field because SPC is a browser feature and to >>> align with other related browser features (e.g., WebAuthn), it would use >>> the browser language. After this change, if the field is set, the UA will >>> try to match the browser language with the developer provided list of >>> languages. If there's a match, there is no change; however, if there is no >>> match, the UA will return a locale mismatch error to the developer. The >>> intent behind this change is that the developer supplies strings for the >>> SPC dialog, and the language of those strings might not match the rest of >>> the dialog. This allows the developer to guarantee that the language of the >>> strings they provide matches the dialog's language. >>> >>> Addison Phillip's concerns were not fully addressed but we have developer >>> support >>> <https://github.com/w3c/secure-payment-confirmation/issues/343#issuecomment-5415886806> >>> for this change. In addition, we opened an issue >>> <https://github.com/w3c/i18n-request/issues/324> with the i18n >>> community, and they told us they would review our PR for the spec change by >>> the end of September >>> <https://github.com/w3c/i18n-request/issues/324#issuecomment-5526812106>. >>> It never ended up getting reviewed and after numerous attempts to ask for a >>> review (as well as inviting them to join our WPWG meeting on Oct 8th) we >>> received no response, so we decided to go ahead with the spec change so the >>> developer can begin testing the changes. >>> >>> On Mon, Oct 19, 2026 at 7:36 PM Alex Russell <[email protected]> >>> wrote: >>> >>>> The "Explainer" here is pretty thin, and I'm not sure I understand the >>>> before/after code developers would generally write. Also, it wasn't clear >>>> to me if Addison Phillip's comments were fully addressed; can you perhaps >>>> comment on those aspects? >>>> >>>> >>>> https://github.com/w3c/secure-payment-confirmation/issues/343#issuecomment-5457268443 >>>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Thursday, October 15, 2026 at 7:08:36 AM UTC-7 Chromestatus wrote: >>>> >>>>> *Contact emails* >>>>> [email protected] >>>>> >>>>> *Explainer* >>>>> https://github.com/w3c/secure-payment-confirmation/issues/343 >>>>> >>>>> *Specification* >>>>> >>>>> https://w3c.github.io/secure-payment-confirmation/#dom-securepaymentconfirmationrequest-locale >>>>> >>>>> *Design docs* >>>>> >>>>> https://github.com/w3c/secure-payment-confirmation/issues/343 >>>>> https://github.com/w3c/i18n-request/issues/324 >>>>> https://github.com/w3c/secure-payment-confirmation/pull/345 >>>>> >>>>> *Summary* >>>>> Updates Secure Payment Confirmation's `locale` data field to return a >>>>> Not Supported DOMException if none of the language tags provided in the >>>>> field match the language used by the Secure Payment Confirmation's dialog. >>>>> If the field is not set or empty, this validation is skipped. This helps >>>>> web developers with matching the language of the data that they are >>>>> supplying to Secure Payment Confirmation with the dialog. >>>>> >>>>> *Blink component* >>>>> Blink>Payments >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPayments%22> >>>>> >>>>> *Web Feature ID* >>>>> secure-payment-confirmation >>>>> <https://webstatus.dev/features/secure-payment-confirmation> >>>>> >>>>> *Motivation* >>>>> This feature amends Secure Payment Confirmation so that web developers >>>>> can align the language of data elements that they supply to Secure Payment >>>>> Confirmation with the language used by the Secure Payment Confirmation >>>>> dialog. Currently web developers can provide a list of language tags for >>>>> Secure Payment Confirmation to use in their dialog. But Secure Payment >>>>> Confirmation does not use this list because it is not feasible for the >>>>> browser to support all languages and the Secure Payment Confirmation is a >>>>> browser feature so it should use the browser language to be consistent >>>>> with >>>>> other browser features. By returning an error when none of the language >>>>> tags provided match Secure Payment Confirmation's language, web developers >>>>> are able to retry with different language tags (while updating the >>>>> language >>>>> of their supplied data elements) until they get a match. >>>>> >>>>> *Initial public proposal* >>>>> https://github.com/w3c/secure-payment-confirmation/issues/343 >>>>> >>>>> *Search tags* >>>>> spc <http:///features#tags:spc> >>>>> >>>>> *TAG review* >>>>> *No information provided* >>>>> >>>>> *TAG review status* >>>>> Not applicable >>>>> >>>>> *Goals for experimentation* >>>>> None >>>>> >>>>> *Risks* >>>>> >>>>> >>>>> *Interoperability and Compatibility* >>>>> This feature updates the behaviour of an existing field. If the >>>>> previous behaviour was implemented by other browser but this new behaviour >>>>> is not, then there is an interoperability risk of the browsers behaving >>>>> differently with the same request. >>>>> >>>>> *Gecko*: N/A ( >>>>> https://github.com/mozilla/standards-positions/issues/570) Firefox >>>>> haven't implemented SPC yet so the update to the locale field is not >>>>> relevant. >>>>> >>>>> *WebKit*: N/A (https://github.com/WebKit/standards-positions/issues/30) >>>>> Safari >>>>> haven't implemented SPC yet so the update to the locale field is not >>>>> relevant. >>>>> >>>>> *Web developers*: Positive ( >>>>> https://github.com/w3c/secure-payment-confirmation/issues/343#issuecomment-5415886806 >>>>> ) https://www.w3.org/2026/08/13-wpwg-minutes.html >>>>> https://www.w3.org/2026/09/10-wpwg-minutes.html >>>>> https://www.w3.org/2026/10/08-wpwg-minutes.html >>>>> >>>>> *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 information provided* >>>>> >>>>> >>>>> *Debuggability* >>>>> Web developers should be able to create Secure Payment Confirmation >>>>> requests with or without matching locales, thus no changes are needed in >>>>> devtools. >>>>> >>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>> No >>>>> The locale validation will only be added to platforms that support >>>>> Secure Payment Confirmation which are currently only Android, macOS, and >>>>> Windows. >>>>> >>>>> *Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> No >>>>> Web platform tests are in development. They are delayed due to the >>>>> lack of support to change the browser locale language which is needed for >>>>> this feature. >>>>> >>>>> *Flag name on about://flags* >>>>> enable-spc-locale-validation >>>>> >>>>> *Finch feature name* >>>>> SecurePaymentConfirmationLocaleValidation >>>>> >>>>> *Rollout plan* >>>>> Will ship enabled for all users >>>>> >>>>> *Requires code in //chrome?* >>>>> False >>>>> >>>>> *Tracking bug* >>>>> https://crbug.com/535278878 >>>>> >>>>> *Launch bug* >>>>> https://launch.corp.google.com/launch/4489220 >>>>> >>>>> *Measurement* >>>>> A new SecurePaymentConfirmation.LocaleOutcome will be created and used >>>>> to track the usage and outcomes (match vs no-match) of the field. >>>>> >>>>> *Availability expectation* >>>>> The locale validation for Secure Payment Confirmation will only be >>>>> available in Chromium browsers for the foreseeable future. >>>>> >>>>> *Estimated milestones* >>>>> Shipping on desktop 154 >>>>> Shipping on Android 154 >>>>> >>>>> *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). >>>>> https://github.com/w3c/i18n-request/issues/324 >>>>> https://github.com/w3c/secure-payment-confirmation/issues/343 >>>>> https://github.com/w3c/secure-payment-confirmation/pull/345 >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> https://chromestatus.com/feature/5126146013396992?gate=4803300429004800 >>>>> >>>>> *Links to previous Intent discussions* >>>>> Intent to Prototype: >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a7ccbd5.dc132f77.2e13a8.0cd1.GAE%40google.com >>>>> >>>>> >>>>> 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/CAGben6nRApG2U1DbzoaZ0E7a4ZiaSbkHexOQ1ZYpV9JE%2BqGEPg%40mail.gmail.com.
