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/CAGben6mYyJ94P_7CRVyY_hJXiZ5gJchVYqC1EwcmwjWSepfr%2BQ%40mail.gmail.com.
