Thanks Stephen, that makes sense.

LGTM2

On Tuesday, July 15, 2025 at 3:20:00 PM UTC-4 Slobodan Pejic wrote:

> 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/38a9f6a8-fa87-43d2-a93f-bef198cc9795n%40chromium.org.

Reply via email to