[w3c/payment-handler] Reduce risk of timing attack on canmakepayment (Issue #415)

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

In a timing attack, a colluding website (https://site.example) first fires a server-call to the tracker (https://tracker.example), informing the tracker that it is about to construct a Payment Request. The colluding website then does so, and a `"canmakepayment"` event is fired to the tracker's (already-installed) payment app. Whilst this event contains no user data after the [above mitigations](#canmakepayment-and-is_ready_to_pay), the service worker (or native application) still has 1p context and so can message its own server with its concept of the user's identity. The https://tracker.example server then
attempts to match up the initial server-call with the canmakepayment event, and thus track the user.

#### Possible Mitigations

One option would be to partition the Service Worker's storage, which would remove its ability to access the 1p user information when handling the `"canmakepayment"` event. However once a service worker opens a Payment Handler window (which is a 1p context) in the `"paymentrequest"` event, it can receive the payment app’s 1p identity for the user through `postMessage()` and store it for later usage, thus negating the partitioning. In addition, a user agent has no way to partition the storage of an OS-native (e.g., Android) app.

As an alternative, we have been considering a push model, in which installed payment apps can proactively 'push' their response boolean (`true`/`false`) down to the browser for future `"canmakepayment"` events. Then, when a Payment Request is constructed, the browser just uses the cached value rather than call into the Service Worker.

A final option would be to remove `"canmakepayment"`/`IS_READY_TO_PAY` entirely, although we have not yet determined whether that is feasible. (It certainly seems like it would break use-cases.)


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

Message ID: <w3c/payment-handler/issues/415@github.com>