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

> > I'm referring to this part of @othermaciej's comment:
> 
> Ah, thank you for pointing that out. I did not catch that, my error. However, I don't think something like that can be embedded in a spec, w/o defining what "funny business" is, and the privacy of a spec shouldn't turn on unstated heuristics of what "funny business" is, so I think it best to focus on the algorithm described in the spec.

The current algorithm as described in [1] leaves prompting to browser discretion. I think this is refers to browser's heuristic on detecting "funny business".

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


> > 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.
> 
> The concern is (i) the abuse potential, and (ii) the worry about adding privacy debt to the platform through something that gets misused in a way we can't foresee.
> 
> So, I'm not saying that there's no legit use cases, or that there is no way to get the feature safe, just that there should be a strong precautionary principal in place (and that "lets make an exception for my feature" is a common thing I hear, that is definitely not inline with caution, not saying that thats what you said :).

I agree with both of your goals. I think the best next step is to elaborate on the privacy / security model of Payment Handler API, and enumerate, as exhaustively as possible, privacy attack vectors. Then we can decide if 3P storage are an effective mitigation to these threats.

Separately, I'll also start documenting payment app use cases that will be significantly impacted if payment handler window becomes a 3P context. I hope this will allow us to make a pragmatic decision.

FWIW, I think a pragmatic decision is important. The web doesn't exist in an vacuum. The web will be out-competed by other platforms if it either fails flatly on privacy or if makes it impossible to build important user journeys. If I may just get a little philosophical, I feel payments is very important to the web, because the web's lack of a proper monetization model is part of what incentivized pervasive tracking. A secure, privacy-sensitive and low-friction payment primitive will allow content creators to monetize directly instead of relying on personalized ads.

> > The main difference is that the proposal can reject PaymentRequest.show before…
> 
> The concern here is that there doesn't seem to be a way that I can use the payment handler w/o giving it 1p storage. E.g. I have to give the context all or nothing, where 2y'd storage is in place to prevent putting users in this situation. Is there a way you can structure / order things where I can use the payment handler, w/o giving 1p storage?

Why should the payment handler be treated differently from a popup window, which has 1P storage?
 
> The `requestStorageAccess` approach would seem to solve both use cases in my mind. By default I could save my self having to type in address info when reusing the same payment handler on the same site, and if wanted, the payment handler could use requestStorageAccess() to get the same privilege across all sites. Im not trying to be dense, but what use case am I missing?

The main use case I was worried about is using the same payment handler across all sites. I worry that if browser is required to prompt the user on every {website, payment app} combination, this will be a bad user experience. But I've never built a payment app buyflow, so maybe this is solvable. This is why I'd like to work with a real payment app to gain more nuanced understanding of the problems here. The documents I promised above should help me develop a more informed opinion.

> > Admittedly this idea needs more exploration. My initial thinking is that the Payment Request API is designed to serve a specific use case…
> 
> I would be interested in hearing more, but in general, I think you should start with the assumption that that any communication channel can ultimately be leveraged for arbitrary communication. Also note that any heuristic that depends on "did X match Y" or similar has likely already let some information pass and the cats already out the door…

Acknowledged.

To summarize, I think the best way to move this discussion forward is to do the following:

1. I'll create a document to enumerate privacy attack vectors enabled by Payment Handler API
1. I'll continue to work with payment apps we have relationship with to evaluate the impact of switching to 3P storage will have on existing use cases

Given that these tasks will take some time, one way we can limit the impact now is to move Payment Handler API behind Origin Trials [2]. Do you have a strong opinion about this?

[2] https://github.com/GoogleChrome/OriginTrials


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