Skip to content

Commit

Permalink
[Spec] Remove user-identifiable information from canMakePayment (#404)
Browse files Browse the repository at this point in the history 
* [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
  • Loading branch information
@stephenmcgruer
stephenmcgruer authored Dec 14, 2022
1 parent d61d41c commit 3a6c1e8
Showing 1 changed file with 20 additions and 69 deletions.
89 changes: 20 additions & 69 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -816,18 +816,10 @@ <h2>
<pre class="idl">
[Exposed=ServiceWorker]
interface CanMakePaymentEvent : ExtendableEvent {
constructor(DOMString type, optional CanMakePaymentEventInit eventInitDict = {});
readonly attribute USVString topOrigin;
readonly attribute USVString paymentRequestOrigin;
readonly attribute FrozenArray&lt;PaymentMethodData&gt; methodData;
constructor(DOMString type);
undefined respondWith(Promise&lt;boolean&gt; canMakePaymentResponse);
};
</pre>
<p>
The <dfn>topOrigin</dfn>, <dfn>paymentRequestOrigin</dfn>,
<dfn>methodData</dfn>, and <dfn>modifiers</dfn> members share their
definitions with those defined for {{PaymentRequestEvent}}.
</p>
<section>
<h2>
<dfn>respondWith()</dfn> method
Expand All @@ -837,23 +829,6 @@ <h2>
can respond to a payment request.
</p>
</section>
<section data-dfn-for="CanMakePaymentEventInit">
<h2>
<dfn>CanMakePaymentEventInit</dfn> dictionary
</h2>
<pre class="idl">
dictionary CanMakePaymentEventInit : ExtendableEventInit {
USVString topOrigin;
USVString paymentRequestOrigin;
sequence&lt;PaymentMethodData&gt; methodData;
};
</pre>
<p>
The <dfn>topOrigin</dfn>, <dfn>paymentRequestOrigin</dfn>, and
<dfn>methodData</dfn> members share their definitions with those
defined for {{PaymentRequestEvent}}.
</p>
</section>
</section>
<section>
<h2>
Expand All @@ -875,40 +850,8 @@ <h2>
<li>
<p>
<a>Fire Functional Event</a> "<code>canmakepayment</code>" using
<a>CanMakePaymentEvent</a> on <var>registration</var> with the
following properties:
<a>CanMakePaymentEvent</a> on <var>registration</var>.
</p>
<dl>
<dt>
<a data-lt="CanMakePaymentEvent.topOrigin">topOrigin</a>
</dt>
<dd>
the [=serialization of an origin=] of the top level payee web
page.
</dd>
<dt>
<a data-lt=
"CanMakePaymentEvent.paymentRequestOrigin">paymentRequestOrigin</a>
</dt>
<dd>
the [=serialization of an origin=] of the context where
PaymentRequest was initialized.
</dd>
<dt>
<a data-lt="CanMakePaymentEvent.methodData">methodData</a>
</dt>
<dd>
The result of executing the <a>MethodData Population
Algorithm</a>.
</dd>
<dt>
<a data-lt="CanMakePaymentEvent.modifiers">modifiers</a>
</dt>
<dd>
The result of executing the <a>Modifiers Population
Algorithm</a>.
</dd>
</dl>
</li>
</ol>
</section>
Expand Down Expand Up @@ -1454,7 +1397,7 @@ <h2>
Algorithm</a>.
</dd>
<dt>
<a data-lt="CanMakePaymentEvent.modifiers">modifiers</a>
<a data-lt="PaymentRequestEvent.modifiers">modifiers</a>
</dt>
<dd>
The result of executing the <a>Modifiers Population
Expand Down Expand Up @@ -1944,16 +1887,24 @@ <h2>
</li>
<li>In a browser that supports Payment Handler API, when a merchant
creates a PaymentRequest object with URL-based payment method
identifiers, <a>CanMakePaymentEvent</a> will fire in registered
payment handlers from a finite number of origins: the origins of the
identifiers, a <a>CanMakePaymentEvent</a> will fire in registered
payment handlers from a finite set of origins: the origins of the
payment method manifests and their <a>supported origins</a>. 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
<a>CanMakePaymentEvent</a> 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.
<li>We acknowledge the risk of a timing attack via
<a>CanMakePaymentEvent</a>:
<ul>
<li>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.</li>
<li>The merchant website then constructs the PaymentRequest,
triggering a <a>CanMakePaymentEvent</a> to be fired at the installed
payment handler.</li>
<li>That payment handler contacts its own origin, and on the server
side attempts to join the two requests.</li>
</ul>
</li>
<li>User agents should allow users to disable support for the
<a>CanMakePaymentEvent</a>.
Expand Down

0 comments on commit 3a6c1e8

Please sign in to comment.