Thanks Domenic, I have filed an issue to address this problem with the secure-payment-confirmation specification (#307 <https://github.com/w3c/secure-payment-confirmation/issues/307>).
On Monday, July 14, 2025 at 10:09:19 PM UTC-4 Domenic Denicola wrote: > This generally looks good, but there's a bit of a hole in the spec which > makes it unclear whether CSP, etc. apply to these image fetches: see > https://github.com/w3c/image-resource/issues/48 . (The SPC spec calls > "Fetch an image resource" with no request supplied, but the Image Resource > spec is broken in that case.) > > On Tue, Jul 15, 2025 at 3:13 AM Alex Russell <slightly...@chromium.org> > wrote: > >> LGTM1; my view is that each browser team is managing risk about >> browser-presented UI and that nothing about this forces anyone to display >> anything. >> >> Best, >> >> Alex >> >> On Thursday, July 10, 2025 at 11:24:51 AM UTC-7 Nina Satragno wrote: >> >>> El mié, 9 jul 2025 a la(s) 12:11 p.m., Stephen Mcgruer ( >>> smcgr...@chromium.org) escribió: >>> >>>> > Hey, with regards to providing logos. My understanding is that this >>>> would be displayed in a trusted content. Is there some affordances to >>>> clearly indicate that these logos are provided by the merchants? I'm a >>>> little concerned for cases like displaying arbitrary content in trusted UI >>>> because of things like hate symbols, among other things. >>>> >>>> Hi Vlad; you're completely right to be concerned in this regard - it is >>>> a general concern with SPC. Whilst we do care about this issue, our >>>> counter-argument is that there is no incentive to display misleading or >>>> offensive logos using SPC. >>>> >>>> Firstly, if we examine the 'offensive' case - what is the value of SPC >>>> here for someone who wants to offend? If I'm the website, I can render >>>> offensive iconography in an HTML 'bottomsheet' UX, with a Chrome logo at >>>> the top of it, and write whatever I want. Users will generally not know >>>> the >>>> difference, and many will just attribute that to being from Chrome anyway. >>>> We're actually not looking to present SPC as being "from Chrome" - there's >>>> no logo, for example. We've historically discussed this with security, and >>>> we have offered to remove the 'line of death/full screen scrim' to further >>>> divorce SPC from being 'browser UX' - but so far they haven't asked us to >>>> do that. >>>> >>>> Secondly, if we examine the 'misleading' case, we cover that in the >>>> spec (here >>>> <https://w3c.github.io/secure-payment-confirmation/#sctn-security-payment-attack> >>>> >>>> and here >>>> <https://w3c.github.io/secure-payment-confirmation/#sctn-security-merchant-data>), >>>> >>>> but broadly the answer is that even if you trick the user into creating an >>>> SPC cryptogram, it has no value unless you are literally processing a >>>> transaction with the underlying payment providers (and they are able to >>>> examine the output signed cryptogram to know exactly what data you >>>> provided >>>> to the user). So as a misleading attacker, you at best end up with an SPC >>>> cryptogram with no use for it. >>>> >>>> On Wed, 9 Jul 2025 at 12:01, Stephen Mcgruer <smcgr...@chromium.org> >>>> wrote: >>>> >>>>> > Sorry, I didn't read the WPT PRs you linked. I see that the tests >>>>> already depend on test_driver.add_virtual_authenticator(). Is there >>>>> anything blocking testing here, or is it OK if shipping this is >>>>> conditional >>>>> on the tests being landed? >>>>> >>>>> The main issue is that WebAuthn virtual authenticators are not >>>>> supported on Chrome Android (as far as I know, cc @Nina Satragno >>>>> <nsatra...@google.com> ), whilst this feature is shipping first for >>>>> SPC in Chrome Android (with Desktop to follow in a few milestones). So >>>>> they're not going to pass when initially landed (and indeed will regress >>>>> SPC's wpt.fyi status in Chrome), *however* we discussed this >>>>> internally yesterday and decided its still better to have tests that >>>>> reflect the specification even if they now fail due to lack of test >>>>> support. So our plan is to land them in the coming days (once reviewed). >>>>> >>>> >>> This is correct, there's no virtual authenticator support for Android. >>> From a WPT perspective this also seems like a reasonable approach to me. >>> >>> >>>> >>>>> On Wed, 9 Jul 2025 at 11:21, Philip Jägenstedt <foo...@chromium.org> >>>>> wrote: >>>>> >>>>>> Sorry, I didn't read the WPT PRs you linked. I see that the tests >>>>>> already depend on test_driver.add_virtual_authenticator(). Is there >>>>>> anything blocking testing here, or is it OK if shipping this is >>>>>> conditional >>>>>> on the tests being landed? >>>>>> >>>>>> On Wed, Jul 9, 2025 at 5:17 PM Philip Jägenstedt <foo...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Hey Stephen, >>>>>>> >>>>>>> Is WebAuthn virtual authenticators the DevTools feature mentioned in >>>>>>> https://developer.chrome.com/docs/devtools/webauthn? >>>>>>> >>>>>>> If you need powerful test automation for WebAuthn, have you had a >>>>>>> look at what's currently possible with WebDriver BiDi and >>>>>>> testdriver.js? >>>>>>> Recently >>>>>>> <https://github.com/web-platform-tests/wpt/commits/0fc79d8e619d1ab680b2688e8ec6b9dd51b19b26/resources/testdriver.js> >>>>>>> a >>>>>>> lot of previously "too hard" features have been added to testdriver.js, >>>>>>> and >>>>>>> there might be a pattern you can follow there. >>>>>>> >>>>>>> Best regards, >>>>>>> Philip >>>>>>> >>>>>>> On Thu, Jul 3, 2025 at 7:29 PM Stephen Mcgruer < >>>>>>> smcgr...@chromium.org> wrote: >>>>>>> >>>>>>>> (Also, -chrome-payments-eng@ as that is an internal group that will >>>>>>>> not accept email from @chromium.org or other external accounts :)) >>>>>>>> >>>>>>>> On Thu, 3 Jul 2025 at 13:26, Stephen Mcgruer <smcgr...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Quick clarification here: >>>>>>>>> >>>>>>>>> > Is this feature fully tested by web-platform-tests? >>>>>>>>> > No >>>>>>>>> >>>>>>>>> We are working on adding tests, but since the SPC WPTs rely on >>>>>>>>> WebAuthn virtual authenticators, and those are not available on >>>>>>>>> Chrome >>>>>>>>> Android, we are having to test them manually as we develop. When >>>>>>>>> these >>>>>>>>> features are implemented for Desktop then things should start working >>>>>>>>> better! >>>>>>>>> >>>>>>>>> - https://github.com/web-platform-tests/wpt/pull/53358 >>>>>>>>> (paymentEntityLogos) >>>>>>>>> - https://github.com/web-platform-tests/wpt/pull/53333 >>>>>>>>> (instrument.details) >>>>>>>>> - https://github.com/web-platform-tests/wpt/pull/53386 (new >>>>>>>>> output states) >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, 3 Jul 2025 at 12:14, Chromestatus < >>>>>>>>> ad...@cr-status.appspotmail.com> wrote: >>>>>>>>> >>>>>>>>>> Contact emails darwiny...@chromium.org, slobo...@chromium.org, >>>>>>>>>> smcgr...@chromium.org >>>>>>>>>> >>>>>>>>>> Explainer >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/197 >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/275 >>>>>>>>>> >>>>>>>>>> Specification https://w3c.github.io/secure-payment-confirmation >>>>>>>>>> >>>>>>>>>> Design docs >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/197 >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/issues/275 >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/292 >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/294 >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/298 >>>>>>>>>> >>>>>>>>>> Summary >>>>>>>>>> >>>>>>>>>> Updates the UX elements for the SPC dialog on Android Chrome. >>>>>>>>>> Other than just UX presentation the following are being added: - >>>>>>>>>> Allowing >>>>>>>>>> merchants to provide an optional list of payment entity logos >>>>>>>>>> related to >>>>>>>>>> the payment that will be displayed in the UX ( >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/294). - >>>>>>>>>> Returning different output states back to the merchant depending on >>>>>>>>>> whether >>>>>>>>>> the user wants to continue the transaction without SPC or to cancel >>>>>>>>>> the >>>>>>>>>> transaction ( >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/292). >>>>>>>>>> Currently, we only send a single output state back for both cases. - >>>>>>>>>> A new >>>>>>>>>> payment detail label field will be added to the payment instrument >>>>>>>>>> so the >>>>>>>>>> text be presented across 2 lines in SPC ( >>>>>>>>>> https://github.com/w3c/secure-payment-confirmation/pull/298) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Blink component Blink>Payments >>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPayments%22> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> TAG review N/A (minor additive features) >>>>>>>>>> >>>>>>>>>> TAG review status Not applicable >>>>>>>>>> >>>>>>>>>> Risks >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Interoperability and Compatibility >>>>>>>>>> >>>>>>>>>> Low risk. The SPC UX Refresh changes are only purely additive API >>>>>>>>>> shapes that are all backwards compatible. The risk is that other >>>>>>>>>> browser do >>>>>>>>>> not implement it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Gecko*: No signal ( >>>>>>>>>> https://github.com/mozilla/standards-positions/issues/570) >>>>>>>>>> Firefox has never finalized their view on SPC, so we updated the >>>>>>>>>> original >>>>>>>>>> SPC issue with a note on this additional capability. >>>>>>>>>> >>>>>>>>>> *WebKit*: No signal ( >>>>>>>>>> https://github.com/WebKit/standards-positions/issues/30) Safari >>>>>>>>>> has never finalized their view on SPC, so we updated the original >>>>>>>>>> SPC issue >>>>>>>>>> with a note on this additional capability. >>>>>>>>>> >>>>>>>>>> *Web developers*: Positive Responding to requests/feedback from >>>>>>>>>> web developers in the WPWG. >>>>>>>>>> >>>>>>>>>> *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? >>>>>>>>>> >>>>>>>>>> None >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Debuggability >>>>>>>>>> >>>>>>>>>> Web developers should be able to try the new SPC UX Refresh >>>>>>>>>> through a Chrome flag, 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 >>>>>>>>>> >>>>>>>>>> SPC UX Refresh is added to Secure Payment Confirmation which is >>>>>>>>>> supported only on Android, Windows, and Mac. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>> ? No >>>>>>>>>> >>>>>>>>>> DevTrial instructions >>>>>>>>>> https://docs.google.com/document/d/1w3RfvmoQqCvJkio4rxl0QR4BL1AzgHdv9a0qJhfCzpg >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Flag name on about://flags >>>>>>>>>> enable-secure-payment-confirmation-ux-refresh >>>>>>>>>> >>>>>>>>>> Finch feature name SecurePaymentConfirmationUxRefresh >>>>>>>>>> >>>>>>>>>> Rollout plan Will ship enabled for all users >>>>>>>>>> >>>>>>>>>> Requires code in //chrome? False >>>>>>>>>> >>>>>>>>>> Tracking bug https://g-issues.chromium.org/issues/405173922 >>>>>>>>>> >>>>>>>>>> Launch bug https://launch.corp.google.com/launch/4397413 >>>>>>>>>> >>>>>>>>>> Measurement SPC UX Refresh is only additive to Secure Payment >>>>>>>>>> Confirmation: The Secure Payment Confirmation UseCounter will be >>>>>>>>>> used. >>>>>>>>>> >>>>>>>>>> Availability expectation Secure Payment Confirmation is only in >>>>>>>>>> Chromium browsers for the foreseeable future. >>>>>>>>>> >>>>>>>>>> Non-OSS dependencies >>>>>>>>>> >>>>>>>>>> Does the feature depend on any code or APIs outside the Chromium >>>>>>>>>> open source repository and its open-source dependencies to function? >>>>>>>>>> None >>>>>>>>>> >>>>>>>>>> Sample links >>>>>>>>>> https://rsolomakhin.github.io/pr/spc-payment-entities-logos >>>>>>>>>> https://rsolomakhin.github.io/pr/spc-opt-out >>>>>>>>>> >>>>>>>>>> Estimated milestones >>>>>>>>>> Shipping on Android 139 >>>>>>>>>> DevTrial on Android 139 >>>>>>>>>> >>>>>>>>>> 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). >>>>>>>>>> None >>>>>>>>>> >>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>> https://chromestatus.com/feature/5206050462236672?gate=5106969593249792 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Links to previous Intent discussions Intent to Prototype: >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/683f5e54.170a0220.31427f.1558.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 blink-dev+unsubscr...@chromium.org. >>>>>>>> To view this discussion visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafTfsu-e69p_8ixAyLvfj0VnVuxs%3DT95w55UbeDSKKr5g%40mail.gmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafTfsu-e69p_8ixAyLvfj0VnVuxs%3DT95w55UbeDSKKr5g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> >>> >>> -- >>> Nina Satragno >>> >> -- >> 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 blink-dev+unsubscr...@chromium.org. >> > To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bbcefa96-47c5-4ad2-8f38-d735fd94e63an%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bbcefa96-47c5-4ad2-8f38-d735fd94e63an%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e23d497d-38f4-4fa2-98c8-617db36bf918n%40chromium.org.
