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

> > 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
> 
> I don't see anything about "automatically granting". The user gesture part is a requirement, but isn't access itself.

I'm referring to this part of @othermaciej's [comment](https://github.com/whatwg/html/issues/3338#issuecomment-357790890):

"Although prompting is allowed by our proposal, we expect in most cases we will just grant the permission without prompting, as the user action is sufficient. We will prompt only if we suspect some funny business is going on, and even then we may just choose to always deny."

> The browser doesn't need a long list of new, hard to reason about, hard to compose guesses for when privacy isn't needed. I appreciate, from your perspective "what's one more little exception", but that is the way that privacy on the platform will continue to crumble; a long list of growing exceptions.

I understand we don't want yet another straw. I care very much about Payment Handler API not being abused for non-payment use cases. Suppose I can distinguish perfectly a payment use case from others, and only allow a legitimate payment app to use the open window algorithm to access 1P storage, would you still consider this a privacy hole?

What I'm trying to understand is whether the concern is the abuse potential of the API or whether you don't see any legitimate use case at all.

> More specifically, can you say how your proposal for `PaymentRequest.show` differs from the one `requestStorageAccess`? 
>
> Are you proposing the exact same algorithm, just with different words in the user prompt? If thats the case, I would be fine with this; but I don't understand how it differs from the original request, to make the payment handler context a standard 3p content. I don't mean any argument, im just trying to understand the current suggestion.

The main difference is that the proposal can reject `PaymentRequest.show` before the payment handler context is even constructed. This is doable because `show` is called from the merchant context. It is not possible with `requestStorageAccess` because it is called from the embedded context.

From the user's perspective, the difference can be much smaller. In both cases, the user clicks on something and then sees a permission prompt with some message. I'd prefer reusing the same prompt UI if possible because it seems less confusing to users. I'll need to talk to our UX folks.

> > Also because the communication is via Payment Request API instead of the generic postMessage, this leaves room for browser to detect and restrict abuse
>
> Can you say more about this? Any communication channel can quickly be converted to transmit arbitrary data

Admittedly this idea needs more exploration. My initial thinking is that the Payment Request API is designed to serve a specific use case, so we may be able to leverage domain specific knowledge to prevent abuse. For example, we can use signals such as the total amount, completion rate to check if a payment handler is likely real or not. Browsers can also develop heuristics for detecting e-commerce websites and known payment apps and block suspicious "payment handlers" similar to Safe Browsing.

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