If there's any company making mobile safe for business but useful for people, it's Apple. And Apple is making iOS and OS X even safer while remaining truly useful for people in the new content and application management APIs debuting in iOS 7 and OS X 10.9 Mavericks, detailed later in this post. The move will create a huge, positive shift in attitudes about business use of mobile tech, and I daresay PC tech as well, especially as third-party tools and software developers adopt the APIs.
And they will: AirWatch, Centrify, Citrix Systems, Good Technology, MobileIron, MobileSpace, and so on have already announced they will use the technology in their management tools (some are already shipping). In an interesting twist, MobileSpace is also providing similar capability for Android.
[ Galen Gruman describes a smarter approach to mobile security. | Mobile security: iOS vs. Android vs. BlackBerry vs. Windows Phone. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]
When Apple adopted Exchange ActiveSync (EAS) and added its own management and security APIs to iOS 4.2 in summer 2010, business joined the mobile revolution. Suddenly, IT could enforce password policies, be confident that on-device encryption was enabled, and even regulate device access to specific Wi-Fi networks, applications, and various services for users where locking down access was a legitimate security need. Over time, Apple has refined those controls in each subsequent iOS version and added many of them to OS X. Google copied the basic APIs for Android, and Samsung enhanced them to be closer to what Apple offers.
Here are the key content and application management APIs and related capabilities that iOS 7 and OS X Mavericks bring to the table. Apple of course has documentation on much of it in its developers website (you need a developer account to view these) as well as a public overview for IT.
Managed Open In
The Open In facility is how iOS exposes content from one app to another. In iOS, there is no shared file system, which prevents malware attacks and keeps apps' content stores separate from other apps. Instead, apps specify what file formats they both support and will accept from other apps. Users see this as the Share sheet pane of compatible apps when they use the Share button or other Open In trigger. The current app then calls the selected app and offers to send it the selected file. This is how, for example, you move a file attachment from Mail into GoodReader or Dropbox, or from Dropbox to Apple Pages or Google Quickoffice.
A new API in iOS 7 and OS X Mavericks lets you specify which apps may be sent Open In calls -- essentially, whitelisting apps that can accept data from the apps you provision or manage. The management is at the account level, so all accounts (including Mail and Calendar) and apps provisioned by the corporation follow the Open In policy set for that account. It's important to understand that managed Open In is binary: All managed apps (those provisioned by the company) have the same set of Open In policies, and all unmanaged apps (those provisioned by the user from the App Store) have none of your Open In policies applied, notes Ojas Rege, vice president of startegy at MobileIron.
Where the new managed Open In approach falls short is when an app has both personal and business uses, as many commercial apps do. The Open In policy applies to any and all documents in an app, as there is no way outside of account-based apps like Mail to know whether the data is corporate or personal. I've urged Apple and its competitors create a more granular information management standard I've dubbed InfoTrust.
Single sign-in and unified passcode policies
iOS 7 and OS X Mavericks unify storage of and access to sign-in keys, using what's called the shared keychain, so they can be used by multiple apps and managed via an MDM server. In previous versions of iOS, the internal dev team at a company could use a shared keychain for single sign-in to corporate apps. A developer with a suite of apps could do the same for that suite.
The new Kerberos-based single sign-on facility lets IT federate these shared keychains as well as single apps' keys, so a common login can unlock all the apps whose passwords have been federated. That single sign-in key is stored by iOS, not by the apps, and managed by your own management server. Most apps don't need to be recoded to be compatible with single sign-in. But deploying the single sign-on does mean work for IT to make the Kerberos key facility accessible through a VPN rather than over the Internet, notes MobileIron's Rege.
OS X Mavericks' passcode policies are now identical to those in iOS 7, so IT can stop worrying about the implementation implications of minor differences in previous versions.
AirPlay, AirPrint, and font management
Additional iOS policies
On devices running in supervised mode -- that is, those issued by a company preconfigured, the familiar BlackBerry approach -- there are now APIs for policies on whether users can change account information, whether users can change entries in the Find My Friends app (such as to only track specific colleagues in a workgroup, and to prevent employees from making themselves invisible if their location is being tracked), whether apps may use cellular data or not, whether devices can pair to other Macs, and define allowable services (such as copy or paste) for text selections.
Setting a device to supervised mode no longer requires physically connecting it to a PC or Mac running the Apple Configurator tool; supervision can now be set up at purchase and managed over the air.
For any iOS device, new API restrictions include controls over ad tracking, iCloud Keychain syncing (the unified website password cache shared across all devices on the same account), over-the-air PKI updates, and whether the Wi-Fi and Airplane Mode buttons appear on the lock screen.
Also for all devices, MDM servers can now query whether the mobile hotspot function is enabled (to make the device a Wi-Fi access point for other devices, so they can share a cellular connection), whether Do Not Disturb is active, whether Find My iPhone is enabled, and whether an iTunes account is signed in. New controls include setting a custom lock screen, putting a device in lost mode (so its lock screen displays "if you find me" information), and disabling the hotspot feature.
The new app-management protocols also let IT specify apps to be installed automatically on iOS devices and Macs, based on the new ability to buy and distribute app licenses rather than individual (per-user) redemption codes. MDM servers can manage which apps are available to whom and which are auto-installed (the others show up in the Purchased pane in the App Store app on the user's device, available for download if desired).
Licenses to such managed apps can be revoked, so apps no longer automatically become owned by the user, as in the case of redemption codes. (However, content licenses -- such as for books -- stay with the user and cannot be revoked.) Revoked iOS apps continue to work for a 30-day grace period, and a prompt to buy a noncorporate copy appears. (You'll need to manage access to information separately, such as by disabling VPN or email access using their own policies.) Revoked OS X apps stop working immediately, quitting on launch. For this to work, managed apps need to check their receipt status.
These licenses and their installation management are available for apps in the Apple corporate app store, aka the App Store Volume Purchase Program, and do not apply to apps in the public App Store -- Apple considers those to be personal apps that companies have no rights over. It's a clear separation: Even though there's one user interface, iOS and OS X tracks which apps and content come from the corporate app store, Exchange or other server, and any management servers, then provides IT control over those. Whatever the user buys from the public App Store or accesses from his or her own email and other accounts belongs to that user -- including the Apple ID.
That principle has been in iOS since version 4.2, but the new APIs and protocols extend it more deeply into the application and content domains. As a result, most organizations' data protection and app isolation needs should be supported without relying on specific vendors' management tools and APIs. IT can use a broader variety of corporate apps without being locked in to specific management vendors -- and thus should be able to get control over more apps than is possible today. Users avoid the hassle of switching between personas, a clunkier approach adopted by BlackBerry 10's Balance feature, Samsung's Knox protocol, General Dynamics' Android version, and Android tools such as Enterproid's two-year-old Divide. After all, who needs clunky?