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

> On 25 Jan 2017, at 6:46 pm, Adrian Hope-Bailie <notifications@github.com> wrote:
> 
> I like the approach of using an event (I think I have heard consensus that the group i happy with this change).
> 
> 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.
> 
We can't do that, unfortunately. That would break service workers. It would also be super easy to work around (just put everything in IDB or make a text file with the Cache API, and then send it later). 

So, if there is data that the event should not expose, we should talk about that: the event *is* the sandbox. 

My proposal only exposes filtered payment methods and whatever is on the DOM Event interface, from which it inherits. 

> As @ianbjacobs points out, this is partly based on privacy concerns, but also because this needs to return quickly as it likely impacting UI (the set of apps being presented to the user)
> 
That's the ideal, but not what can happen in reality. For example, the service worker may need to connect to a watch or other device over Bluetooth (actually bought something today like this with my Apple Watch) or might need to verify that the payment method has balance over the network or whatever - it's up to the application, we shouldn't restrict how it checks. If it is taking too long (or the SW shuts down), then the browser can intervene appropriately. 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 


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