On Thu, Aug 16, 2012 at 2:16 AM, Fernando Jiménez <[email protected]> wrote: >>> 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.
Don't we have the freedom to impose what JWTs that we are willing to funnel between the website and the payment provider? I.e. can't we require that the JWT contains human readable descriptions? > 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. Yup. I'm aware of this. It's definitely somewhat worrying, but it seems to me like it should work as long as the JWT request is signed rather than encrypted with the developer key. It could result in the situation when the user could be shown a UI saying "a payment for $10 is requested for this bowl of virtual chicken soup", but once the user clicks "pay using BlueVia" and logs in, he/she is faced with a dialog saying that the payment request is invalid. Not ideal, but also likely not going to happen terribly often since there is no incentive for the website to do so. >>> 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? I'm a bit confused as to what you are proposing since you are commenting on the user-flow in my counter proposal. Did you intend for this comment to be in response to step 3 in the original flow? If so, yes, it's true that we could do step 3 without sending user identifying information to BlueVia. But that wasn't the flow that was described to me when I asked how the proposed API worked. If we make sure to not send any cookies to BlueVia in step 3 of the original flow then that definitely limits the privacy leak. But it would also mean adding platform support to loading iframes without sending cookies. Something we currently don't have. The other problem is that it's relatively easy to fingerprint people even if we don't send cookies. Especially once you open an <iframe> which lets scripts run. You can read about it here: https://panopticlick.eff.org/. Hence it's generally better to not send data to 3rd parties, than to rely on that they can't identify who is sending the data. But I definitely agree that we should keep in mind the option of keeping the original flow, but not sending user-identifying information in step 3. >>> 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. If it turns out that I'm the only person worried about this privacy leak, then we should absolutely go with the current API. I mostly started this thread to get input from the security and privacy teams to see if this was something that worried them. If it doesn't, then we shouldn't let this issue block us. / Jonas _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
