Re: privacy topics for Payment Request API and Web Payments

> On Mar 23, 2017, at 8:15 PM, Nick Doty <npdoty@ischool.berkeley.edu> wrote:
> 
> 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

Hi Nick,

Thank your for sending these. I have some notes and suggestions below and would like to hear your thoughts.

Ian


> ---
> 
> ## 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.)

The Interest Group developed a Vision for Web Payments in 2015 that speaks (a bit, not much) to privacy goals: 
 https://www.w3.org/Payments/IG/Vision

I mentioned two privacy design goals in my presentation to the PING [1], namely:

 * The API is designed so that only the information necessary for a given party to fulfill its role is available to that party.
 * Users must consent to (a whole list of things….)

There is a Privacy considerations section in the spec that speaks to these:
 https://w3c.github.io/browser-payment-api/#privacy-considerations

We don’t have a more substantive list of privacy design goals. I don’t think that such a document should prevent us from entering CR, but
it might indeed be useful to document. Do you have any examples of similar documents from other groups that we might steal from? :)

We also have a FAQ where we could add a section explicitly on privacy design goals (drawing from the above):
   https://github.com/w3c/payment-request-info/wiki/FAQ

[1] https://www.w3.org/2017/Talks/ij_ping_201702/payments.pdf

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

This sounds like the aforementioned goal of "The API is designed so that only the information necessary for a given party to fulfill its role is available to that party.” We believe that Payment Request API will make it easier to bring payment methods to the Web that have these sorts of properties.
> 
> ## Payment apps
> 
> It seems that the Payment API spec specifically leaves the design of "payment apps" open to implementers.

It may not have been clear that we are working on a separate specification that explains how Web apps can handle payment requests:

 Payment Handler API
 https://w3c.github.io/webpayments-payment-apps-api/

We anticipate taking this to FPWD over the next month or so.

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

Web apps request permission by origin to handle payments.

> * do they reveal data about a user or device? any sensitive data? under what conditions?

It is an explicit goal not to do so.

> * do they persist data separately from the browser? (are we creating new evercookies?)

We are relying on service workers in the design. 
> 
> 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.

SUGGESTION: That I add an issue on the Payment Handler API to clarify what needs to happen from a privacy perspective when a user unregisters a payment app.

> ## 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.

In the user interfaces we have seen so far (see, for example, Google developer documentation [2]) users are presented with the
set of information they are confirming. So I don’t think it’s the case that they are clicking on a credit card icon, for example, and that
a lot of other information is being shared without them realizing it.

[1] https://developers.google.com/web/fundamentals/discovery-and-monetization/payment-request/

> ## 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.

The WG is sensitive to competing goals here (and has called out the issue in a Note in the spec). Implementation suggestions very welcome.

> 
> ## 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.

I believe that the expectation is that calls are made in a secure context. I have added an issue on the spec to ensure that is clear:
 https://github.com/w3c/browser-payment-api/issues/501

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

Since we are building Payment Handler API on other Web technologies (including service workers and the permissions model) part (most?) of the answer may hinge on the behavior of those technologies.

(Aside: We have also asked the Security IG and TAG for review!)

> ## 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.

The group has discussed this, see:
  https://github.com/w3c/browser-payment-api/issues/6
  https://github.com/w3c/browser-payment-api/issues/189

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Monday, 3 April 2017 15:46:52 UTC