On Thu, Aug 16, 2012 at 1:29 AM, Andreas Gal <g...@mozilla.com> 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.
As I said below, just because a user is comfortable with doing payments through BlueVia doesn't mean he/she is comfortable sending arbitrary browsing information to them. I'm personally fine with funneling most of my payments through both the Chase bank as well as the Visa credit card company. But I wouldn't trust either of them to not try to use my browsing history to make money in ways that I'm not ok with. For example by sending that information to third parties. >> 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). Indeed. I don't have any issues with this step. It's exactly the same in my alternative proposal. >> 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. The problem is that if we define the navigator.pay API as "only call this function once you have made absolutely sure that the user is willing to pay for this item/service" then that means that websites would have to be responsible for popping up an extra dialog asking users "are you sure that you want to pay for this?". This is exactly the type of extra step that I think we're trying to avoid. It's to our users benefit if we can tell web developers that we will ensure to not sure the data with anyone without consulting the user first. > 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. This is not what I'm proposing. >> 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". >> 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. I'm happy to leave this up to UX too. I just wanted to demonstrate that it's possible to create UX which doesn't require additional clicks. / Jonas _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
