Limit information available during canmakepayment event

[ianbjacobs]

(Below I quote previous text from the Chrome team, moving it from this pull request [1] to an issue)
[1] w3c/webpayments#261

When a Payment Request is constructed, the Payment Handler specification requires the user-agent to fire a "canmakepayment" event¹
to any matching installed Service Workers. The Service Worker is able to handle the event and return (via respondWith) either true or false.

To support native Android apps, Chrome also fires an IS_READY_TO_PAY intent to the matching installed native applications.

The "canmakepayment" event (and IS_READY_TO_PAY intent) currently conveys the following information to the Payment App:

• topOrigin - e.g., https://merchant.example (browser-determined)
• paymentRequestOrigin - e.g., https://psp-iframe.example (browser-determined)
• methodData - a sequence of arbitrary method data (merchant-supplied)

The transfer of this information is invisible to the user and without consent (reminder that it happens on Payment Request construction, long before any UI might be shown). Because Payment Apps run in a 1p context, it could be used to track the user.

Proposed Mitigation

Remove the topOrigin, paymentRequestOrigin, and methodData fields from "canmakepayment" event. The payment app may still respond based on its own knowledge (e.g., checking 1p data for this user), but that knowledge is compressed into only one bit for the merchant to consume (true/false).

Footnotes

1. Not to be confused with the canMakePayment() method of the Payment Request API. The "canmakepayment"event is fired at> construction time, not in response to acanMakePayment()call, and is used to answerhasEnrolledInstrument()` instead. ↩

[stephenmcgruer]

Thanks Ian!

Note that the "canmakepayment" information has already been removed from the Payment Handler spec (#404) and from Chrome (in https://bugs.chromium.org/p/chromium/issues/detail?id=1290492#c22).

So we could close this bug. However, the IS_READY_TO_PAY event in Chrome for native Android payment apps still includes this information because we broke multiple apps when we tried to remove it. On the Chrome side, we are still re-evaluating what stance we have where web APIs meet natively installed apps (e.g., did the user give enough permission when they installed the app, could we have Play Store policies to protect users, etc), so for now the leaking fields still exist in IS_READY_TO_PAY`. As such, I would suggest keeping this open - if we end up in the long-term situation where web-apps and native-apps get different behavior, I would want us to spec that somehow (maybe just as a note), so we can track that in this issue?

[ianbjacobs]

@stephenmcgruer, thanks for the update. +1 to keeping this issue open to track the IS_READY_TO_PAY outcome. Would a label help here (e.g., "Android")?