Intent to Implement and Ship: Remove Payment Request User Activation Requirement

[Nick Burris]

Contact emails

nbu...@chromium.org, smcg...@chromium.org, ic...@chromium.org

Specification

https://github.com/w3c/payment-request/pull/1009

Design docs

https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4

Summary

To help developers reduce friction in Payment Request flows, we are removing the user activation requirement for PaymentRequest.show(). Spam and clickjacking mitigations are put in place to mitigate security and privacy risks with this change (see design doc).

Blink component

Blink>Payments

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: We've received direct feedback from web developers that they would be able to reduce friction in their redirect-based payment flows if PaymentRequest.show() could be initiated without a user activation.

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

Existing debuggability for PaymentRequest; e.g. a specific SecurityError is thrown when an activationless show() call is not allowed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

--enable-blink-features=PaymentRequestActivationlessShow

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1454204

Estimated milestones

DevTrial on desktop

117

DevTrial on Android

117

Anticipated spec changes

https://github.com/w3c/payment-request/pull/1009

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4879115349393408

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Tue, Jun 13, 2023 at 8:54 PM Nick Burris <nbu...@chromium.org> wrote:

Contact emails

nbu...@chromium.org, smcg...@chromium.org, ic...@chromium.org

Specification

https://github.com/w3c/payment-request/pull/1009

The PR seems to be a draft. What's preventing us from landing it?

Was this discussed in some public forum?

 

Design docs

https://docs.google.com/document/d/16DHqqPWe5oM6Rucnn6Y1llhJ-DoEeLtTWFldJFg4iqA/edit#heading=h.w5782xqp7ab4

Summary

To help developers reduce friction in Payment Request flows, we are removing the user activation requirement for PaymentRequest.show(). Spam and clickjacking mitigations are put in place to mitigate security and privacy risks with this change (see design doc).

I'm having a hard time imagining the use case for activation-less payments. Is there a concrete example you can share?

 

Blink component

Blink>Payments

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

While I agree that a signal specifically for this seems like an overkill, could you maybe comment with this on past position requests, to see if Gecko or WebKit have an opinion on this issue?

 

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADvKJHOuA%2BEMEWO7heQJeZkr%2BU%2BtndoVuXenCeC7xQ_ENXy9RQ%40mail.gmail.com.

[Stephen Mcgruer]

Hi Yoav, thanks for the questions!

> The PR seems to be a draft. What's preventing us from landing it? Was this discussed in some public forum?

We intend to land the PR before shipping this feature. It has been discussed broadly in the Web Payments WG, but I expect to raise the specific PR for discussion as well. (Though note that at the current point, I believe Chrome is the only active browser vendor in that WG. Apple have stated interest in rejoining it, but are waiting for an in-progress charter change first.)

> I'm having a hard time imagining the use case for activation-less payments. Is there a concrete example you can share?

Fair question, and I apologize - we should have motivated this more clearly externally. The core use-cases are based around redirect payment flows, which are fairly common in payments. Two coarse examples we have heard are:

1. A merchant-aggregator page showing products from many different merchants. If a user decides to buy something with a given payment method, the aggregator page redirects to the specific merchant. The merchant then wants to trigger payment, without requiring the user to click again on their chosen payment method.

2. A redirect-based payment flow, where the payment method wants to trigger a natively installed experience (via Payment Handler) without the user having to click again. (E.g., user is on merchant.example, chooses to pay with FooPay. The merchant site redirects to foopay.example. FooPay then wants to trigger its natively installed app on the phone, if available, but doesn't want to require the user to click again.

We are cognizant that this may be a risky change, and have consulted internal security folks on it in detail. From that, there are mitigations laid out in the design doc, and we are also intending to monitor for potential misuse.

> While I agree that a signal specifically for this seems like an overkill, could you maybe comment with this on past position requests, to see if Gecko or WebKit have an opinion on this issue?

Ack, we will follow up on this. Note that Gecko does not implement Payment Request currently.

Thanks,

Stephen 

[Yoav Weiss]

Thanks Stephen! :)

On Mon, Jun 19, 2023 at 3:13 PM Stephen Mcgruer <smcg...@chromium.org> wrote:

Hi Yoav, thanks for the questions!

> The PR seems to be a draft. What's preventing us from landing it? Was this discussed in some public forum?

We intend to land the PR before shipping this feature. It has been discussed broadly in the Web Payments WG, but I expect to raise the specific PR for discussion as well. (Though note that at the current point, I believe Chrome is the only active browser vendor in that WG. Apple have stated interest in rejoining it, but are waiting for an in-progress charter change first.)

> I'm having a hard time imagining the use case for activation-less payments. Is there a concrete example you can share?

Fair question, and I apologize - we should have motivated this more clearly externally. The core use-cases are based around redirect payment flows, which are fairly common in payments. Two coarse examples we have heard are:

1. A merchant-aggregator page showing products from many different merchants. If a user decides to buy something with a given payment method, the aggregator page redirects to the specific merchant. The merchant then wants to trigger payment, without requiring the user to click again on their chosen payment method.

2. A redirect-based payment flow, where the payment method wants to trigger a natively installed experience (via Payment Handler) without the user having to click again. (E.g., user is on merchant.example, chooses to pay with FooPay. The merchant site redirects to foopay.example. FooPay then wants to trigger its natively installed app on the phone, if available, but doesn't want to require the user to click again.

We are cognizant that this may be a risky change, and have consulted internal security folks on it in detail. From that, there are mitigations laid out in the design doc, and we are also intending to monitor for potential misuse.

Have y'all considered passing along the user activation from the redirector page to the redirected page? (maybe with an explicit opt-in from the redirector)

[Stephen Mcgruer]

> Have y'all considered passing along the user activation from the redirector page to the redirected page? (maybe with an explicit opt-in from the redirector)

We looked at that approach early, and discussed it with mustaq@ (cc'd) who has worked on a lot of user activation V2. Specifically, the idea was to extend Capability Delegation to navigation as well. However I believe Mustaq had a few concerns with that idea: there may not be an obvious API surface (needs a new API on window.location?), there were complexities around how to measure 'time passing' cross navigation (i.e., when to stop and when to start the user activation timer, especially also with multiple redirect hops), and finally I think he had some philosophical concerns about whether activation should be able to 'follow' a navigation. This led us to revisit the broader question of "do we think user activation is necessary for Payment Request", and we came to the conclusion that it was safe to drop.

Mustaq - please correct me if I'm wrong on any of this, or if we should revisit the discussion!

[Mustaq Ahmed]

Hi Stephen:

Your summary is correct: determining how much "remaining time" to carry over a navigation is an unanswered question for user activation here but more importantly, carrying even a few milliseconds across a navigation is prone to abuse.  For example, imagine accidentally clicking on an ad that navigates to a malicious site---nobody would want that site to be able to open popups or lock your pointer etc, right?  This is one example where the "user agents" are correctly biased more towards end-user needs over web-developer needs.  This is more than just a philosophical position because of the link to user safety.

Like any user-activation gated APIs, WebPayments experts are the right owners here.  If you find a sweet spot between user-safety vs dev-needs by not relying on HTML User Activation, please make sure malicious API usage (like activation-less payments Yoav asked about) gets due attention.  Does a TAG review apply here?

On a related note, I can see that Capability Delegation proposal doesn't fit your redirect case because it currently needs access to a target (post-navigation) Window object.  I am beginning to think now that a origin-specific "deferred" delegation could be a thing, not sure if it would even fit your use-case or how contentious it could become :( .  Thoughts?

Mustaq

[Rick Byers]

This makes good sense to me. Obviously there's so much risk and potential for abuse around payments, getting the user to click seems like a very weak mitigation anyway (eg. the prevalence of "click to read more" buttons). +1 to waiting for the PR to land, but it looks like the WG has now approved it, so proactive LGTM1 for when the PR actually lands.

It's too bad Apple isn't currently a member of the WG, so we're not likely to get their thoughts on this in time to influence our launch decision. But I also don't think it's a substantial interop risk - Payment Request is already very different on Apple browsers due to the tight coupling only with Apple Pay.

Rick

--

[Yoav Weiss]

LGTM2 conditional on the PR landing

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_7ZCW3f-uEv%3DcsRY_qtmOzJGujoXVcXfvC7BiCusUfhg%40mail.gmail.com.

[Stephen Mcgruer]

Thanks Mustaq for your input (and API OWNERS for the ongoing LGTMs, here's hoping for #3 :)). I agree with your points on the difficulty of making either user activation or capability delegation work across navigation (though I still personally think there are reasonable use-cases! :D). We're definitely paying attention to potential abuse scenarios here, though we do agree with Rick's take that getting user activation is unfortunately a fairly weak protection today already.

Wrt the PR status - yes, the WG has now endorsed it, but we will definitely be landing the PR before trying to ship this. We've re-targeted the launch from M116 to M117.

[Mike Taylor]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maev1jVfi8f4ZAt57x0nZF2OdpCQBEu9qbiNbm%2BLfvx0wA%40mail.gmail.com.