Google's Android vs. Apple's iPhone: Which is More Secure?

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

I’m going to go out on a limb here and predict Google’s Android mobile phone platform is going to prove itself to be more secure than Apple’s iPhone in the long run. Let’s take a closer look.

But first, I have to explain the basis for this preliminary comparison—Android handsets, after all, are not yet shipping, while we all know the iPhone is readily available in several parts of the world. Comparing them now really is a case of comparing apples and oranges, no pun intended. So that really just leaves me with having to compare them via their design features and user reports.

Further, Android’s design is open to scrutiny, while iPhone’s inner workings are closed and proprietary. That said, much has been written about both, and I’m going to base my comparison on what I’ve been able to find publicly documented, except where otherwise noted.

So, with that pretty significant set of caveats out of the way, let’s dive in.

• Application security architecture. This is a biggie for both systems. The iPhone applications appear to all run with root (administrative) privileges on a single UNIX kernel. That means that if one application fails, the entire system can trivially be compromised. On the other hand, Apple has thus far kept the system locked from the standpoint of adding new software. (I’ll address their newly announced SDK below.) On the other other hand, each release of the iPhone firmware to date has had at least one defect in it enabling the underground community to add their own software to the device, pretty much with impunity. Not exactly a stellar track record, particularly for a device that’s just a few months old.

Now, looking at the security of Android’s application platform, it’s obvious they’ve thought long and hard about how to do this. Their architectural documents clearly say, “Each Android package (.apk) file installed on the device is given its own unique Linux user ID, creating a sandbox for it and preventing it from touching other applications (or other applications from touching it). This user ID is assigned to it when the application is installed on the device, and generally remains constant for the duration of its life on that device.” Further, each package includes an XML configuration document (AndroidManifest.xml) that pre-defines the permissions and authorizations for each package. This provides a policy jail that each application runs inside. That’s a pretty powerful model.

On the other hand, defining the permissions in an application’s AndroidManifest.xm file is discretionary, and a user could no doubt be duped into giving a malicious application a dangerous set of privileges. We’ve seen how discretionary controls like this can fail in spectacular ways when left to the decision of the end user. Furthermore, these security features are really there to benefit those who play by the rules, and we know by now that’s not how the Bad Guys play. Still, it does provide a level of control and, more importantly, separation between all the applications on the device that the iPhone doesn’t even begin to address.

Qualitative score: Android gets an A- while iPhone gets an F (F-, if that’s possible).

• Openness. We’ve heard claims for many years that open source software is more/less secure than its closed counterparts. What’s more, we’ve seen those claims pretty thoroughly debunked in various studies comparing the two worlds. But this is different. In Google’s Open Handset Alliance, we see numerous big commercial entities participating, and they have significant commercial interests in ensuring the security of the end products they ship.

I’d venture to bet Android’s design and source code will receive more security scrutiny than most (all?) other open source projects. By comparison, only Apple’s Darwin kernel is available for public scrutiny, and there really isn’t much of an external community with massive commercial interests in reviewing its security.

And there’s more to “openness” than just accessibility of a product’s source code. The Android team has clearly documented the process for developing and installing applications for Android, including how to interface with the underlying security framework. That openness has already resulted in at least one product vendor announcing it will be developing security applications—firewall, anti-spam, anti-malware, etc—for the platform.

Maybe I’m totally off base here, but I think this is a pretty significant advantage in Android’s long-term favor.

Qualitative score: Android gets a B while iPhone gets a D.

• Configuration management. Regular readers of my column know I’m no fan of software patching, but I’m also realistic enough to know that it’s often times the best real world option we have in dealing with security defects. To that end, Apple has done a great job at making software updates easy and quick (to the chagrin of the underground community of iPhone unlockers). If you can sync an iPod in iTunes, you can install security patches for an iPhone. Plug it in and wait a few moments. It’s that simple. The only thing better would be a periodic over-the-air updater along the lines of Apple’s Software Update or Microsoft’s Windows Update.

I couldn’t find how the Android folks will address this, so I’m guessing it’ll be at the discretion of each actual handset manufacturer. Some of them do ok with software updates, but the vast majority fail miserably. Let’s hope they learn from Apple’s lead here and come out with updaters that really work.

Qualitative score: Android gets an INCOMPLETE while iPhone gets a B+.

The criteria I’ve listed here are, in my view, pretty important to the long-term security of the products. Even though I don’t yet have two devices side by side to really run through their paces, there are some pretty good indicators. Everything I’ve found leads me to conclude that Android is likely to be a more secure and safer platform for the end users.

I’ll add here that Apple has recently announced a soon-to-be-released software development kit (SDK) that should at least somewhat open the platform up to third party software installations. That hasn’t seen the light of day yet, so I can only guess what it’ll actually be like, but my hope is that they’ll address some of their security shortcomings when they release the SDK. I’ve heard wild speculation bordering on rumor that Apple is at least considering some form of virtual machine technology to separate third party applications from one another. If that ends up being the case, I might have to re-visit my conclusions significantly, but if I were to bet today, I’d put my money on Android.