Re: [w3c/browser-payment-api] How are digital signatures supported for Payment Requests? (#291)

@ianbjacobs wrote:
> In addition to those efficiency questions (the payment app will ignore most data it receives otherwise, which is an inefficient use of time and bandwidth), privacy was cited - sharing more data (from the merchant) than needed to handle the payment.

So, I'm hearing the decision was made due to:

1. inefficient use of time (assuming you mean "time to transmit" or "time to process"?)
2. inefficient use of bandwidth
3. merchant privacy

I'm not taking a position on this yet because we're talking about a fairly complex trade-off, but pushing back on those points above a bit:

Regarding inefficient use of time - perhaps we should have some timing statistics to see how much time we're talking about. I expect that it will be on the order of a few hundred microseconds at most since the Payment Request communication channel is web page to web page. Page bloat is at least 2MB at present: https://gigaom.com/2014/12/29/the-overweight-web-average-web-page-size-is-up-15-in-2014/ so even if it's shoved down an HTTP pipeline, I can't imagine it being more than a few milliseconds (a tiny fraction of page load time). I don't find this argument compelling.

Regarding inefficient use of bandwidth - the biggest contributor to the bandwidth is the array of payment methods which are a couple of hundred bytes in all the cases we've seen. Again, a few hundred microseconds at most since the Payment Request communication channel is page to page. I know WorldPay has stated that they support 200+ payment methods, but do those boil down to mostly cards? The question is, what's the largest array of payment methods we're expecting and how many transactions are going to use that largest array? If we multiply the example in the spec by 10x, we get around 1.8KB for the payment method array. That doesn't seem like a waste of bandwidth. Multiplying it to 200x gives us 36.6Kb, which is much larger, but certainly a drop in the bucket compared to what the rest of the page is using. I'm not convinced by the inefficient use of bandwidth argument.

Regarding the privacy argument - the assumption is that the merchant doesn't want to advertise all of the payment methods that they support to payment apps. I find this argument the most compelling, but don't fully understand how we're protecting this information from being leaked. For example, (in 80+% of cases) can't anyone come to the merchants website and execute a payment request and then cancel it? In that scenario, one can find out the payment methods that the merchant supports even with the "protections" we've built in. The only time the merchant is protected against this "privacy violation" is when the transaction is such that the payment app provider can't get access to the merchant website to execute a payment request. Do merchants really care about this form of privacy? Do they understand that we can't really protect them against this privacy violation unless they put access control of some kind in front of their Buy button?

So, I think there is a very thin "privacy protection" argument for only forwarding payment app specific payment method information to the payment app. If that argument holds, then we're going to have to create an entirely new type of algorithm for digitally signing and verifying 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/browser-payment-api/issues/291#issuecomment-253257073