Why Apple Plays God with the iPhone SDK
August 28th, 2008
Daniel Eran Dilger
AppleInsider’s article “Developers question why Apple keeps its iPhone 2.0 SDK under NDA” presented several reasons why developers are frustrated with Apple’s tight control over the iPhone platform. Another facet behind Apple wanting to maintain a centralized position of control over iPhone development, where developers are bound by NDA to interface only with Apple but not each other, is to head off tangent hacks that might complicate Apple’s ability to lead its platform in the direction it wants.
One obvious recent example of this is OpenClip, a student developer’s plan to add copy and paste features to the iPhone by allowing third party apps to copy pasteboard data from other applications’ private directories. This works under the current iPhone 2.0 software, but only because Apple hadn’t yet finalized all of the details of its application sandbox security enforcement.
With the iPhone 2.1 SDK betas, which started shipping before OpenClip was released, the iPhone 2.1 software no longer allows apps to peek at each other’s files, the implementation of a policy Apple originally announced to developers in the “iPhone OS Programming Guide” with the original iPhone 2.0 SDK. There are many other examples of how hobbyist efforts to graft unofficial APIs into mainstream iPhone development could cause problems for Apple and for users.
Daring Fireball: Raining on the OpenClip Parade
iPhone OS Programming Guide: Security
Developers question why Apple keeps its iPhone 2.0 SDK under NDA
This isn’t a new problem; third party developers also worked to enhance and extend the Classic Mac OS of the 1980s using INIT patches that changed how the System Software worked at a low level. Apple gave developers an expanded, officially sanctioned mechanism for doing this in System 7 with System Extensions. However, this turned out to be chaotically difficult to manage.
INITs or Extensions frequently ran into conflict with each other and destabilized the system. They also served as a vector for viruses. Once an Extension grew popular among users, it became difficult for Apple to work around any problems it might cause or to deliver new features that might run into conflict with existing Extensions. In Mac OS X, Apple intentionally provided no mechanism for broadly patching the OS in the manner of System 7’s Extensions.
Third party developers have still managed to find ways to hack into the OS however. Mac OS X’s Input Managers, a mechanism NeXT originally designed to serve a controller for adding language support for complex character sets across applications, were hacked into a general purpose way to patch into nearly every app on the system and inject code that could modify their behavior and user interface. It’s easy to see why Input Managers also serve as a security hole and a destabilizing factor that cause applications to crash and system updates to fail.
MacJournals News : Input Managers are not ‘plug-ins’
Security Enforced by Authority.
As Apple progressively tightens down the system to enhance users’ security, it has only asked developers not to use Input Managers inappropriately; it hasn’t yet banned them. it also asks developers not to install code into the Mac OS X kernel unless absolutely necessary, and provides security guidelines to follow when installing applications and in other cases where sloppy behaviors could expose users to potential threats.
In other areas, Apple has gone beyond just making suggestions and is enforcing rules that following known best practices in security. From the start, Mac OS X was compartmentalized into Unix domains, including a System domain for Apple’s software, a machine domain for system wide Applications, and a User domain that segregated the settings and files of each user. User accounts and file permissions enforced the domain boundaries, to help prevent software from assuming more control that it should.
In the iPhone OS, third party applications are further compartmentalized into sandboxes. There is no communal file system that all apps can share as there is on desktop computers. Instead, each app can only access its own files within its sandbox for security reasons. Apple also limits third party apps from lingering in the background after a user has dismissed them with the home button. This is both a power saving mechanism and part of the iPhone’s security policy.
The system also requires that all apps be signed by a recognized authority, so that malware vendors can’t distribute untraceable software. Efforts to inject malicious software into distribution through the iTunes Apps Store on the sly can be remotely shut down by Apple using its “kill switch” of certificate-based security. Apple’s heightened security enforcement measures on the iPhone are also making their way onto the Mac OS X desktop, in order to allow corporations to centrally manage the software installed on their computers and to allow parents to control the access their children are allowed.
Apple’s security efforts are being rolled out in incremental advancements. If the company allowed third party developers to fork its strategies and introduce frameworks that impeded or conflicted with its plans, it would dial the company back into the days of System 7, where Mac Extension conflicts caused crashes that Apple could do little about because it wasn’t exercising its authority to enforce security on its platform.
With its Android smartphone platform, Google appears to be offering users and developers the tantalizing fruit of determining for themselves what they want, including a security model where developers vouch for their own apps on a handshake and users are free to initiate their own trust relationships with developers without any certificate-based security administered by a central authority.
However, that kind of freedom has served as fertile ground for the viruses, spyware, and adware crisis of the desktop Windows PC. The web itself is another example of a platform where anything goes and security is an afterthought, with the result being egregious adware and the mass distribution of malware that exploits the freedom of Windows PCs to seed new replicants and spam.
Microsoft contributed to the seedy nature of the web early on with its ActiveX technology, which gave developers wide open freedom to do things within the browser, with disastrous results. The only way to secure the web is to limit what can be done within the browser and rely upon external authorities to certify encrypted transactions where necessary.
Android developers, hardware makers and service providers will also have the freedom to pick and chose which APIs, hardware, and applications they want to support, ostensibly giving users the freedom of an infinite number of choices to select from, a policy that has introduced chaos among Windows Mobile phones, where choice is often an impediment rather than a feature. Symbian phones similarly have three different UI layers to chose from. Linux on the desktop has two main desktop environments, KDE and GNOME, with incompatible behaviors and implementations.
While some critics of Apple’s security policies worry the company exercises too much control what software providers can offer on the iPhone, it’s also true that the company’s mobile platform has delivered a level of success and security for mobile software distribution that other platforms can’t match, with tangible benefits for both developers and users.
The iPhone’s App Store prevents widespread piracy of developers’ work, allowing them to sell their software in volume for just a few dollars a title rather than the $15 to $50 that mobile software commonly sells for on other platforms. Users can also be confident that applications they download through iTunes aren’t infected with viruses, or spying on them via key loggers or other background tasks, and can’t even access their location without asking permission first. Android, Windows Mobile, and other mobile platforms can only hope that malicious developers don’t assault their users. Those vendors also lack a kill switch to do anything about it afterward.
And despite all the freedom Android promises to provide in hardware variety (something Windows Mobile currently delivers), iPhone users have the actual freedom of knowing that titles they buy from the Apps Store will work on their phone. iPhone developers have the freedom to add accelerometer support into their apps because all iPhones have the hardware to use it. That’s not the case with Windows Mobile, and it won’t be true with Android either.
While it’s true other platforms offer features the iPhone doesn’t, Apple’s platform starts off from a secure foundation that will be easy to build new features upon; it’s far harder to retrofit security into a platform that was designed to be full featured and impose few limits nor set any clear standards. Security requires a trustworthy authority. If Apple stopped playing God, it wouldn’t be doing its job.
Did you like this article? Let me know. Comment here, in the Forum, or email me with your ideas.
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast (oh wait, I have to fix that first). It’s also cool to submit my articles to Digg, Reddit, or Slashdot where more people will see them. Consider making a small donation supporting this site. Thanks!