From 3a6c1e840dc763358862e8de93ec01e405d77ebb Mon Sep 17 00:00:00 2001 From: Stephen McGruer Date: Wed, 14 Dec 2022 13:52:50 -0500 Subject: [PATCH] [Spec] Remove user-identifiable information from canMakePayment (#404) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * [Spec] Remove user-identifiable information from canMakePayment The “canmakepayment” service worker event lets the merchant know whether the user has a card on file in an installed payment app. It silently passes the merchant's origin and arbitrary data to a service worker from payment app origin. This cross-origin communication happens on PaymentRequest construction in JavaScript, does not require a user gesture, and does not show any user interface. As such, it is a potential source of silent user tracking in a post-3p cookies world. * Fix existing bug pointing to wrong modifiers --- index.html | 89 ++++++++++++------------------------------------------ 1 file changed, 20 insertions(+), 69 deletions(-) diff --git a/index.html b/index.html index a95a55a..f4a886b 100644 --- a/index.html +++ b/index.html @@ -816,18 +816,10 @@ 

           [Exposed=ServiceWorker]
           interface CanMakePaymentEvent : ExtendableEvent {
-            constructor(DOMString type, optional CanMakePaymentEventInit eventInitDict = {});
-            readonly attribute USVString topOrigin;
-            readonly attribute USVString paymentRequestOrigin;
-            readonly attribute FrozenArray<PaymentMethodData> methodData;
+            constructor(DOMString type);
             undefined respondWith(Promise<boolean> canMakePaymentResponse);
           };
-

- The topOrigin, paymentRequestOrigin, - methodData, and modifiers members share their - definitions with those defined for {{PaymentRequestEvent}}. -

respondWith() method @@ -837,23 +829,6 @@

can respond to a payment request.

-
-

- CanMakePaymentEventInit dictionary -

- 
-            dictionary CanMakePaymentEventInit : ExtendableEventInit {
-              USVString topOrigin;
-              USVString paymentRequestOrigin;
-              sequence<PaymentMethodData> methodData;
-            };
-
-

- The topOrigin, paymentRequestOrigin, and - methodData members share their definitions with those - defined for {{PaymentRequestEvent}}. -

-

@@ -875,40 +850,8 @@

  • Fire Functional Event "canmakepayment" using - CanMakePaymentEvent on registration with the - following properties: + CanMakePaymentEvent on registration.

    -
    -
    - topOrigin -
    -
    - the [=serialization of an origin=] of the top level payee web - page. -
    -
    - paymentRequestOrigin -
    -
    - the [=serialization of an origin=] of the context where - PaymentRequest was initialized. -
    -
    - methodData -
    -
    - The result of executing the MethodData Population - Algorithm. -
    -
    - modifiers -
    -
    - The result of executing the Modifiers Population - Algorithm. -
    -

    • @@ -1454,7 +1397,7 @@

    Algorithm.
    - modifiers + modifiers
    The result of executing the Modifiers Population @@ -1944,16 +1887,24 @@

  • In a browser that supports Payment Handler API, when a merchant creates a PaymentRequest object with URL-based payment method - identifiers, CanMakePaymentEvent will fire in registered - payment handlers from a finite number of origins: the origins of the + identifiers, a CanMakePaymentEvent will fire in registered + payment handlers from a finite set of origins: the origins of the payment method manifests and their supported origins. This - means that a registered payment handler will know that a user has - visited a website before the user has selected that payment handler - to complete a transaction. This behavior is similar to the status quo - where a merchant embeds a third-party iframe in a checkout page. - However, because user agents enable users to disable the - CanMakePaymentEvent and users can choose to uninstall payment - handlers, this approach improves upon the iframe status quo. + event is fired before the user has selected that payment handler, + but it contains no information about the triggering origin (i.e., + the merchant website) and so cannot be used to track users directly. +
  • We acknowledge the risk of a timing attack via + CanMakePaymentEvent: +
      +
    • A merchant website sends notice via a backend channel (e.g., the + fetch API) to a payment handler origin, sharing that they are about + to construct a PaymentRequest object.
      • +
    • The merchant website then constructs the PaymentRequest, + triggering a CanMakePaymentEvent to be fired at the installed + payment handler.
      • +
    • That payment handler contacts its own origin, and on the server + side attempts to join the two requests.
      • +
  • User agents should allow users to disable support for the CanMakePaymentEvent.