LGTM3 On Tue, Oct 27, 2026 at 11:37 PM Mike Taylor <[email protected]> wrote:
> 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 >>>>>> >>>>>> 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 > <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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/45d89f5b-27df-459d-8be1-305f27e09b2e%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/CAOMQ%2Bw9MsOHCcQrawEFr3wFuDhrUYjdBPHONpQjYcC8v-uY3zg%40mail.gmail.com.
