On Thu, Aug 16, 2012 at 7:52 AM, Fernando Jiménez <[email protected]> wrote: >> 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.
Well, if the signature doesn't match, which is the only part that we can't verify in Gaia, then the user will get a message saying that the payment request was invalid. So no need to compare anything, the user's money should never have been at risk. >> 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. >> 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. >> 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. / Jonas _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
