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.

> 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 :).  

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

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?

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

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