LGTM2 On 10/27/26 6:52 p.m., Alex Russell wrote:
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 <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 <https://github.com/w3c/secure-payment-confirmation/issues/343> *Specification* https://w3c.github.io/secure-payment-confirmation/#dom-securepaymentconfirmationrequest-locale <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/secure-payment-confirmation/issues/343> https://github.com/w3c/i18n-request/issues/324 <https://github.com/w3c/i18n-request/issues/324> https://github.com/w3c/secure-payment-confirmation/pull/345 <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 <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 <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 <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://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/08/13-wpwg-minutes.html> https://www.w3.org/2026/09/10-wpwg-minutes.html <https://www.w3.org/2026/09/10-wpwg-minutes.html> https://www.w3.org/2026/10/08-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 <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/i18n-request/issues/324> https://github.com/w3c/secure-payment-confirmation/issues/343 <https://github.com/w3c/secure-payment-confirmation/issues/343> https://github.com/w3c/secure-payment-confirmation/pull/345 <https://github.com/w3c/secure-payment-confirmation/pull/345> *Link to entry on the Chrome Platform Status* https://chromestatus.com/feature/5126146013396992?gate=4803300429004800 <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 <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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c60c16ff-09f9-4d46-b49f-7eec1d3497efn%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/45d89f5b-27df-459d-8be1-305f27e09b2e%40chromium.org.
