Re: [w3c/payment-request] Revert activation relaxation in show() -- find a general platform solution instead (Issue #1064)

RByers left a comment (w3c/payment-request#1064)

I'm not sure this framing is correct. I left some big-picture thoughts in the [TAG issue](https://github.com/w3ctag/design-reviews/issues/1213). But for payments specifically, the problem is handling the case of a user clicking to pay from one page, which redirects to another page completely to handle the payment there (not an iframe or a popup window). Capability delegation says nothing about that problem, right? I'm all for discussing better solutions, but we need to start with an agreement on the problem we're aiming to solve.

In general, in chromium we have found user activation restrictions to be useful in two cases:
1. Preventing abuse from iframes within a page. Permissions policy and capability delegation work together to ensure powerful capabilities can only be used in cross-origin subframes when ancestor frames have opted in. 
2. Throttling annoying behavior in the main frame. Eg. a page can open only one pop-up per tap. 

When we've tried to use user activation restrictions to fully prevent abuse in the main frame, it's largely failed. Eg. requiring a user activation for `history.pushState` just caused pages to add annoying "click here to keep reading" buttons. The fundamental problem here is not that we can't delegate the activation signal properly, it's that there is very little meaning in the activation signal itself. Our larger vision for properly solving this is problem is to replace "activation" constraints with browser-controlled in-page UI ala [PEPC](https://github.com/WICG/PEPC). Then when a user taps on what we know is a camera control, we know they've provided a signal that they want access to their camera.

So in the payments context I'd suggest maybe the right long-term fix is a <payment> PEPC element which, once tapped, unlocks all browser-based payment UI even across redirect chains. The problem is that this is a HUGE activation lift which can really only start once all engines have some PEPC support. Until then, I think we're stuck with pragmatic hacks like what WPWG has long ago resolved on here following their consensus process for active members in the group.

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

Message ID: <w3c/payment-request/issues/1064/4421890389@github.com>