Microsoft has launched Outlook for iOS and Android, a new mobile email client that is available for iOS and Android devices. This new app will replace the OWA for Devices app which remains available for now while Outlook for iOS and Android is developed and improved further.
The launch of Outlook for iOS and Android has stirred up some controversy around security and the way that the application and its back-end infrastructure handle user credentials. I want to go into this further here, but first let’s briefly look at the application itself.
Managing Email, Not Just Accessing Email
A major gripe with many mobile email applications, particularly the native mail apps that ship with mobile operating systems like iOS and Android, is that they deliver only basic access to email and calendars. Very little functionality exists in these apps to help end users manage their email.
In a world where email is supposedly dead, yet more and more people are drowning in the ever increasing volume of email they receive, it is not surprising to see specialized mobile email applications arrive on the scene. Examples include Mailbox, Google Inbox, and Acompli (which was acquired by Microsoft and is now Outlook for iOS and Android).
These apps put features in the hands of users to allow them to manage their email better, sort through the noise, and (for some people) achieve “Inbox Zero”. This is a good thing for users, and I applaud Microsoft for getting into this space rather than live with the user experiences that other applications are providing.
Functionally the application is fine, if a little rough around the edges. But that is easily improved and no doubt Microsoft has a roadmap of rapid updates planned to improve the user experience.
I want to talk about other things instead.
Security Concerns with Outlook for iOS and Android
Much noise has been made about the way that Outlook for iOS and Android works, with particular concern around the storing of user credentials.
I have the same information about the architecture behind Outlook for iOS and Android as anybody else, and here’s my explanation of how it works.
In short, Outlook for iOS and Android connects to a server or service hosted in the cloud. It does not connect directly to your corporate Exchange server, Office 365 tenant, or other email services (the app supports Outlook.com, Yahoo!, and Gmail).
When you configure an account in Outlook for iOS and Android you’re sending your credentials to the cloud service to store. The cloud service then connects to your mailbox on your behalf, accesses your email for the purposes of indexing and sorting (for example, to determine what should go in your “Focused” inbox view), and then the app on your mobile device downloads the messages from that cloud service.
Cynics would say this is akin to a “man in the middle” attack. Which it is; except it is not malicious.
There are legitimate concerns to be had here, let’s be honest.
- Microsoft is storing your credentials (in the case of Gmail I believe OAuth is used instead). How are they stored? This has not been communicated at this stage. However, I trust Microsoft to securely store my data including my credentials, and so do thousands of organizations around the world (take DirSync with Password Sync as an example).
- Corporate policies are being violated. Providing your user credentials to a third party is a breach of many IT usage policies, and the app doesn’t make clear to end users that this is occurring. In fact the typical end user would have no idea that this is happening.
Microsoft needs to address these concerns as soon as possible. Let’s assume for now that the architecture of Outlook for iOS and Android is not going to change, and that the cloud service acting as a proxy between the user and their mailbox will remain in place. Microsoft needs to communicate much more transparently what is happening here so that end users and corporate IT can make a proper risk assessment.
In the meantime, if you would prefer to block or quarantine the app from your Exchange or Office 365 mailboxes while you do more investigation then you can follow the steps here to create an ActiveSync device access rule:
Microsoft also needs to open up a process whereby a customer can request removal of stored credentials. Removing the app from a device does not necessarily remove the stored credentials. I’m sure a light-touch mechanism for this can be developed in the near future.
Mobile Device Management Concerns with Outlook for iOS and Android
I spent some time examining Outlook for iOS and Android from a mobile device management perspective. I found a few interesting things that I wanted to expand on here.
Policy Compliance
The first thing some people will notice is that Outlook for iOS and Android will successfully connect to mailboxes that have ActiveSync mailbox policies in place that require things like PIN codes and device encryption.
However, the app itself has no PIN code functionality that I can see, and in-app encryption is an unknown as well. Yet it reports itself to the server as compliant and is allowed in. Remember, ActiveSync policy compliance is an honesty system where the server relies on the device accurately reporting its compliance. This is true of straight ActiveSync connectivity but can be mitigated with additional mobile device management.
This is not automatically a problem. The default policies for Exchange 2013 and Office 365 are quite permissive and do not require PINs or device encryption. So any organization still running those defaults has no problem with Outlook for iOS and Android’s behavior.
That said, it would be nice if Microsoft would ship an app that respects an organization’s policies.
Device Associations
Due to the “man in the middle” approach being used with Outlook for iOS and Android there will only ever be one mobile device association visible for the user, no matter how many different devices they have installed the app on.
This is fine, if a little awkward to report accurately on, until someone loses a device. Imagine an executive who has the app on their phone and tablet. The tablet is lost in the back of a taxi, but they still have their phone. The IT team has to make a decision – issue a remote wipe for the single “device”, which will wipe the account data from every device the app is installed on. Or, do nothing.
There’s no right answer there. But it does lead us into the next problem.
Remote Wipe Behavior
I was pleased to see that in my testing the remote wipe does actually work, and it does only remove the specific account from the Outlook for iOS and Android app. Other accounts configured in the app are untouched, as is the rest of the data on the device itself.
This type of “selective wipe” is perfect for BYOD environments. But there’s still a problem with how it works with this app.
Unfortunately, the app (or the cloud service in the middle) never reports back with the result of the wipe. No matter whether the remote wipe was request was successful or not, it will remain in a “pending” state forever. Or until the wipe request is removed.
In the earlier example of the executive with two devices this presents a problem. All their devices are blocked from connecting due to the remote wipe request. If they want to keep using their phone then the remote wipe request needs to be removed, without anyone knowing whether the lost tablet was successfully wiped.
There may be a workaround available whereby the app is completely removed and reinstalled, which gives it a new device ID and circumvents the problem. But that is still an awkward solution, and doesn’t solve the issue of the remote wipe result never being reported accurately.
Blocking Behavior
This falls more into the user experience side of things rather than being an architectural concern, but I’ll call it out here anyway.
When Outlook for iOS and Android is blocked, for example by using ActiveSync device access rules as mentioned earlier, it interprets this as an authentication failure and re-prompts for credentials. The other option given to the user at that time is to delete the account from the app. However, it is not clear whether this deletes the account only from the app, or also from the cloud service that is storing credentials and polling for email on the user’s behalf.
Other mail apps such as the native Mail app on iOS simply interpret a block as a “failure to connect to server”, which is also not a great user experience but is possibly better than falling into a cycle of re-entering credentials or removing the account entirely.
Summary
In my view Microsoft has done the right thing in acquiring this application from Acompli and launching it as Outlook for iOS and Android. The world is crying out for better email management apps and Microsoft needs to be in this space.
In the push to get it released I think they’ve fallen short on some of the communication aspects of the launch. These can be quickly remedied and I’m sure a series of blog posts and other announcements will clear up a lot of the confusion and concern that is floating around right now.
From a functional perspective I agree that the app needs some work, but I also think it is ready for launch and is past the point of being labelled a “beta” release. Holding things back and trying to get them perfect is how the old, slow Microsoft would have done it. This is the new Microsoft, ready to compete with the smaller, more agile startups out there, and more open to user feedback and letting that guide their development efforts. The more hands using the app and giving feedback the better.
Give it a try and let me know your thoughts in the comments below.
Further reading:
- Do the ex-Acompli now Outlook clients really compromise security or is everyone overreacting?
- A deeper look at Outlook for iOS and Android
This article Microsoft Wants to Improve Your Mobile Email Experience with the New Outlook for iOS and Android is © 2015 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
