Intent to Deprecate and Remove: Calling PaymentRequest.show without user activation

95 views
Skip to first unread message

Stephen Mcgruer

unread,
Dec 1, 2021, 10:43:55 AM12/1/21
to blink-dev, Rouslan Solomakhin

Contact emails

smcg...@chromium.org

Specification

https://www.w3.org/TR/payment-request/#show-method

Summary

Allowing PaymentRequest.show() to be triggered without a user activation could be abused by malicious websites. To protect users, the spec was changed to require user activation, and we are now following through in the Chrome implementation.


Plan is to deprecate in M98 and remove in M99. We may push the M99 date to M100 based on compat risk; see below.


Blink component

Blink>Payments

TAG review

N/A - enforcement of feature from an already-reviewed specification

TAG review status

Pending

Risks

Interoperability and Compatibility

Interoperability: no risk. Firefox has not shipped PaymentRequest at all, whilst Safari's implementation already requires user activation for calling show(). Compatibility: the main risk. If a website is calling PaymentRequest.show() without a user activation today, it will stop working. If that website doesn't have fallback code to use another payments flow, it may lead to a broken purchase experience for the user. Due to this risk, we added a UseCounter, kPaymentRequestShowWithoutGesture, which tracks use of the feature. Although hits on the UseCounter have reduced significantly since 2019*, there is still non-zero usage which is growing slowly over time. We believe the growth to be related to the general increase of web payments, rather than an expanded number of sites. To tackle the remaining usage, we have performed a UKM analysis, and identified the primary remaining site. We are in contact with them, and expect them to roll out a fix in the coming weeks - after which we will revisit the numbers and this thread. * https://chromestatus.com/metrics/feature/timeline/popularity/2398


Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1445138)

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=179056)

Web developers: No signals

Other signals:

Debuggability

As we are treating this as a deprecation, we intend to use the issues tab (as per the checklist) to warn developers of the upcoming removal. Once the support is removed, calling show() will throw a SecurityError with a clear error message.


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

Yes - https://wpt.fyi/results/payment-request/show-consume-activation.https.html?label=experimental&label=master&aligned

Requires code in //chrome?

False

Tracking bug

https://crbug.com/825270

Estimated milestones

Deprecate in M98, remove in M99 or M100 (compat risk depending).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5948593429020672

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/2PhPgk_k9a0/m/alO4yt_HBQAJ
Intent to Experiment: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ
  • This is a bit of a strange case, where we initially believed that we needed Capability Delegation to support deprecating this feature. However, the partner who needed that ability has instead solved their problem in a different way. As such, we believe it safe to require user activation for show() calls without Capability Delegation being available.

This intent message was generated by Chrome Platform Status and hand edited by smcgruer@.

Yoav Weiss

unread,
Dec 1, 2021, 11:05:46 AM12/1/21
to Stephen Mcgruer, blink-dev, Rouslan Solomakhin
On Wed, Dec 1, 2021 at 4:43 PM Stephen Mcgruer <smcg...@chromium.org> wrote:

Contact emails

smcg...@chromium.org

Specification

https://www.w3.org/TR/payment-request/#show-method

Summary

Allowing PaymentRequest.show() to be triggered without a user activation could be abused by malicious websites. To protect users, the spec was changed to require user activation, and we are now following through in the Chrome implementation.


Plan is to deprecate in M98 and remove in M99. We may push the M99 date to M100 based on compat risk; see below.


Blink component

Blink>Payments

TAG review

N/A - enforcement of feature from an already-reviewed specification

TAG review status

Pending

Risks

Interoperability and Compatibility

Interoperability: no risk. Firefox has not shipped PaymentRequest at all, whilst Safari's implementation already requires user activation for calling show(). Compatibility: the main risk. If a website is calling PaymentRequest.show() without a user activation today, it will stop working. If that website doesn't have fallback code to use another payments flow, it may lead to a broken purchase experience for the user. Due to this risk, we added a UseCounter, kPaymentRequestShowWithoutGesture, which tracks use of the feature. Although hits on the UseCounter have reduced significantly since 2019*, there is still non-zero usage which is growing slowly over time. We believe the growth to be related to the general increase of web payments, rather than an expanded number of sites. To tackle the remaining usage, we have performed a UKM analysis, and identified the primary remaining site. We are in contact with them, and expect them to roll out a fix in the coming weeks - after which we will revisit the numbers and this thread.


Does the primary remaining site have fallback code, or will it be broken?
 

Debuggability

As we are treating this as a deprecation, we intend to use the issues tab (as per the checklist) to warn developers of the upcoming removal. Once the support is removed, calling show() will throw a SecurityError with a clear error message.


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

Yes - https://wpt.fyi/results/payment-request/show-consume-activation.https.html?label=experimental&label=master&aligned

Requires code in //chrome?

False

Tracking bug

https://crbug.com/825270

Estimated milestones

Deprecate in M98, remove in M99 or M100 (compat risk depending).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5948593429020672

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/2PhPgk_k9a0/m/alO4yt_HBQAJ
Intent to Experiment: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/i6pAWsjU7zg/m/CzqgcGAXAwAJ
  • This is a bit of a strange case, where we initially believed that we needed Capability Delegation to support deprecating this feature. However, the partner who needed that ability has instead solved their problem in a different way. As such, we believe it safe to require user activation for show() calls without Capability Delegation being available.

This intent message was generated by Chrome Platform Status and hand edited by smcgruer@.

--
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/CADY3Mae4RVpVxnjMS8oJ7WE7yOtAiqqa79%3D8v%2ByNf2XhCtHWgg%40mail.gmail.com.

Stephen Mcgruer

unread,
Dec 1, 2021, 12:22:41 PM12/1/21
to Yoav Weiss, blink-dev, Rouslan Solomakhin
> Does the primary remaining site have fallback code, or will it be broken?

Yes and no :). It doesn't have automatic fallback for the specific payment method the user has selected (Google Pay), but the user could then select one of the other payment methods that the site supports (either a credit card flow or I think PayPal IIRC).

Stephen Mcgruer

unread,
Dec 1, 2021, 12:31:34 PM12/1/21
to Yoav Weiss, blink-dev, Rouslan Solomakhin
To be clear; I think we have a good enough shot of that remaining site fixing their code 'soon' (I expect O(weeks)) that we both:

1. Shouldn't do the removal till they have, and
2. Don't need to provide an alternative in the form of capability delegation.

But the code change to at least start this deprecation would have to land by December 9th (or we punt for 1.5 months), hence why we're filing this ahead of them fixing their site :).

Yoav Weiss

unread,
Dec 1, 2021, 12:33:39 PM12/1/21
to Stephen Mcgruer, blink-dev, Rouslan Solomakhin
LGTM1 to deprecate in M98 and remove in M99, assuming no surprises come up on the usage front.

Chris Harrelson

unread,
Dec 1, 2021, 12:34:57 PM12/1/21
to Yoav Weiss, Stephen Mcgruer, blink-dev, Rouslan Solomakhin

Mike Taylor

unread,
Dec 1, 2021, 3:25:01 PM12/1/21
to Chris Harrelson, Yoav Weiss, Stephen Mcgruer, blink-dev, Rouslan Solomakhin

Stephen McGruer

unread,
Jan 4, 2022, 10:29:01 AMJan 4
to blink-dev, Mike Taylor, Stephen McGruer, blink-dev, Rouslan Solomakhin, Chris Harrelson, Yoav Weiss, Mustaq Ahmed
Hey folks,

Following up here - we have determined that the remaining uses do necessitate making Capability Delegation available for web developers (see our Intent to Experiment - unfortunately our partner didn't engage at that time or we would have caught this earlier :(. )

We expect an Intent to Ship to be sent for Capability Delegation 'soon', targeting M100, and so are planning to push this deprecation out to M100 as well to align with that.

Thanks,
Stephen
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages