Developer Warns Against Using In-App Browsers on iOS Due to Potential for Keylogging

[redscull]

As a developer because we care about the end user experience and it's nicer than bouncing between apps all the time.

I don't see any issue, why would you even download an app from a developer/company you didn't trust.

I am also a developer, one with a long history focused on user experience. I would rather bounce around apps. That is in fact exactly how they were intended to be utilized. Apps load up extremely quickly and do their one main job really well. The in-app browsing experience is inferior to using Safari, and I don't like being subjected to an inferior browsing experience.

I downloaded Facebook. I use Facebook. I wouldn't trust Facebook with my world, but I trust them enough to utilize Facebook's functionality. I hate Facebook's in-app browser. They can log which links I click from within their app; that's fair. But they're over-reaching when they insert themselves into my entire subsequent browsing experience. They have no business knowing if I click ads on the site reached via their link or how long I stay there or what else I click through to or what I might buy or type.

Furthermore, the in-app browsing experience is poorer than what Safari offers. I don't have access to my other tabs or as much screen real estate or any other normal functionality I want and am used to having when I'm browsing. I hate the double back arrows in particular (one is navigation back, one is back to Facebook). That is far more obnoxious than just multi-tasking or home-icon-clicking back to Facebook when I'm done browsing.

Your job as an app developer is to make focused, awesome apps. If your app isn't a browser, don't put a browser in it. Not unless you're committed to your in-app browser being fully as great as Safari. This is the same mindset for using the new extensions functionality in iOS 8. You can off-load tasks to those apps which excel at them so you can focus on your own, making it leaner, faster, and less complex.

If your normal user's workflow involves linking to websites merely to quickly glimpse something before returning to your app and its tasks, and you're convinced that they aren't truly transitioning to a web browsing mindset, I can see why you feel that app-hopping is the wrong approach. But the solution you've provided isn't right either. If their need to view external content is so minimal, you should simply load that content for them in a manner which doesn't imply they've launched an integrated browser. Specifically, they shouldn't be able to freely navigate around the entire web (nor do they even want to according to your use-case). You may be doing this, so kudos, but Facebook is an example of doing it wrong; their links truly are external content, not part of Facebook.

 

[jennyp]

How can anyone trust Agile to store the passwords but not the in-app browser? If Agile wants your passwords, it certainly doesn't have to grab them via the browser.

And - surely - it can't grab them from the app, either, since your encrypted "one" password never leaves the app ?

 

[philosopherdog]

Is it really news that devs could grab login credentials? Isn't that why apple does a code review before approving apps. Are there any examples if this on the ios side in the wild. There certainly are examples on the android side.

 

[AGKyle]

Is it really news that devs could grab login credentials? Isn't that why apple does a code review before approving apps. Are there any examples if this on the ios side in the wild. There certainly are examples on the android side.

Apple doesn't do a code review. They do a general purpose review to make sure the app runs, isn't using code it shouldn't and it doesn't try to do things that they do not allow.

Developers do not give their code to Apple, they give them a binary that runs and Apple does a review of that. You just have to trust the developer to do the right thing. As indicated in the original article, this is not a bug, it's a conscious choice by Apple to allow developers to do this so that they can use it to improve user experience.

 

[PsykX]

Thanks for stating the obvious, Craig.

Thats why you only download browsers from reputable companies.

That has nothing to do with where your browsers come from.
It has to do with in-app 3rd-party browsers (even those using WebKit), i.e. Facebook has an in-app browser and what he says is you should never use it to login anywhere.

I must admit that I never considered this point...

 

[coolfactor]

Doesn't that mean this has been around for a long time already, then? Is it really an issue?

My thinking, too. Why is this being reported now, just after the release of iOS 8? Coincidence or carefully timed?

----------

I am also a developer, one with a long history focused on user experience. I would rather bounce around apps. That is in fact exactly how they were intended to be utilized. Apps load up extremely quickly and do their one main job really well. The in-app browsing experience is inferior to using Safari, and I don't like being subjected to an inferior browsing experience.

I agree with everything you've said. It always throws me off when I tap a link within the Facebook app and it loads up a crippled web view. I was expecting to be taken to Safari. Maybe this can be made configurable. Give the users the choice.

 

[Manderby]

Why do you need a custom WebView for this? Here, try it out using your original Safari:

EDIT: Link deleted. For reasons.

Took me half an hour to do something like that. Yes, this is not the same, as it is basically phishing by giving the users the false impression of having just the original website in front of you, while in the background, there is another site gathering all your data, I could even store your mouse movements! As long as no one looks at the web address, you can fool lots of users.

Yes, it is not perfect, but you get the general idea.

 

[Kissaragi]

Dear mr Craig Hockenberry,
I trust Agile bits completely when using 1passwords built in browser and I'm not worried about someone finding I've looked up a chicken curry in paprika. Please try a different tactic when your looking for free advertising for your app in future.

Yours sincerely, K

 

[Dinø]

As a developer because we care about the end user experience and it's nicer than bouncing between apps all the time.

I don't see any issue, why would you even download an app from a developer/company you didn't trust.

If you were a developer, you would realize that the in app browser doesn't share any session data with the real browser. You are guaranteeing that the user will have to type in his userid and password. They might already have an active session in the standalone Safari app.

 

[jtara]

It's a rather silly argument/warning.

OF COURSE any app has access to whatever you type into that app! Sheesh! Users should be aware of this.

This warning might cause users to avoid so-called "hybrid" apps, which use a UIWebView embedded in the app so that the UI can be created using HTML. There's no reason to avoid such apps, nor to avoid apps that have in-app browsing.

I think it is important, though, that apps that provide some ability to log-in to a third-party site (often as part of some authorization for the app to be able to work with some third-party site's API) that the app should always open that page in Safari, so that there is no possibility of the app capturing the data.

Usually, when the purpose is to authenticate an API user, the site will have a means of redirecting the user after the authentication. You can usually use this redirect to get the user from Safari back to your app. (By using special URL prefix available in each mobile OS.)

As well, I prefer not to have an in-app browser ever open a third-party site, period. For one, it is too easy for the third-party site to "hijack" the app and make it impossible for the user to return to the app's internal pages. While it's bad for stickiness to lose a website user this way, it's worse for an app.

 

[larrylaffer]

This whole idea assumes that Apple's app review process wouldn't catch this.

Just sayin'.

 

[sjinsjca]

Is this specific to iOS 8 or iOS for that matter? If not why is this a story?

No. Key logging a risk with any browser or app that includes a browser, or in fact any app that takes keyboard input in any fashion for any reason. Since browsers are used for logging into secure online services, they're of particular concern. As are browser extensions.

The same issue potentially applies to any computing device, not just iPhones and not just phones for that matter. Key loggers are very common on personal computers; besides malware containing that functionality, employers regularly install them to monitor employee behavior (or, more often, to get the goods on an employee after a termination decision has been made, in order to reduce severance costs).

Jeez, people, calm down. Not only is this nothing new, it's not iPhone-related, not Apple related, not phone-related... egad.

 

[japanime]

I am also a developer, one with a long history focused on user experience. I would rather bounce around apps. That is in fact exactly how they were intended to be utilized. Apps load up extremely quickly and do their one main job really well. The in-app browsing experience is inferior to using Safari, and I don't like being subjected to an inferior browsing experience.

I downloaded Facebook. I use Facebook. I wouldn't trust Facebook with my world, but I trust them enough to utilize Facebook's functionality. I hate Facebook's in-app browser. They can log which links I click from within their app; that's fair. But they're over-reaching when they insert themselves into my entire subsequent browsing experience. They have no business knowing if I click ads on the site reached via their link or how long I stay there or what else I click through to or what I might buy or type.

Furthermore, the in-app browsing experience is poorer than what Safari offers. I don't have access to my other tabs or as much screen real estate or any other normal functionality I want and am used to having when I'm browsing. I hate the double back arrows in particular (one is navigation back, one is back to Facebook). That is far more obnoxious than just multi-tasking or home-icon-clicking back to Facebook when I'm done browsing.

Your job as an app developer is to make focused, awesome apps. If your app isn't a browser, don't put a browser in it. Not unless you're committed to your in-app browser being fully as great as Safari. This is the same mindset for using the new extensions functionality in iOS 8. You can off-load tasks to those apps which excel at them so you can focus on your own, making it leaner, faster, and less complex.

If your normal user's workflow involves linking to websites merely to quickly glimpse something before returning to your app and its tasks, and you're convinced that they aren't truly transitioning to a web browsing mindset, I can see why you feel that app-hopping is the wrong approach. But the solution you've provided isn't right either. If their need to view external content is so minimal, you should simply load that content for them in a manner which doesn't imply they've launched an integrated browser. Specifically, they shouldn't be able to freely navigate around the entire web (nor do they even want to according to your use-case). You may be doing this, so kudos, but Facebook is an example of doing it wrong; their links truly are external content, not part of Facebook.

Yours is one of the better posts I've ever read on Macrumors. This is the way all developers should think.

As a potential customer, I'd be interested in seeing a list of some of the apps you've developed. (Maybe add a link to your signature?)

 

[macfoxpro]

Well one more risk![/QUOTE

Don't know much about "in-app browsers" but I have a killer Meatloaf recipe.

1 pound ground turkey
3/4 cup fresh bread crumbs (from 2 slices light whole-wheat bread)
1/2 cup finely chopped Vidalia or other sweet onions
1/3 cup grated carrot
1/4 cup 1% milk
1/4 cup tomato sauce
1 large egg, lightly beaten
1 garlic clove, finely chopped
1 tablespoon Worcestershire sauce
3/4 teaspoon salt
1/4 teaspoon freshly ground black pepper
Topping
2 tablespoons ketchup
2 teaspoons light brown sugar
1 teaspoon yellow mustard
preparation

1. Preheat the oven to 375°F. Line a rimmed baking sheet with foil.

2. To make the meat loaf: In a large bowl, combine the turkey, bread crumbs, onions, carrot, milk, tomato sauce, egg, garlic, Worcestershire sauce, salt, and pepper. Mix gently but thoroughly. Mound the meat loaf mixture onto the prepared baking sheet, patting it into a loaf shape with your hands.

3. To make the topping: In a small bowl, combine the ketchup, brown sugar, and mustard. Spoon the topping over the meat loaf, using the back of the spoon to spread it evenly.

4. Bake the meat loaf for about 45 minutes, or until the meat is no longer pink on the inside and is cooked through (165°F on an instant-read thermometer). Let it sit for 5 minutes, then slice and serve.

 

[indiekiduk]

I heard that Apple have already began rejecting apps that try to do Oauth logins via in-app web browsers, i.e. UIWebView. Since a few developers weren't aware of the security flaw Apple had to add a rule. It's a bit of extra effort, and not the best end-user experience, but you just need to switch to safari, do the oath and make it switch back to your app, which it can do automatically with a bit of effort.

 

[lookatchu]

Pardon my confusion, but are bank apps, i.e. Bank of America, considered in-app browsers ? Or, are "in-app browsers" only apps that have a link within the app that opens up Safari?

 

[jtara]

Pardon my confusion, but are bank apps, i.e. Bank of America, considered in-app browsers ? Or, are "in-app browsers" only apps that have a link within the app that opens up Safari?

Is the bank going to steal your bank credentials?

Puzzled look...

This issue has NOTHING to do with embedded web browsers!

The danger is with ANY app that asks you to fill-in your user ID/password for some other app or site. e.g. how many apps ask you to enter your Facebook login/password? Plenty. And how many *should* there be? None.

Or, are "in-app browsers" only apps that have a link within the app that opens up Safari?

That is *not* an in-app browser. That's Safari.

 

[lookatchu]

Is the bank going to steal your bank credentials?

Puzzled look...

This issue has NOTHING to do with embedded web browsers!

The danger is with ANY app that asks you to fill-in your user ID/password for some other app or site. e.g. how many apps ask you to enter your Facebook login/password? Plenty. And how many *should* there be? None.

Thanks for the explanation.

 

[JackANSI]

Since when is this news? This has been around since at least iOS 5 i think.

 

[genovelle]

It's quite simple. Use a browser made by Google for sensitive data. Don't use one made by John Nobody for that kind of stuff.

Kinda sad you had to ask actually.

You mean Google, the company that my hospital had to go to great measures to keep chrome off their computers because it downloads a server that runs in the background doing who knows what and transmitting data off site. Not what I would call good for sensitive data. Look up the execs comments on privacy and security and I doubt you would select them to manage you personal data.

 

[lk400]

Financially they won't take much of a hit (although AAPL is kind of a separate thing). But what's more valuable than Apple's pile of cash? Their brand. And that is taking a pretty good beating in recent weeks, from the leaked iCloud accounts, the botched keynote video live stream, Tim Cook's awkward moment with Bono that makes them look old and uncool even to old people, the free U2 album download that no one wanted forced on them, the horrendous iPhone 6 preorder fiasco, various iPhone 6 issues, many annoying iOS 8.0 issues (including all HealthKit apps getting pulled from the App Store), to todays botched 8.0.1 "fix" that disables the primary communication stream of iPhones. I mean they will get through it, but it's been kind of rough.

Did you just value the Apple brand? What number did you come up with?

 

[skinned66]

The key phrase for this exploit is "unscrupulous developer."

I'm not concerned in the slightest. Still, information of this type is good to spread around.

I expect zero changes to be made to iOS as a result of this. Stick to reputable app developers and you'll be just fine using in-app browsing.

I used the 1Password browser fairly often - now I have extensions

 

[Yvan256]

As opposed to who? Why don't you tell us our alternatives?

That's what I thought.

Funny how you ask me a question, immediately followed by "That's what I thought".

What was I supposed to do? Insert my reply into your own comment before you clicked "submit"?

Doesn't matter who the alternatives are, with Google we are the product, privacy be damned.

At this point, I trust Apple and Microsoft a hundred times more than Google.

 

[catplusplus]

Apps can get keystrokes typed into the app

I think most people get the idea. For the ones who don't, education is important. So is deletion from various app stores. In-app browsers have little to do with it, any username/password UI can get and potentially misuse your credentials.

 

[sgibson]

I think everyone is missing Craig's point here.

Twitterific has, up until now, switched you to Safari to authenticate with Twitter, then switched back to Twitterific once authenticated. This means that the app itself never has any access to, or ability to record, what you enter on twitter.com

With the latest version of the app, Apple *rejected* it for doing this, forcing them to move to an in-app browser for authentication.

Developers that care about user privacy and security want as little information as possible. Even if they *know* they aren't tracking user keystrokes when entering passwords, they'd rather be completely out of the equation anyway because they don't want to contribute to user thinking that behaviour is ok.

The use of in-app browsers normalises the practise of entering sensitive details in apps that you may not trust to the same level as Safari. It would be trivial to create an app that quietly harvests Twitter or Facebook login details and sends them to a shady third party who can then use those same passwords to attempt to sign in on, for instance, your bank or other account (because people still reuse passwords).

What Craig is saying is that the behaviour Apple's review has forced on them is less secure and leads to people not thinking about this vulnerability. They are encouraging the less secure behaviour when what they should really be doing is forcing developers to go the other way. If you use a web-based login system, like OAuth, to connect your app to a third party service, the app should be rejected *because* an in-app browser, since you can't trust it as implicitly as Safari. Round tripping to Safari should be the required behaviour, not a reason for rejection.