Samsung? BlackBerry? Who Will Win the Containerization Wars?
Mobile Application Management vendors all perform containerization, wrapping apps in a security management layer of code. 3rd parties like Box that distribute lots of apps would want to be able to distribute a wrapped version in the app stores, but every MAM vendor uses a different wrapper. Will one win out? Is there a role for standards?
MDM (mobile device management) has become a commodity technology over the years. It is also embarrassingly limited in its ability to secure devices and data on those devices. But it is, ironically, standardized by the rigid definition of what Apple will support.
The main technique in MAM is containerization or wrapping: The management system takes an app and "wraps" it inside a shell of code through which all access to the app must pass. This container (or "wrapper") is a management point: It implements policy as set by the MAM system. Examples of policies that Apperian's EASE can impose as policies on an app include:
A per-app passphrase
Strong encryption of all data stored
A per-app VPN tunnel to the enterprise
Many other companies implement similar sets of features in their MAM products. Some big names are getting into this business, including BlackBerry with BES 10 and Samsung with Knox. But there is no standard for the feature set and there is no binary standard for the container code, so there is no interoperability.
Join us at Interop Las Vegas where the mobility track will explore best practices for management of mobile computing today and what's coming in the future. Register today!
Of course, the MAM companies don't necessarily want interoperability, but if there was, then the development tools for secured apps and the management systems for them could be separate. More importantly, secured versions of apps could be deployed through the app stores. For now they must be deployed through an enterprise app store -- a feature often sold separately.
At one point an MAM vendor suggested to me that certain large volume apps, Box for instance, would start to distribute versions of their apps wrapped with that MAM vendor's container in the app store. This would greatly ease the deployment of these apps and be a good deal for the MAM vendor as well. But what about all the other container systems? If there are 20 of them (I don't know about that number but it's possible) are app vendors supposed to maintain 20 versions in the app store?
[Update: I've just been reminded of the Symantec Sealed program which is a program to do pretty much what I propose in this column, albeit with Symantec's MAM implementation (Symantec App Center). In fact, I believe it was Symantec who was the vendor I mentioned in the article as suggesting to me that they would do this.]
So where this idea is going is that it would be good for there to be a containerization standard. A manifest could define which APIs are supported, the secured version could be distributed through the app store — perhaps it would be the only version distributed — and dev tools, management systems and enterprise app stores could compete based on their own merits.
Of course, for the most part the same companies sell these tools together so they don't have much of an interest in dividing them up. But Samsung and BlackBerry — and maybe even Apple — could change this. BlackBerry does sell BES, but it has shown an interest in opening its APIs before and currently its interest lies in spreading the use of its technology by any means necessary. Samsung is already working with third-party MAM companies to support Knox. Apple is nowhere in all this, but could help itself a lot by advancing the standard for security of app management.
Mobile security is a messy phenomenon evolving as you read this through the market. The market is still structured not necessarily to the advantage of the customer, but it's inevitable that it will end up that way, because in the end customers will demand it. That's why I don't think the chaos of multiple container formats will last.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.