[pay UI] Paypal login cannot be assured to be from paypal

[Stuart Langridge]

When paying for an app with Paypal, the Paypal login screen is presented in an Ubuntu wrapper. There is no indication on this page that I'm actually looking at paypal.com rather than being phished or that some bad DNS has pointed me to a wrong site. The padlock in the top corner doesn't indicate anything I'm inclined to believe -- is it showing that the connection is https? Has it verified that I'm really talking to Paypal? How can I know that? This is encouraging people to type their Paypal password into phishing sites. The previous step in the purchase process, where I'm choosing which payment system to use, also displays a padlock, and that hasn't connected to any payment site at all.

[Alejandro J. Cura (alecu)]

I think this is a valid concern.

Anyway, the info shown by the padlock bubble should be the same as what the browser shows when visiting the same page. Would showing extra info there provide more assurance?

Perhaps opening the browser instead to complete the payment is a better solution?

[Jamie Strandboge (jdstrand)]

Paypal uses an EV cert so we should be indicating it is EV in addition to a lock. For example, compare these in firefox or chromium:
- https://wiki.ubuntu.com/ (valid, non EV)
- https://www.paypal.com/ (valid, EV)

We of course should be failing for self-signed or invalid.

[Jamie Strandboge (jdstrand)]

On the other hand, so long as we fail hard in the case of invalid SSL (and implement verification correctly!), because this is a specialized app that uses a hardcoded URL, one could argue there is no need to show anything extra. If a lock would provide more user assurance, then perhaps make it a green lock. As such, feel free to take comment #3 under advisement if implementing this, but I'll soften my stance and say it is not a requirement.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stuart Langridge (sil)]

@jdstrand: I may have not explained this ideally. Yes, EV certs will protect us if your router is trying to lie to you about where paypal.com is, but they don't help at all if my app shows something which looks like the trust-store dialog but actually isn't. Users will then type their Ubuntu One password into it, which we don't want them to do, but there's no way of telling whether something that looks like a secure OS-presented dialog actually *is* that secure OS-presented dialog.

[Olivier Tilloy (osomon)]

Closing the webbrowser-app task, it’s already doing the right thing wrt certificates (minus differentiating EV certificates, which is bug #1402725).

[dobey (dobey)]

@sil I don't think there will ever be any way to guarantee that. Any UI that appears on the screen can be replicated, so there is no way we can place something in that UI itself, which could not be replicated. Not even 2FA will protect against that, as any 'fake' UI could also just as easily respond to a 2FA request and have you enter the code.

I guess we should close this as invalid, or mark it as a duplicate of bug #1402725 for the EV cert handling?