2020 3p context

One of the main goals of developing an ecosystem of payment handlers has been to streamline checkout by making it easy for users to return stored data rather than re-type similar information across the Web. Thus, by nature, payment handlers are meant to share information with different origins.

However, as was pointed out by Pete Snyder in payment handler issue 351, browsers generally are moving in a direction of reducing this sort of access to global storage. As Pete wrote:

If I'm reading [Payment Handler API] correctly, this would enable types of tracking that other parts of the web platform are trying to address (specifically, double-keying, or partitioning, storage by 1p-3p to prevent the 3p from tracking the user across the web). If I read the spec correctly, the standard would allow the payment processor to track the user across pages that use the processor, since the processor would always have access to the same global storage, instead of different storage for each 1p it appears under.

Updating the spec so that open window doesn't create a top-level-context, but a 3p context, would solve this problem, and would be inline with the privacy protections being pursued by partitioning storage, Storage Access API, etc.

Today, Chrome opens payment handler windows in a 1p context. The following proposal changes that behavior.

Proposal

• By default (and without prior consent), payment handlers will only have 3p access to storage.
• Users can consent to granting 1P storage access to a payment handler (identified by its origin).

Forms of Consent

Consent to grant 1P storage access may take a variety of forms. For example:

• (a) At payment handler install time: browser can offer user an option to opt-in, e.g. "would you like to allow wallet.example to access storage on all origins?" The default should be "no".
• (b) During first use of a payment handler: browser may prompt user to opt-in if no previous consent exists.
• (c) Periodically, during payment handler invocation: browser has the discretion to re-prompt user to opt-in based on signals such as the time of last consent and activity with the payment handler.

Note: For both (b) and (c), Chrome, Firefox and Safari developers all indicated desire to reuse the same prompting strategy as the respective Storage Access API implementations.

Revocation of Consent

• Users may explicitly revoke consent.
• Browsers (at their discretion) may revoke consent after some period of inactivity with this payment handler.

Implications

For users

• User may see more explicit prompts when a payment handler is installed and when they first use a payment handler. Browser vendors have discretion on the UX specifics. In general, we believe that if done right, the small friction of such "ceremony" is beneficial for establishing user trust.

For payment handler developers

• None. The browser will treat a PaymentRequestEvent.openWindow() call as an implicit request for storage access, so developers don't have to explicitly call document.requestStorageAccess().
• Browsers will fine-tune the UX of payment handler installation and prompting strategy to ensure no unnecessary friction is added to legitimate payment handlers.

For the Payment Handler API specification

• Add a "request storage access" sub-step to the beginning of the open window algorithm to reference the request storage access algorithm.
• Clarify the storage partition accessible by the payment handler based the result of the previous step.