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/CAM0wra8UkZNdmL%3DsC4iNzmoKb%2Bt%3Deqv5V8YTUos%2B5cbFY6oqpQ%40mail.gmail.com.
