Reduce risk of timing attack on canmakepayment #415
Description
(Below I quote previous text from the Chrome team, moving it from this pull request [1] to an issue)
[1] w3c/webpayments#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, 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.)