At issue is Apple's iPhone client implementation of Exchange ActiveSync, the Microsoft specification Apple licensed last year in order to provide official support for Exchange Server sync to the iPhone and iPod touch.
EASy to wipe
EAS defines not only how Exchange server syncs data to mobile clients, but also involves remote management features like remote wipe and security policy such as mandating that all devices be set to use a PIN to lock the screen when not in use.
Microsoft has evolved EAS over time, adding new options that allow Exchange admins additional control over the devices they choose to support. For example, in Exchange 2007 Service Pack 1, Microsoft added a new security policy option to require device encryption on mobile devices in order to support a new feature of Windows Mobile 6.0.
With file level device encryption, administrators can rapidly remote wipe a lost or stolen device, minimizing the risk of its data falling in the wrong hands. Without device encryption, a remote wipe takes longer because the remote device must zero all of its files. This makes it more likely that a thief could interrupt the wipe process, although once a phone is stolen, a savvy thief can disable its network connection and attempt to prevent any remote wipe from ever occurring.
Client manufacturers who license EAS from Microsoft, including Apple, Palm and Sony Ericsson, can implement the EAS specification on their client devices however they like. For example, the Palm Pre's Exchange support currently doesn't support security policy involving PIN use or remote wipe at all. Even Microsoft's own Windows Mobile 5.x implemented support for EAS differently than the current WiMo 6.x.
For example, under WiMo 5, EAS remote wipe couldn't also clear any data stored on an installed SD Flash card. Since most WiMo phones shipped with very little included storage, any important data was most likely kept on this impossible to wipe Flash memory.
This effectively meant that Exchange admins simply could not really wipe a WiMo 5.0 phone, even though the devices were described as supporting a form of remote wipe. That detail didn't stop pundits from favorably comparing WiMo 5.x's ineffectual wipe with the lack of any remote wipe feature on the original iPhone up until the release of the 2.0 firmware.
An Exchange server has no way to demand that clients obey all of its security policies; it has to trust that client devices respect them. When administrators specify a given policy on the server, mobile devices that fully support those feature options will stop working if the server-side policy settings raise the bar beyond the devices' capabilities.
That's what happened to many iPhone users who upgraded to iPhone 3.1 only to discover that their device stopped syncing with any Exchange Servers using the default "RequireDeviceEncryption" policy set to "True." Only the iPhone 3GS and the newly released 32 and 64GB iPod touch models support this hardware encryption feature; earlier models of the iPhone and iPod touch do not, and subsequently, their expanded support for Exchange policy settings forced them to no longer work.
In order for affected iPhone 3.1 users to reestablish a connection with Exchange, server-side administrators need to create a policy exception (for either that user or the entire server) which will allow connections to mobile devices that do not support device encryption. This was the status quo prior to Exchange 2007 SP1, which introduced the policy option, so it really isn't a drastic reduction in security as some have suggested. It involves unchecking a box and clicking OK (below).
The only other alternative is for those users to either upgrade to phone hardware that meets the minimum requirements configured on their company's Exchange Server, or downgrade back to iPhone 3.0 and simply ignore the security policy set by their company. The reason for the change on Apple's end is to comply with legal security requirements such as HIPAA, enabling the new iPhone 3GS to be suitable for approval in secure enterprise environments such as within the healthcare industry.
Oh the humanity
This change in the iPhone 3.1 update was poorly communicated to users by Apple, which should have at least alerted users of the potential impact of the upgrade during the installation process. The same update also quietly disabled tethering support on AT&T for certain users who had enabled the software feature against the terms of their AT&T contract.
The result was confusion and frustration by users, many of whom lack any capacity to motivate their company's Exchange admins to help them understand what had happened, let alone accommodate them with security policy changes from the default settings many Exchange Server shops never bother to change.
Similar security policy problems have resulted in problems for Mac users. Windows Server introduced changes that broke compatibility with existing clients while trying to enhance the network's security profile in tandem with the launch of Vista, for example. Support for alternative platforms like the iPhone and the Mac is not Microsoft's top priority, of course. However, Apple's increasing popularity among consumers, particularly among executives and mobile road warriors, has helped to promote improved support for Apple clients in many Windows-oriented companies.
Still, when unexpected things happen, many pundits are ready revile Apple's security credentials and denounce the company in scathing terms. Writing for InfoWorld, Galen Gruman stated Apple had "betrayed the iPhone's business hopes" and accused the company of misrepresenting the security profile of its iPhone devices, based on the speculation that iPhone 3.0 software must have "lied" by reporting that it was performing encryption prior to the update.
The problem with proprietary standards
In reality, iPhone 3.1 simply improved its support for EAS's defined security policy options, with unfortunate results for anyone who wanted to sync with an Exchange Server set to the default policy settings that happened to exclude their model of iPhone.
The proprietary nature of EAS, along with its constantly changing specifications tied to Microsoft's business decisions rather than industry consensus, creates a problem for consumers who want competition and choice along with the assurance that the phone they buy will work with their company's servers.
Right now however, the enterprise messaging industry's leading vendors have no desire to craft an open standard for mobile sync. Instead, RIM is promoting its own BlackBerry Enterprise Server product, which rakes in profits, while Microsoft is working to establish EAS as a way to anchor its dominance in corporate email with Exchange Server.
Imagine if Palm had paid Apple for the rights to sync the Pre with iTunes, but that part of the deal required Palm to only support features Apple allowed. This wouldn't be ideal or open. On the other hand, it's challenging for community consensus to build open standards that don't hamper the potential for innovation. Emerging web standards are a great example of finding a common ground in between, where vendors can innovate with different engines and browsers that also implement common, compatible features.
Whether something similar will ever happen in the mobile world remains to be seen. Apple is rapidly becoming a significant player in the smartphone industry, having passed Microsoft's combined Windows Mobile market share. With so many iPhone users, Exchange administrators have more reason than ever to accommodate them.
Apple is also taking its first real opportunity to enter the enterprise market seriously, and iPhone 3.1 is evidence of that, even if it results in short-term pain for some users right now. To help, Apple has revised its iPhone 3.0 Enterprise Deployment Guide (PDF) to include the new changes in iPhone 3.1.
Without much life left in its own mobile platform, Microsoft is likely to become increasingly supportive of third party mobile platforms on Exchange, and could someday even release EAS as an open specification to prevent a rival, alternative open specification from being launched.
Microsoft is actually making some use of the Open Mobile Alliance Device Management (OMA DM) protocol, which is also used by Symbian and in mobile device management tools sold by IBM. OMA DM is an offshoot to the SyncML consortium. Apple hasn't attempted to support SyncML since the original version of iSync, and neither the iPhone nor Android seem to be paying any attention to OMA DM.