privacy topics for Payment Request API and Web Payments

Apologies for not getting these notes more polished or out earlier, but I wanted to at least collect some of the privacy topics that came up in our PING meeting last month, in the hope that they can still be useful to Web Payments as they are actively pushing documents through wider review. I'm sending these directly to the Web Payments group (because I'm getting to this late), but if PING folks have more detailed comments on these brief notes, I expect that would be welcome.

Some of these notes just re-iterate comments that came up in our 16 February call:
https://lists.w3.org/Archives/Public/public-privacy/2017JanMar/0029.html <https://lists.w3.org/Archives/Public/public-privacy/2017JanMar/0029.html>

Hope this helps,
Nick

---

## Privacy goals

It might be useful for the Web Payments effort if there were an agreed upon list of privacy principles and goals that we had in mind for the many specifications likely to come out of this work. If there's interest, I think PING would be a good place to get feedback on a 1-pager of that kind. (There is some information about this in the charter, but there might be more tacit ideas that would be useful to document.)

One goal I think we should have for Web Payments would be for payment infrastructure that discloses less information/identification when making a payment. While we often think of large credit card payments for purchasing items to be mailed to us (at which point, the user's identity is quite clear, in a way that is well-established and reveals their geographic location), it would be great to see Web Payments that could be used for smaller digital transactions that don't require revealing persistent unique identifiers like a credit card number or shipping address. We understand this to be a longer term goal, and that current APIs are to handle the basic case of existing basic credit card payments, but it's worthwhile to note this as an area where an API can provide not only usability and efficiency, but potentially a large privacy gain.

## Payment apps

It seems that the Payment API spec specifically leaves the design of "payment apps" open to implementers. That seems like a reasonable, flexible design. However, it seems like there will often be privacy questions about the apps, and that their implementation could violate the Web's privacy model. I think the typical questions we have about such plugins are:
* do they scope data to a particular origin? (if not, there are risks about cross-origin fingerprinting/cookies)
* do they reveal data about a user or device? any sensitive data? under what conditions?
* do they persist data separately from the browser? (are we creating new evercookies?)

It's not exactly clear how Payment Apps are going to be installed or vetted or explained to the user. If new payment methods or payment apps are being added/installed regularly, it seems like it could be a particular concern for persistently tracking users.

## Information disclosed by a payment

One privacy concern might be increased and unexpected information disclosure when making a payment. If I just click on a little credit card icon on my browser, it might not be clear to me that I'm also sending billing address/shipping address information to the site as well.

## Drive-by information disclosure

Of particular concern, for fingerprinting and for information disclosure in general, is what information is disclosed without a user prompt step. As is already noted in the drafts, the canMakePayment() method is of concern here because it provides some information not just whether the payments feature exists in a browser, but whether a payment type is supported by the user's particular configuration, without ever notifying the user. Strict quota limits by user agents may indeed be a good way to mitigate the privacy cost here, if this feature is required for the API functionality. That said, it seems like a small number of calls with very specific PaymentRequest objects could potentially introduce a lot of entropy.

## Security

Is this feature safe to use outside of secure contexts? It would seem to be an especially bad practice to send credit card and other financial transaction information over HTTP.

Are there any particular risks associated with XSS attacks that could lead to user's losing money? If I've approved a permission request on this origin before and an attacker manages to insert their own JavaScript, is it possible that they can complete payments that they wouldn't have been able to with legacy methods?

## Addresses (not privacy-related)

Is this an entirely new civic address standard? It would be preferable to cite an existing standard, rather than proliferating yet another way to represent civic addresses; existing standards may also help with worldwide usability.