On Aug 16, 2012, at 1:13 AM, Jonas Sicking <[email protected]> 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.

> 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".
> 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.
> 
> Did we do a privacy review of this API? Did this come up during that review?

I don't think thats completed yet.

Andreas

> 
> / Jonas
> _______________________________________________
> dev-b2g mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-b2g

_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security

Reply via email to