On Thursday, 16 August 2012 09:13:04 UTC+1, Jonas Sicking 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). > > 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. > > 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. > >
Actually, the user will need to be identified before he can accept the payment, we cannot show the appropriate information for the payment if we don't know who the user is. e.g: in what currency he is going to be charged. Take into account also that the Advise of Charge is going to change between countries and carriers due to local legal requirements and carrier requirements. > 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. > I don't think it's with no action, the web app should invoke navigator.pay once because the user has an intent to do a purchase. Besides that, how does this compare to how the web actually works already? Right now any website can embed Google Analytics or Facebook Connect scripts and those companies can track what websites I'm visiting. How does this compare to loading a javascript from paypalobjects.com in every marketplace webpage? > 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. > > 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. > As I commented, Gaia cannot present the Advise of Charge page because it'll change from user to user. Best, Ernesto _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
