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

I think that changing this into an event might not be such a good idea privacy-wise. In a regular event handler, there's nothing stopping the service worker from logging all of the payment request information and passing it back to the back-end. That would let an information-greedy payment provider see all of the user's potential payments -- even the ones that don't ultimately end up in that particular payment app.

The intention of the currently specified mechanism is that the registered `canHandle()` function should be a "pickled", "pure" function ("pure" meaning that the function does not rely on anything other than the input parameters, and does not have any side-effects).

I'm not actually a great fan of the current `canHandle()` mechanism, but since I don't have a better suggestion, I think it's acceptable, as long as we can show that it's implementable. If not, then I would like to propose that we drop the whole `canHandle()` mechanism.

Since this has turned out to be very difficult to specify in a way that fulfills everyone's needs, maybe it would be better if we postponed this mechanism to version 2 of the specification? That would require that we revert some changes to the `basic-card` specification, and move back to having individual method IDs for the various types of cards, with all the problems that entails, but maybe those problems are easier to tackle.

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