Sandboxing mobile email in a third-party app is a common technique to prevent corporate data from leaking into users’ personal apps. The problem with these 3rd party email clients is that sometimes they’re slower and clunkier than the clients that are built into iOS and Android, and that they lack the ability to integrate with the rest of the device. (Of course, that’s often the whole point!) Some users are fine with third-party clients, but many prefer the native client.
But what if it was possible to protect email in built-in clients? Complete sandboxing of built-in clients (such as preventing other apps from accessing contacts) is probably a lot to ask of Android and iOS, but if all you’re worried about are attachments, then there are more options—all you really need to do is just turn off the “open in” function. This dastardly little feature is what launches attachments into the unknown world of other third-party apps. The issues surrounding complete sandboxing versus just protecting attachments probably deserve their own article, but regardless, there are many use cases where protecting only the attachments would be sufficient.
Anyway, here are are four ways of protecting email in built-in clients. The only problem is that the first three are merely thought-experiments and unlikely to exist anytime soon!
1. Add email sandboxing to mobile platforms themselves
iOS could protect emails by adding a few more policies to mobile device management configuration profiles. iOS MDM profiles have options that allow administrators to set up Exchange ActiveSync (EAS) accounts with a few security settings—admins can block users from moving messages to other folders of from using other apps to send emails using the EAS account. Now imagine if the MDM profiles were expanded and could turn off “open in” or prevent other apps from accessing contacts or other account information—suddenly iOS would have email sandboxing built-in! Since Android doesn’t use configuration profiles, new APIs for MDM apps to control the built-in email clients would need to be added.
These would be major changes for these operating systems. We can talk about how enterprise friendly or not friendly each platform is, but I just can’t imagine either one of these happening any time soon.
2. Add more controls to Exchange ActiveSync
On the other end, Microsoft could add more device management settings to Exchange ActiveSync, so that “open in”, contact access, and other permissions would come with the email protocol. This would have the advantage that administrators wouldn’t have to rely on a device being enrolled in MDM to get these settings. Instead, any client making the connection to EAS would get them. The only problem here is that not only would Microsoft have to make big changes, (and all indications so far are that Exchange 2013 won’t add any new ActiveSync features) but also the clients would have to be modified, as well.
3. Add per-device policies to Exchange ActiveSync
While we’re talking about ActiveSync, it’s worth mentioning that another way to make mobile email controllable would be to have more granular control over policies. In Exchange 2010, there are plenty of options for controlling which particular devices are allowed to make EAS connections in the first place, but the problem is that once devices are given access, all of the devices for a particular mailbox get the same management policy. The only way to enforce a policy on one of a user’s devices and not another is to simply not allow the other device to connect at all. Per-device management policies—as opposed to just per-device access policies—would create a lot more options for administrators. Again, the Exchange 2013 preview is out, and this isn’t in the cards.
4. Encrypt attachments
There are a lot of cases where companies are just worried about attachments, and fortunately there are ways of handling this today. (MobileIron Docs@Work is one product that comes to mind.) Instead of completely turning attachments off, they can be intercepted as they leave the server, encrypted, delivered along with the message, and only un-encrypted by corporate-managed applications. The user retains the original experience of the native email client, and corporate attachments are protected. With the previous three techniques, we’re assuming that even though “open in” is turned off, users would still get to preview attachments within the built-in mail client. Encrypting attachments, however, means that a user will have to go to a separate app in order to view them. While this could be annoying, if a user really prefers the built-in email client, at least this technique makes it possible.
What do you think—is just protecting attachments enough? Or will Android, iOS, or Exchange ActiveSync ever provide as much insulation as a third party email client? Share your thoughts in the comments!
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.