Re: [w3c/payment-handler] Open Window Algorithm and tracking through 1ps (#351)

From discussion with @snyderp @marcoscaceres @aestes @rsolomakhin @ianbjacobs yesterday, I believe we reached the following consensus:

- Payment handler window will only have 3P access to storage by default, unless user has consented previously.
- User can consent to granting 1P storage access to a payment handler (identified by its origin) via a few new browser affordances:
  - (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".
    - The consent granted here may be revoked after some period of inactivity with this payment handler, at the browser's discretion.
  - (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.

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

Implications to the [Payment Handler API](https://w3c.github.io/payment-handler):
- Add a "request storage access" sub-step to the beginning of the [open window algorithm](https://w3c.github.io/payment-handler/#open-window-algorithm) to reference the [request storage access algorithm](https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess).
- Clarify the storage partition accessible by the payment handler based the result of the previous step.

Implications to 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.

Implication to 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.

Other noteworthy points discussed:

- While payment handler API is not fundamentally different from a popup, @snyderp points out that Safari may be taking steps to make popups default to 3P context.
- 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.
- 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.

Next steps:

- I'll flesh out the Service Worker implications
- Start a pull request to incorporate the proposed changes

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/issues/351#issuecomment-566642121