Hi, On 16/08/2012, at 13:41, Jonas Sicking wrote:
> 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? Yes, we do have that freedom. That's why I was also giving the solution of imposing some mandatory JWT parameters (IMO at least product price and description). > 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. Indeed. The final payment provider screen would contain the "real" information about the current digital good being sold, so the user can compare with the information not verified but showed by Gecko in the previous step. > 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? Sorry, I was referring to step 6 of your proposal. As I said, IMHO where to ask for a user login should be up to the payment provider. It shouldn't be Gaia loading the payment provider login screen, but the payment flow (that would contain the login screen) in general. > 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. Well, we would keep the original flow with the addition of a confirmation screen shown by Gecko. > 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. Actually, you are not the only one, as I am also concerned about this matter, that I must confess that I didn't think about until you mentioned. I still think that this is mostly a payment provider identity protocol issue, but I agree that Gecko should probably ask for user's confirmation before sending any users data ,even if he authorized the payment provider to automatically log him in. Anyway, even if we want to implement this, it may not a be a reason to block the basic parts of the implementation. But that's not my decision at all :) I just need confirmation to start developing the fix for this, that I repeat, should not be hard to implement. Thanks for your help Jonas! -Fernando _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
