Hi, as I already said via IRC, FWIW this looks to me more like a BlueVia identity protocol issue than a payment protocol issue. The privacy issue that you mention would not happen for other payment providers, unless these payment providers implement a similar identity protocol. The login information is sent only for the BlueVia use case to provide a seamless UX.
Anyway, I must agree with your privacy concerns regarding this flow. On 16/08/2012, at 10:29, Andreas Gal wrote: > > On Aug 16, 2012, at 1:13 AM, Jonas Sicking <jo...@sicking.cc> wrote: > >> Hi All, >> >> While looking at the navigator.pay API, there's one privacy concern that I >> had. >> >> As the API is currently intended to use, the flow is something like >> the following: >> >> 1. User visits website. >> 2. Website calls navigator.pay and provides a JWT-encoded request >> which contains information about what is being payed for, how much >> money is being payed, currency etc. The request is signed with the >> developers private key (which means that it must be generated >> server-side). >> 3. Gaia automatically sends the JWT encoded data to BlueVia. This >> request includes user identifying information (except for the first >> time the user uses BlueVia payments). > > Two comments here. First, as a payment agent BlueVia has a certain trusted > position. Second, the user explicitly opted into BlueVia being registered as > a payment method. If we believe that these two comments aren't sufficient, > another option is to not send the JWT to BlueVia and require that every time > a payment method is selected using a drop-down box. Once the user touches the > drop down box and selects a payment method (BlueVia), the JWT is sent, and > the UI is retrieved. > > I would argue that due to the opt-in, for V1 its ok to skip the select box > and directly send the JWT to the payment channel, but I am happy to discuss > alternatives. This could be easily implemented. In fact the selection screen (where we could add the payment information) was already implemented in Gaia and I was requested to change it for a drop down menu because of PR review feedback. I can get that screen back easily if needed. >> 4. BlueVia returns a HTML page which contains UI which describes to >> the user the information encoded in the JWT request. I.e. the details >> of the payment. >> 5. The user clicks an "accept payment" button. >> 6. Gaia displays UI which allows the user to log in to BlueVia. > > Note that this is automatic (e.g. via BrowserID). > >> 7. Once the user has logged in, BlueVia sends a server-to-server >> request to the application server indicating that payment has been >> received. >> 8. The webpage is notified that the payment went through. >> >> My concern here is step 3. It seems like a privacy leak to me that >> with no action from the user, details about something that the user is >> considering buying, or that the user accidentally clicked, is sent to >> BlueVia. Just because I trust BlueVia with handling my money, doesn't >> mean that I'm comfortable with BlueVia knowing which websites I visit. >> If I decide that I actually want to make a payment to the website >> using BlueVia, then obviously I have to let BlueVia know, but until >> then it doesn't seem like something that we should be telling BlueVia >> about. > > Note that for this to be a privacy leak, the website has to intentionally > request a payment, or in other words, the website has to intentionally leak > to BlueVia that its being visited, for this to leak to BlueVia. There are > ample of other ways of doing so that are much easier. I don't see this as > being worse than allowing sites to include images from other origins. > > Before people start throwing out Mozilla proxying payment requests and shims > as a rescue here, that approach is roughly as bad. If we consider this a > leak, it leaks to Mozilla, instead of BlueVia. > >> >> It seems like we can get a very similar UX experience with the same >> number of clicks using a flow like: >> >> 1. User visits website. >> 2. Website calls navigator.pay and provides a JWT-encoded request >> which contains information about what is being payed for, how much >> money is being payed, currency etc. The request is signed with the >> developers private key (which means that it must be generated >> server-side). >> 3. Gaia decodes the JWT data and displays the information encoded in >> the JWT request as well as a button that says "Pay with BlueVia". I agree that this would be nice to have and, as I mentioned before, it should be easy to implement. Anyway, I have a few comments about this. First of all, the JWT content is defined by the payment provider. For the BlueVia use case, the JWT contains human readable information about the digital good being sold. But other payment providers might decide not to request that kind of information within the JWT. Actually, BlueVia only needs the application identifier. That means that we might end up showing non human understandable information. Something like "You are about to pay for 12345677". To solve this, Gecko might force the JWT to have at least a clear product price and a human readable description. Apart from that, the JWT request is signed with the developer's key, *only* shared by the developer and the payment provider. Gecko doesn't know anything about the developer's key, so the JWT can't be verified before showing its content to the user. I am not saying that this is a problem, but I just want to be sure that you are aware of this. >> 4. The user clicks an "Pay with BlueVia" button. > > I guess this is equivalent to the planned drop-down box. I have no opinion on > the UX here. > >> 5. Gaia displays UI which allows the user to log in to BlueVia. >> 6. Once the user has logged in, the JWT data is sent to BlueVia. >> 7. BlueVia sends a server-to-server request to the application server >> indicating that payment has been received. >> 8. The webpage is notified that the payment went through. >> Why would the user need to be logged in before sending any JWT data to the payment provider? That would mean that Gecko would also need to know about how the payment provider handles user identification (for ex. login endpoint). If we send the JWT data and no user information, the payment provider would only know that someone anonymous wants to buy something. Isn't that ok in terms of privacy? IMO where to ask the user to log in is up to the payment provider. >> Did we do a privacy review of this API? Did this come up during that review? > > I don't think thats completed yet. AFAIK, no, we didn't do a privacy review yet. We did a security review so far. Thanks! -Fernando _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
