No worries; thanks for the data. LGTM1
On Wednesday, October 21, 2026 at 9:37:28 AM UTC-7 Darwin Yang wrote: > 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/c60c16ff-09f9-4d46-b49f-7eec1d3497efn%40chromium.org.
