On 17/08/2012, at 02:15, Jonas Sicking wrote: >>> 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. > > Then I'm not really following what you were saying. The user > experience in my proposal is eactly the same as the user experience in > the original flow once the user has chosen BlueVia as payment > provider.
Ok, then I guess you were considering the login step as part of the whole payment flow hosted by the payment provider. I was afraid that you were proposing an extra step that require Gecko to confirm that the user is logged in the payment provider before sending the JWT. (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.). >>> 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. > > Note that I'm not proposing an additional confirmation by Gecko. I'm > proposing that we replace the confirmation UI displayed by BlueVia in > step 3 of the original flow, with a confirmation UI displayed by > Gecko. So from the user's point of view it's almost exactly the same > behavior. I am afraid that, for legal reasons, that would probably not be possible. If I am not wrong, the payment provider is forced to show the payment information and ask the user for confirmation. Ernesto, can you confirm on this, please? If I am not wrong with this assumption, we would be facing at least two confirmation steps (and probably an additional one on the application side, but that's something we cannot control). >>> 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. > > Sounds good! Let me know if you have any questions. I'll try to be > available late tonight again so that we can rip through any questions > quickly. Great. Thanks Jonas! Also, if you consider that any other change is required, please let me know. Cheers! -Fernando _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
