Re: [w3c/webpayments-payment-apps-api] Use PaymentRequest and PaymentResponse (#99)

@marcoscaceres 
>My proposed solution gives more control to users by:
>
>- Allowing the payment app to collaborate with the browser's autofill database, when both the payment app and the user want to. This is done through the payment app's UI - and in collaboration with the end-user.

This can just as easily be done by the browser.

>- Allowing the payment app to potentially hold different addresses than the autofill database.

I'm not sure how this is of benefit. I'm certain users will be frustrated by the notion that the address they already have on file with bobpay.com needs to be re-entered for alicepay.com.

>- Not having a browser's sync mechanism pass around sensitive data. This could become increasingly important in jurisdictions that coerce companies to share such data with government agencies under secret court orders without public oversight. This particularly affects foreign nationals.

Foreign nationals like myself? ;)

So, in terms of who I would trust with sensitive personal data in the face of state-level attackers, I'd trust browser data sync mechanisms far more than payment providers ([Global Payments](http://www.bankrate.com/finance/banking/us-data-breaches-9.aspx), [Chase](http://www.bankrate.com/finance/banking/us-data-breaches-5.aspx), [Citibank](http://www.bankrate.com/finance/banking/us-data-breaches-11.aspx), [Heartland](http://www.bankrate.com/finance/banking/us-data-breaches-12.aspx)) or merchants ([Target](http://www.bankrate.com/finance/banking/us-data-breaches-8.aspx), [Home Depot](http://www.bankrate.com/finance/banking/us-data-breaches-6.aspx)).

The *reason* is because those entities necessarily store information in a form that the institution can use, which means the institution can necessarily decrypt the information (if they do, in fact, store it encrypted at all, which is far from given).  Browsers, on the other hand, have the option of storing data as opaque information that the sync service could not decrypt, even under sophisticated attack or court order. See, for example, [the way Firefox handles sync data](https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol), keeping in mind that the kind of data we're talking about here is what that document refers to as "class-B data" (roughly: the class of data that Mozilla couldn't retrieve no matter how badly it wanted to).

The proof here is in the pudding: despite a number of high-profile attacks on top banks and top merchants, as I cite above, there has been no breach of browser sync data, even though it would easily be several times more valuable. I can't speak to what other browsers do; but in Firefox's case, at least, this is because such exploits are basically impossible.

So, if you're weighing the relative safety of browser sync mechanisms against the data security practices at financial institutions and merchants, you've got it exactly backwards.


>>This proposal violates that principle. It is quite possible that I, as a user, would not like my bank to know who I'm shipping gifts to, and they have no need to possess this information to perform their task.
>
>Then the user doesn't need to provide it to the payment app. That information can be provided to the merchant directly. That's what autofill is for.

We've had extensive discussions in the WebPayments working group as a whole about the suitability of form fill and form autofill for this purpose. The strong -- and maybe unanimous (I can't recall) -- consensus that it was inadequate for this purpose, and that we needed something more tightly bound to the checkout flow. Merchants were among the most vocal on this topic, implying that this was a large part of the value they see in the Payment Request API.

So, I'll reiterate my earlier point: you're pushing to re-use existing web technologies that *simply don't meet the needs of the problem*. If we take on autofill as the solution here, there's a very real risk that the value of this API to merchants will be sufficiently diminished that they simply opt not to use it. You'll have a set of documents that you personally think are more perfect in some dogmatic way, but which are effectively dead on arrival because they don't do what their audience has demanded they do.

>Additionally, just because a merchant says they need your address, doesn't mean the user should trust them (and the browser shouldn't just be giving it out without the consent of the user - which, in my model, is negotiated between the user and the payment app through the payment app's UI).

I would certainly expect browsers to give users full agency over whether this information, when requested, is actually provided to merchants.

I'll also note that your proposal, as you describe it, has a pretty big Achilles' heel in this respect: just as the payment app can elect to negotiate between itself and the user whether to provide this data, it can also elect to provide it without any user approval at all.

>>Moreover, if I'm using a Bitcoin app to provide my payment, and the key value proposition of that Bitcoin app is that it has little to no personal information about me, giving it my full name and shipping address defeats its purpose pretty much entirely.
>
>Again, the user is not obliged to provide this information to the payment app. The point is to put the user in control: if the payment app fails to provide the requested information (e.g., shipping address, name, etc.) to the merchant, then the merchant can get that information autofilled by the browser. Or, failing that, the user types that information manually into the merchant's site.

Which, as I say above, is exactly what merchants want to avoid.

-- 
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/99#issuecomment-277045374