But first, I have to explain the basis for this preliminary comparisonAndroid 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, Androids design is open to scrutiny, while iPhones inner workings are closed and proprietary. That said, much has been written about both, and Im going to base my comparison on what Ive been able to find publicly documented, except where otherwise noted.
So, with that pretty significant set of caveats out of the way, lets dive in.https://o1.qnsr.com/log/p.gif?;n=203;c=204660766;s=9477;x=7936;f=201812281312070;u=j;z=TIMESTAMP;a=20392931;e=i 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. (Ill 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 thats just a few months old.
Now, looking at the security of Androids application platform, its obvious theyve 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. Thats a pretty powerful model.
On the other hand, defining the permissions in an applications AndroidManifest.xm file is discretionary, and a user could no doubt be duped into giving a malicious application a dangerous set of privileges. Weve 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 thats 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 doesnt even begin to address.
Qualitative score: Android gets an A- while iPhone gets an F (F-, if thats possible).
Openness. Weve heard claims for many years that open source software is more/less secure than its closed counterparts. Whats more, weve seen those claims pretty thoroughly debunked in various studies comparing the two worlds. But this is different. In Googles 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.
Id venture to bet Androids design and source code will receive more security scrutiny than most (all?) other open source projects. By comparison, only Apples Darwin kernel is available for public scrutiny, and there really isnt much of an external community with massive commercial interests in reviewing its security.
And theres more to openness than just accessibility of a products 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 applicationsfirewall, anti-spam, anti-malware, etcfor the platform.
Maybe Im totally off base here, but I think this is a pretty significant advantage in Androids long-term favor.
Qualitative score: Android gets a B while iPhone gets a D.
Configuration management. Regular readers of my column know Im no fan of software patching, but Im also realistic enough to know that its 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. Its that simple. The only thing better would be a periodic over-the-air updater along the lines of Apples Software Update or Microsofts Windows Update.
I couldnt find how the Android folks will address this, so Im guessing itll be at the discretion of each actual handset manufacturer. Some of them do ok with software updates, but the vast majority fail miserably. Lets hope they learn from Apples lead here and come out with updaters that really work.
Qualitative score: Android gets an INCOMPLETE while iPhone gets a B+.
The criteria Ive listed here are, in my view, pretty important to the long-term security of the products. Even though I dont yet have two devices side by side to really run through their paces, there are some pretty good indicators. Everything Ive found leads me to conclude that Android is likely to be a more secure and safer platform for the end users.
Ill 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 hasnt seen the light of day yet, so I can only guess what itll actually be like, but my hope is that theyll address some of their security shortcomings when they release the SDK. Ive 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, Id put my money on Android.