Exposure (iPhone app) behaves suspiciously

Exposure uses an embedded browser for Flickr authentication - but as a result there's no way for me to check that it's actually sent me to the real Yahoo! sign-in page! Mobile Fotos launches Mobile Safari instead, which is a bit clunkier but much better from a security point of view.

To take full advantage of Flickr, you should use a JavaScript-enabled browser and
install the latest version of the Macromedia Flash Player.

Comments

Gulopine says:

And here, I also thought the iPhone SDK license prevented apps from bundling their own browsers. Something about apps downloading code from the internet that gets interpreted on the phone. Suspicious, indeed.
Posted 15 months ago. ( permalink )

Seldo says:

It's not bundling its own browser, as far as I understand: it's just using Safari as an embedded object rather than as a separate app.
Posted 15 months ago. ( permalink )

Ben Ward says:

AirMe does this too. It seems like a huge potential problem.

The Pownce application is a fine example of how to do this sort of auth correctly (using OAuth). We need to promote its method better.

The Pownce app invokes MobileSafari at the auth URL, so everything happens inside the browser (existing login sessions are maintained, URL is visible).

The Pownce app then uses a ‘pownce://’ pseudo-protocol as the callback URL for its original auth request. OSX allows applications to register themselves as protocol handlers, so MobileSafari callsback to ‘pownce://somethingblah’, which invokes the Pownce app again. It's slick, no manual intervention by the user and the fact the Pownce app quits in the background is never exposed to the user.

Everyone iPhone app should handle auth this way, and I'm sort of leaning toward the idea that apps should be barred from putting this sort of authentication into their internal browser.
Posted 15 months ago. ( permalink )

raminf says:

Sorry, but I very much prefer the embedded web page approach. Sending a user off to another app, then back again makes for a jarring user-experience. The UIWebView *is* an instance of the browser and the page you see is what Flickr (or any other OAuth-compliant service) says you should be going to. Makes no difference whether it's in a single-pane window or the full web-browser.

If your concern is a mis-behaved application sending you off to a phishing site it can just as easily happen in the webView as MobileSafari, since you are being sent to a specific URL dictated by the server. If you're paranoid about that, then you'll want to route your iPhone WiFi through a proxy-server and watch where it's sending the requests.

The Pownce protocol handler trick is interesting, but it forces every OAuth client to add a URL registry entry into the system protocol handler space. Not terribly scalable and a potential point of name conflict as more apps come onto the market.

Personally, I think the OAuth folks should revise the spec to extend the mobile profile to devices that can have embedded webviews. While at it, it would be nice if they came up with a way for apps to customize the look and feel of the server auth page so it better fits into the application UI.
Posted 15 months ago. ( permalink )

Ben Ward says:

raminf:

Yes, a UIWebView can be integrated into your app more cleanly than invoking MobileSafari, but total integration between app and service is not the design goal of OAuth (or any such system). In fact, the whole point is that you grant 3rd party permission to use a service from that service itself, and not within the third party application. The move from the application to the service and back again is an integral part of a user understanding of what is going on. Otherwise we're no better off than just entering the password into a third party website.

As in the screengrab, there is no way to know that the Yahoo! authentication page is legitimate. There is no URL bar, and even if there was, it could be faked because it's not a web browser. You could very very easily make an app that presented a clone of the Yahoo page and stole a YID and password.

The danger to users from abuse massively outweights the tiny improvement in user experience. In fact, I'm unconvinced that it's an improvement in user experience at all.

Here's how I see it: The Pownce method is better for the user because it moves them from the third party app in which they have only limited trust, and moves them to the browser environment in which they have full trust. They have confirmation of HTTPS. They can inspect the URL. They have the functionality of the real site itself.

Users should never, ever enter their username and password into a system which they do not trust, and you should not ask them to. It's horribly irresponsible.

Even if your app is displaying the content directly from the third party site, the user doesn't understand that. They shouldn't need to. End of the day, they're not being presented with their web browser, yet they're still being asked for their password. Building a culture where people enter their password into 3rd party systems — regardless of the technical implementation — is no better than Facebook/Plaxo etc. asking for your Google/Yahoo password on their website.

Additionally, I think the URL handler implementation is perfectly scalable. Just pseudo-namespace your handler. Adopt ‘com-pownce-iphone-app://’ rather than ‘pownce://’ using your own domain (the same pattern as OSX preference files), then conflicts are a non-issue. These are not handlers for users. Heck, you could generate a GUID or random number for uniqueness.
Posted 15 months ago. ( permalink )

Simon Willison says:

Just tried out the Pownce app and it does get it exactly right - the iPhone handles the transitions between applications extremely well, so it's clear that you are moving from an application to Mobile Safari and then back again - all without disrupting the user flow.

If OAuth encourages applications to embed it in a UIWebView or similar then the entire point of it existing is lost - we may as well just go back to applications asking for usernames and passwords directly.
Posted 15 months ago. ( permalink )

fraserspeirs says:

Hi Simon, I'm the developer of Exposure.

Thanks for bringing this up. I went back and forth on this from a user experience point of view and ended up with the design that I have now. From my experience developing FlickrExport, I knew that the browser-based authentication was by far the most problematic part of the user experience.

Is there anything that Exposure could do in its current implementation that would make you feel better, or do you see the browser as the only app on the phone that can truly be trusted?

Again, thanks for your thoughts.

Best,
Fraser
Posted 15 months ago. ( permalink )

raminf says:

I guess we come at it from different angles. To me, the 'pop out to browser' scheme (popularized by Flickr API and now part of OAuth) is suitable for browser-based apps not desktop apps. It all feels like an artifact of the days when the standalone browser was all there was.

But I can understand the wish not to let any old third-party app have access to the username/password. I just don't think relying on the jump to browser as a way to thwart malicious third-parties buys anything.

On the iPhone, unlike the desktop, once a page is loaded, the whole URL field (name, lock and all) scrolls up and away with the content. So now the user has to be trained to not only break away from their app and into a browser, but to wait until the page is loaded, then scroll up to the top to verify that the domain suffix is something similar to the service. All this so they can go look at pretty pictures on their phone!

To be truly safe, you need something like an app certification system, with public/private key exchanges, app-signing etc. At that point, the server could treat the app like a trusted access point and let them ask the user for username/password info to pass along with the request. It's more hassle for the API provider, but it makes for a much smoother user-experience.

As with most of these issues, it's probably best for the app not to make a policy decision, but to give the end-user the choice of using the embedded browser or jumping out to MobileSafari. That makes for very little code change and keeps everyone happy.
Posted 15 months ago. ( permalink )

Simon Willison says:

fraserspeirs - unfortunately it absolutely has to be the browser. I personally didn't find the Pownce flow intrusive at all, but if you look at the reviews of the Pownce app on the App Store three out of four are complaining about the browser authentication step.

This is the problem with phishing: it's the ultimate place where security features needing to trump user experience, and users hate (and/or ignore) any protections that are put in place. I know user education never actually works, but if we don't educate people they'll never be able to safely use the applications we develop, so I feel we have to try and educate anyway.
Posted 15 months ago. ( permalink )

Simon Willison says:

raminf: I agree that Mobile Safari certainly isn't ideal from an anti-phishing perspective. Apple have traditionally been bad at this - Safari on the desktop frequently hides the status bar, for example. At least it gives people a fighting chance though.

I don't agree that giving the user a choice is the way to go. If you ask most people if they want to use an "embedded browser" they won't have the slightest idea what you mean - and those are the people most likely to be caught out by a phishing attack.
Posted 15 months ago. ( permalink )

LukeRedpath says:

I'm not convinced this is that big a deal; see my response here:
lukeredpath.co.uk/2008/8/12/on-iphones-and-us er-credentials
Posted 15 months ago. ( permalink )

liminalists says:

This is definitely a big deal; if you enter your Flickr (re: Yahoo) username and password into an "embedded browser", there's absolutely nothing to stop the developer of that application from storing and transmitting those credentials to themselves or any other 3rd party.

In the case of Yahoo / Google credentials, this is a huge deal because it means that Exposure or whatever other application now has access to your email.

The OAuth approach, combined with the interaction built into the Pownce application, means that the user can trust that the application / developer can only access content that they've specifically been given permission to.

Fraser, raminf, Luke: I'm willing to bet that if an application showed you that it has access to your password, you'd be less inclined to use that application than one you know can't possibly have your password. If that's the case, why ignore the facts?
Posted 15 months ago. ( permalink )

LukeRedpath says:

"if you enter your Flickr (re: Yahoo) username and password into an "embedded browser", there's absolutely nothing to stop the developer of that application from storing and transmitting those credentials to themselves or any other 3rd party."

And the same applies if the app developer is using native widgets to construct a login screen, yet I don't see anybody making a lot of fuss over this.

As I said on my blog, passing the user over to another provider to login simply shifts the burden of trust. It is equally a users responsibility to make sure they only use their credentials with apps by trusted third parties.

The bottom line is that on the iPhone, having to leave the app and go to another one just to login stinks. To the average (non-techie) user, OAuth is meaningless. They just don't care. They just want to log in (and lets remember we're not exactly talking about internet banking accounts here).
Posted 15 months ago. ( permalink )

Simon Willison says:

"And the same applies if the app developer is using native widgets to construct a login screen, yet I don't see anybody making a lot of fuss over this."

I'll happily make a fuss about it. If an application asks for my username and password but I know that the relevant site offers an OAuth-style API I will complain loudly and refuse to use that application - just like I do when a site asks for my webmail password so it can import my contacts (Google, Yahoo! and Microsoft all offer OAuth-style APIs for the address book now).

"They just want to log in (and lets remember we're not exactly talking about internet banking accounts here)."

My Flickr account is my Yahoo! account. If I use Yahoo! Mail, it's my e-mail account. If it's my e-mail account, it's Single Sign On for basically everything I use online thanks to forgotten password e-mails. It may not be an internet banking account but it's only one step down.
Posted 15 months ago. ( permalink )

fraserspeirs says:

Hi Simon,

Just wanted to follow up with you on this. Exposure 1.2 will use Mobile Safari for authentication. 1.1 is just about to go to the App Store.

Best,
Fraser (Exposure dev)
Posted 14 months ago. ( permalink )

Ben Ward says:

Fraser, that's fantastic news! Thank you.
Posted 14 months ago. ( permalink )

Would you like to comment?

[?]

	Simon Willison's photostream
		3,077 uploads

This photo also belongs to:

	Most Interesting (Set)
		100 items

4 people call this photo a favorite

Additional Information

Taken with an Apple iPhone.
More properties
Taken on August 11, 2008
Viewed 2,739 times

Add to your map

Yay location removed

...

(Some formats are OK.)

Or, remove it from the map.

Go to the map

You	Sign in \| Create Your Free Account
Explore	Places \| Last 7 Days \| This Month \| Popular Tags \| The Commons \| Creative Commons \| Search
Help	Community Guidelines \| The Help Forum \| FAQ \| Sitemap \| Get Help

Exposure (iPhone app) behaves suspiciously

Comments

Gulopine says:

Seldo says:

Ben Ward says:

raminf says:

Ben Ward says:

Simon Willison says:

fraserspeirs says:

raminf says:

Simon Willison says:

Simon Willison says:

LukeRedpath says:

liminalists says:

LukeRedpath says:

Simon Willison says:

fraserspeirs says:

Ben Ward says:

Would you like to comment?

Simon Willison's photostream

Most Interesting (Set)

Tags

Additional Information