Re: [w3c/payment-handler] Security consideration: user consent before payment (#365)

@danyao commented on this pull request.



> @@ -2438,10 +2438,19 @@ <h2>
         </h2>
         <ul>
           <li>One goal of this specification is to minimize the user
-          interaction required to make a payment. At the same time, user agents
-          must not permit combinations of configurations that would enable
-          invoking Web sites to invoke payment request and receive payments
-          silently.
+          interaction required to make a payment. However, we also want to
+          ensure that the user has an opportunity to consent to making a
+          payment. Because payment handlers are not required to open windows
+          for user interaction, user agents should take necessary steps to
+          provide for some form of user action before <a data-cite=
+          "payment-request#show-method">PaymentRequest.show()</a> resolves. For
+          example, a user agent might do nothing if a payment handler opens a
+          window and the user has an opportunity to confirm a transaction via a
+          button. But if the payment handler does not open a window, or opens a
+          window without an opportunity for user interaction, the browser might
+          prompt the user to confirm the payment handler's behavior before

Hi @romandev - The `PaymentRequestEvent.isTrusted` check in `respondWith()` ensures that `request.show()` is triggered with a user gesture. I think to protect the user from the [one-click collection of detailed user information without UI][1] privacy attack, I think browsers should also require that the user has interacted with the payment handler UI before allowing the `showPromise` to resolve. Do you think this makes sense?

`finalizeResponse()` is just a strawman. 😅 I need to study `respondWith()` a bit more to see if we truly needs a second method. My initial intuition is based on code examples that show a payment handler calling `respondWith()` immediate in the `paymentrequest` event handler to return a Promise. If we want to use `respondWith()` to capture the requirement that the user has interacted with the payment handler's web content, then it probably needs to be called outside of the event handler and as part of a click event handler on the payment handler's web content. I'm not too sure yet how this click event handler can transfer to the service worker...

All that said, I don't think we need to figure this all out before updating the non-normative note here. WDYT @ianbjacobs @marcoscaceres @romandev ? We can tackle the actual design in a separate issue.

[1] https://w3c.github.io/webpayments/proposals/privacy-threat-model.html#one-click-no-ui


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/pull/365#discussion_r412482518