> 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).
>
> 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>
>>>> .
>>>>
>>>

-- 
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/CADY3MacFq%2Bysf51Sw3PdY2T-Sy6TFTO52BZSB0kMMM%3DUEb1A0Q%40mail.gmail.com.

Reply via email to