-
Notifications
You must be signed in to change notification settings - Fork 42
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.
- 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).
Note: This summary captures the consensus view expressed on issue 351, but see that issue for all of the details.
- While the implementation in Chrome today of payment handler windows does not fundamentally differ from the implementation of popup windows, Safari may be taking steps to make popups default to 3P context.
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.
- Users may explicitly revoke consent.
- Browsers (at their discretion) may revoke consent after some period of inactivity with this payment handler.
- Users should be able to opt out of being prompted for 1p access.
- User may see more explicit prompts when a payment handler is installed and when they first use a payment handler. Firefox shared from their Storage Access API implementation experience that over-prompting has real UX harm. So some browser heuristic to avoid prompting user on every {payee, payment-handler} pair is probably essential. In general, we believe that if done right, the small friction of such "ceremony" is beneficial for establishing user trust.
- 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.
- 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.
- The payment handler's Service Worker should probably be subjected to the same storage access restrictions as the visible payment handler window context. However, there are scenarios where the Service Worker is active without a visible web context (e.g. when hasEnrolledInstrument() is called or when a ServiceWorker chooses to handle show() without calling openWindow()). This needs a bit more thought to flesh out the details.
- Discuss opting out of prompts regarding access to 1p storage. Maybe we can add an optional disableRequestStorageAccess argument to openWindow().