Author: Scott Gruby

Anyone that reads my blog or talks to me professionally knows how much I hate dislike asynchronous network programming. While working on rewriting some networking code, I came across a few more reasons why synchronous networking is a poor decision.

The first issue occurs when a developer abstracts the networking, then forgets that when the call is invoked, it actually makes a network call and does it on the main thread. Synchronous networking should never be done on the main thread. For instance, let us use the following made up example:

- (void) displayUserPreferences
{
	Preferences *prefs = [[Utility sharedInstance] getPreferences];
	if (prefs)
	{
		// Update the user interface
	}
}

- (Preferences *) getPreferences
{
	NSDictionary *dict = nil;
	NSData *result = [Networking queryPreferences];
	if (result)
	{
		dict = [self parseData:result];
	}

	return dict;
}

+ (NSData *) queryPreferences
{
	return [NSURLConnection sendSynchronousRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.something.com/data.json"] returningResponse:nil error:nil];
}

In order to not block the main thread, the developer has to always make sure that displayUserPreferences is called on a secondary thread. While this may sound simple, forgetting to do this is quite easy especially for a developer that didn’t initially write the code. Another developer might think that getPreferences is a local call and doesn’t hit the network and therefore call displayUserPreferences on the main thread. This is, of course, a recipe for disaster.

The second issue isn’t specific to networking, but has to do with threading. In the above example, the “Update the user interface” code under the comment must run on the main thread as user interface calls can/will crash when run on secondary threads. It is far too easy to forget to use performSelectorOnMainThread to run the code on the main thread. Having to keep track of what can and can’t run on a secondary thread just adds confusion and inevitably will lead to mistakes. A simple call like:

[self.tableView reloadData];

run on the secondary thread for networking will cause a crash.

I’ve seen both of these issues in code and there really is no excuse for being lazy in writing networking code. Once you write a good networking class, it can be reused over and over; I’ve used a networking class I wrote a few months ago in 4 or 5 different projects. I wrote it once; tested it extensively and now reusing it is quite simple.

I’m tempted to file a radar bug to ask Apple to deprecate the synchronous call, but I know that they won’t do it. The synchronous networking call screams lazy and should be avoided in my opinion.

When I read a post that John Gruber wrote today about OAuth in native Twitter apps and how much of a poor user experience it is/will be, I had to dig deeper into the article. On first read of the article, I disagreed with him as I thought he missed a very important point about security, but upon re-reading it, he did identify one of the major issues with how OAuth (and other types of service authentication) is done on iOS, in particular.

Developers can alleviate some of the context switching by using an embedded web view inside their native app for the OAuth authentication handshake, but at that point, why not just use xAuth and simply allow the user to enter their username and password in a native dialog box? So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth…

This is something that most users are unaware of when entering their credentials in any iOS app. As long as you are in the app, even if the page says Facebook, Twitter, Dropbox, etc. and you’re not running an app from these companies, the app can capture your username and password. Some companies ship their libraries to developers in a form that doesn’t let the developer modify the source code, but that offers zero protection from a malicious developer that wants to steal usernames and passwords.

I’ve seen one application launch Safari, ask you to login to Facebook and when done, returns you to the app. From a security point of view, this is the ONLY way to ensure that the application doesn’t capture your credentials (provided that you trust that Safari isn’t stealing your credentials). Any embedded web view offers no guarantee that the app isn’t hijacking your credentials as the app can walk the hierarchy of views and grab info; in a kiosk I worked on, we presented web pages, but I modified the web pages before displaying to change the credit card field to a password field to mask the numbers; this type of modification of web data is quite easy when a developer controls the entire app.

Should you be worried? That all depends. Do you use different passwords for every service? If not, consider using 1Passwd. Yes, it may be a pain to enter the random password on a mobile device, but if some app got access to the password you use on all your sites, the risk is great. Are most developers honest? Yes, but bugs in the code could put your password at risk. Also when I tried out apps for Google Voice, I had some strange feelings about an app, so I ran my iPhone’s networking through Charles Proxy to see where the app was connecting; it was connecting to a site that wasn’t Google. I had no idea if my Google Voice password (which is my Google password for email) was going to some lone developer’s server. Based on the developer’s posting in various forums, I didn’t trust his app with my password.

Should users be inconvenienced by having an app launch Safari, enter credentials and then go back to the app? Personally, as someone a bit paranoid about security, I think it is worth the one time inconvenience (per app). The average user may not think this way. However, if the user was better educated in the app indicating that for security purposes Safari will be launched, that may mitigate the issue.