Re: [w3c/browser-payment-api] Why another API? (#203)

@ianbjacobs 

> I believe that browser vendors are particularly interested in this work

Yes, that's something which frightens me. Soon we'll have browsers fighting with payment methods, using devices as leverage and cutting deals with banks.
Providing an alternative browser experience gets ever more difficult.

> Do you mean "fundamentals for payments"? What are the fundamentals you have in mind?

No, exactly not "for payments". Payments are just one thing - and it seems if we have a browser API for that, then were do we stop?

We *do* need multiple competing attempts (formats if you will) to spec and standardise payments between merchants and customers, but I don't want to involve browser vendors (at almost any cost).

Instead we need a generic way for web applications to expose functionality to, and communicate with, other web applications on the same device/browser. Maybe a Service Worker thing? That would have endless possibilities: sharing data from a spreadsheet to a graphical tool, post a message with the users favourite chat app, saving tickets to a wallet app or authentication without having to choose from the webmaster's favourite social networks to name a few. But this is of course a whole other discussion.

@burdges 
That's a valid point. On the other hand even the API itself will increase the number of browser differences available for fingerprinting.
IMO it is the responsibility of the wallet app you're using to reduce it's footprint and keep itself anonymous.
Using an incognito mode you would of course expect the browser to have additional confirmation steps in place before any inter-communication happens.

---
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/browser-payment-api/issues/203#issuecomment-220839151