Re: [w3c/webpayments-payment-apps-api] Revisiting payment app filtering (#96)

@jakearchibald 
> What we need to maintain though is the requirement that the event handler is executed in a "sandbox" of some sort that prevents the data passed in being stored or sent over the network.

While this would conceptually take care of the privacy concerns, I feel that this might be too hard to implement in a secure way. Are there any examples of similar things in existence today, or are we treading new ground here? If it's the latter, then I am apprehensive about this.

@marcoscaceres 
> But the only info the SW gets is "someone wants to know if you can handle this" - not who or what or where they are trying to buy. So the info is not useful beyond "lots of sites wonder if this particular payment method is supported by me".

The SW is installed into a browser by a web site that might have the user logged in. It also regularly opens client windows which presumably will prompt for user login. I think that the SW *does* know "who".

As for "what" and "where", these depend on the contents of the opaque `data` fields in the payment request. Although this is out of our control, I think it is likely that most of these will contain something that lets the payment provider identify the merchant. My gut feeling tells me that the SW can know "where". If the merchant is narrow enough in scope, the payment provider can probably also get some ideas about "what", just by knowing "where".

@marcoscaceres 
> In fact, there may be no intent to buy anything - because a site intimates a canMakeActivePayment() potential long before any actual payment happens (if it happens at all!). The browser knows the registered methods of the app, so it could strip out the ones that don't match.

It is likely that `canMakeActivePayment()` will be called while loading the web page, in order to construct a "Buy" button. If my assumptions above, about the payment provider's ability to infer "who" and "where" are correct, then this does not make things any better at all. In fact, this might make a payment provider able to track every visit a user makes to any page that uses payment requests.

-- 
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/webpayments-payment-apps-api/issues/96#issuecomment-275060709