Do the ex-Acompli now Outlook clients really compromise security or is everyone overreacting?

I fear that some of the noble denizens of the Internet quite lost the run of themselves following Microsoft’s January 29 announcement that their Acompli acquisition had received the full benefit of a corporate rebranding and had emerged to be available as Outlook for iOS and Outlook for Android (limited to some phones and tablets).

The first batch of comments focused on the lack of functionality in the email client and wondered just what Microsoft had been doing in the two months since Acompli was purchased. Or more correctly, why hadn’t the newly acquired development team cracked on to produce all of the missing features that people really want.

Well, speaking with some background experience of corporate acquisitions, my guess is that the Acompli team has been burning many cycles getting to know Microsoft and how to function within a huge corporate structure. And on the other side, it’s likely that Microsoft has spent the time figuring out how best to incorporate Acompli in their overall mobile email strategy, which up to that point had been focused on two tracks: ActiveSync for the masses and OWA for Devices for those who needed advanced functionality. The Christmas and New Year breaks also happened. In other words, lots of time off and planning, little time for programming new features.

So is it at all surprising that what Microsoft announced is what you could reasonably expect at this point? That the rebranded but otherwise unchanged Acompli is the new Outlook client for the iOS and Android platforms and that the OWA for Devices initiative is toast (but will remain available until Acompli catches up with functionality like support for rights management). I happen to think that this is the right strategy and it is good that Microsoft has come out and let us know what they are doing.

Acompli is an application built by a startup. As such, it used what was available to accomplish its goal of bringing a product to market and no more. Remember, it wasn’t part of the Microsoft Corporation when Acompli set out to develop an email client. Even so, the client received pretty good feedback from users.

Acompli is definitely flawed and imperfect when it comes to the functionality you’d expect from an enterprise mobile email client, like access to the global address list, but other clients have their own issues. The Apple iOS mail client has had its ups and downs when linked to Exchange and even the Windows Phone Outlook mobile client lacks features, like access to archive mailboxes.

I don’t think Microsoft bought Acompli because of its broad and deep feature set. Instead, Acompli scored because it looked good, worked well in what it did, and delivered some interesting ways to work with email and calendar for servers that included Exchange but also Gmail and Outlook.com. And it was better than the clients that Microsoft had in-house. OWA for Devices is an inventive attempt to unleash the functionality available in Outlook Web App on mobile devices but it has suffered in terms of usability and performance, and the lack of progress with the Android version was marked.

Interestingly, some have remarked that Microsoft now makes the best Gmail mobile client for the iPhone and even the Wall Street Journal likes the new client.

Getting back to some of the complaints that I’ve heard, let’s talk about how the new Outlook mobile clients access Exchange. As an independent ISV, Acompli had to use available protocols to talk to Exchange. ActiveSync (EAS) is the most practical and obvious choice in this situation. EAS is the most commonly used protocol across all mobile email applications, is a protocol that has stood the test of time and is (now) reasonably bulletproof. But because EAS is the lowest common denominator of Exchange client protocols, what you can do with it is limited.  Just using EAS wouldn’t allow Acompli to offer the kind of functionality that the developers wanted to make their application stand out from the crowd. So they decided to use EAS to fetch data from Exchange and to put the data through some intermediate processing before it was pushed to clients. This is how Acompli delivers its “focused” Inbox. Interestingly, if you use the Office 365 Clutter feature, the focused inbox is even more focused because EAS provides messages that have already been screened by Clutter.

Acompli takes the user credentials provided by those who sign up for its service to fetch mailbox data with EAS. Unlike other mobile clients that use EAS, Acompli is a kind of pseudo-EAS user and a single device identifier appears to Exchange management interfaces. I pointed out in December that the remote wipe implementation via EAS is weak or just doesn’t work and this is definitely something that has to be addressed. I also noted that the “service requires that certain data flow through the Acompli service so that we can index it and provide the Acompli experience on your mobile device.”

Acompli retrieves one month of email from each user mailbox. The data is stored and processed in Acompli repositories, which appear to run on Amazon Web Services. There is no secret here because Acompli describes this in their privacy and security policies, which seek to give confidence to users about how their data is managed:

“Some user data are retained in Acompli system during the lifetime of a user account, always encrypted at rest. A user can choose to completely purge his/her account from the mobile app, in which case all user data will be wiped clean throughout the Acompli system, from both the mobile device and the server farm. Exchange accounts also support end-to-end data purge can also be initiated from the Exchange server via mobile policy “remote wipe” either by the user or by an IT administrator.”

Policies are all very well (and easy to write); making sure that policy happens is quite another matter. As mentioned above, removing data and wiping devices properly when required to protect company information or just because a user decides that they want to stop using a service is absolutely fundamental. No argument. It just has to happen reliability, accurately, and quickly. Some improvement is needed here.

With this background in mind, commentary like the post warning that “Outlook app for iOS breaks your company security” (from Rene Winkelmeyer, an “IBM champion” for collaboration solutions according to his LinkedIn profile) is a little over the top. A number of other commentaries flowed from this post, including this one on the UK Register (known for its in-depth and impartial coverage). There is some truth in the assertions being made, but like everything else in life you have to put the issues into context. And in terms of IT security, that means understanding where risk exists and how to control that risk.

I’ve already discussed why Outlook for iOS and Android retrieves and processes data in the way that it does. Let’s move on to access to OneDrive, Dropbox, and Google Drive. It’s true that users can share attachments on these services, but I suggest that mail apps are all heading down the path of allowing users to make more extensive use of cloud-based file sharing repositories and that Acompli is not unique here. I take security very seriously and believe that this kind of situation has to be covered by a company security policy and the risks inherent in using public cloud file sharing services has to be clearly explained to employees together with the consequences of misusing these services.

More importantly for non-U.S. users, the data retrieved from Exchange is stored on servers located in the United States. That’s a red flag for many Europeans. Hopefully Microsoft is busy moving the data from AWS to Azure behind the scenes and will soon be able to announce that the privacy and data at rest arrangements for international users are similar to those that exist for Office 365.

What we have here is some newly acquired software that has had some corporate lipstick applied to make it able to play its part in Microsoft’s mobile email strategy (a useful FAQ is available online). I didn’t expect much else to happen by now. However, I do expect significant movement to have occurred by the time the Ignite event rolls around next May, especially in the areas of security and management with hopefully some better integration with and use of EAS policies for device management. In the meantime, some EAS controls do work, as MVP Paul Cunningham explains in his article about how to control client connections from Outlook for iOS and Outlook for Android.

Looking back on all the commentary that has been voiced since Microsoft’s announcement, a case can be made to support the view that Microsoft should have waited until these clients were more fully baked into their mobile email strategy and some of the more egregious issues were resolved (like moving data off AWS). But an equal case can be made to say that goodness exists in releasing the clients as they clearly demonstrate where Microsoft’s mobile email strategy is going. And let’s not forget that this is free (beta) software.

My recommendation is that companies should test the new Outlook for iOS and Outlook for Android to make a decision about where you think functionality gaps exists and whether these clients can be used now. If not, wait a few months and test again. The nature of cloud development and the speed at which things happen mean that stuff changes very quickly.

Follow Tony @12Knocksinna