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

I think the problem boils down to this: both legitimate payment handlers and trackers would want to access 1P storage with minimal user friction. Browsers need to allow legitimate use cases while blocking trackers.

Segmented storage blocks 1P storage by default and relies on browser heuristics to remove as much user friction as possible for well-behaved websites that use Storage Access API. For example. Safari suggested automatically granting `requestStorageAccess()` calls that are triggered by user gesture, and only prompts if the browser suspects some funny business is going on [1]. Microsoft seems to be planning something similar from talking to them at BlinkOn last week. I understand that Brave had made a different decision to always prompt by default [2].

What about this alternative approach: instead of blocking storage access, browser can use an algorithm similar to that for granting storage access [3] to block `PaymentRequest.show()`?

I believe this is better than the segmented storage approach in two ways:
The risk of a tracker masquerading as a payment handler is more than access storage: the payment handler window itself, because it looks like native UI, is a powerful feature that needs to be restricted to only legitimate use cases to avoid losing user trust. Blocking access before the open window algorithm triggers solves this problem.
Once a payment handler is “vetted” in a browser, developers can reuse their existing flows without modification.

Browser can work with the user to “vet” payment apps that they trust. For example, browser can show a permission prompt when installing a payment handler with something like  "Do you wish to install https://ewallet.com as a payment method that you can use across the web?" An affirmitive answer would allow this payment app to be loaded in the open window algorithm. Or, browser can prompt the user when `PaymentRequest.show()` is called, e.g. “Do you wish to complete this transaction with ewallet.com?”, and offer an option to never prompt again. Chrome doesn’t do any of these today, but if folks feel this is sufficient we can doing some UX exploration.

While this model still allows some communicaton between 1P contexts (i.e. the merchant context and the payment app context), the user vetting process above limits the capability to only payment apps known and trusted by the user. Also because the communication is via Payment Request API instead of the generic postMessage, this leaves room for browser to detect and restrict abuse.

Lastly, we’ll make sure all the obvious loopholes are closed in the Payment Handler API, i.e.: `window.opener` and `document.referrer` are null.

[1] https://github.com/whatwg/html/issues/3338#issuecomment-357790890

[2] https://github.com/whatwg/html/issues/3338#issuecomment-358151664

[3] https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess


-- 
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-555228894