It's madness I tell thee
This thing hoovers your email using AWS (not Azure) from your corporate email account. "Temporarily" stores it in the cloud and then trickles it down to your phone.
What could possibly go wrong?
Big Blue boffin Rene Winkelmeyer has taken aim at Microsoft's iOS Outlook app, launched overnight, claiming it stores credentials in the cloud potentially even after delete requests, and does not observe known good security practices. The spray against the House That Bill Built followed an examination into the way the app …
This post has been deleted by its author
There's nothing particularly new here.
Before BB10, BlackBerries bought as personal phones would be plumbed into RIM's BlackBerry Internet Services (BIS). This did something very similar; it would retrieve email from your email provider on your behalf, and send a push notification out to your phone when something turned up. It was reliable, saved a ton of battery power (your phone didn't have to do anything for itself), and it was very fast too.
Differences? Well, it was BlackBerry's own servers doing it (not someone else's), I don't recall there ever being any problem with BIS retaining credentials beyond my expectations, and BlackBerry seem not to want to trawl through all your stuff looking for advertising data (which I considered to be a very appealing aspect of that service).
This post has been deleted by its author
Hmmmm...{muses} so do all the e-mails get sucked from O365 --> AWS --> iPhone/Android etc or does the app do a traditional "Exchangey" kind of connection direct to O365if it senses (via autodiscovery) an O365 hosted account?
And another thing!!! How can they expect us to buy in to Azure et al if they don't appear to use it themselves?
There's a big difference in storing the credential to access a service you offer (say O365 own mail), and to access someone else one.
In the former case, credential can be stored (hoepfully) in a far safer way (multiple hash, salt, etc.). In the latter, they have to be stored using reversible encryption, because of the need to submit them to the third party service... and that's a far bigger risk.
"If you use O365 you can bypass any MDM implementation with this app because it permits you to save to Dropbox instead of keeping corporate data in their dedicated cloud."
Not an issue - O365 can use encryption to stop this. If you saved Rights Management controlled documents to DropBox then you would not be able to access them without the permission and decryption keys that permitted it. See http://products.office.com/en-us/business/microsoft-azure-rights-management
I might be a bit uneducated on things, by why does the app need a separate server to fetch the email from your mail-server and then serve it to the phone?
My current (non Outlook/non exchange) setup has the app directly connect by IMAP to the mail-server and handles push notifications without polling. What is wrong with that solution?
It's they can't "index" your email otherwise. Face it - all these services are designed to "index" (aka read and classify information) from evey piece of your personal data. Why some web email services (GMail & C.) prompts you to read "all your accounts emails from a single inbox"? Exactly for the same reason - access all your emails. Accompli just moved this model to a local application by exploiting a "proxy" server reading all your email before delivering them to you. Useless - but hey! - it works [probably] on HTTP - which you know, it's the only protocol you should use (and the only protocol most actual developers look to know...), why use those outdate protocols like IMAP4 designed to read emails without any man in the middle?
PS: IMAP4 handles push notification if the IDLE command is supported by both parties, otherwise it has to poll.
Ignoring the obvious possibility that they use the man-in-the-middle server to exploit the data of their users, there are other ways to explain this.
Modern app developers, and you can assume that most of them are new to programming, go by the design pattern they are used to. And those include using an external server accessed via HTTP/Websockets, instead of doing local computation. They have been taught that local computation is slow and battery draining, so they do remote computation which requires data communications... which is slow and battery draining. Nobody does Profiling to see which way would be better in that situation. Furthermore they have never been taught in the ethical aspects of their trade, so they don't understand why it's a bad idea to more external components than necessary.
Then some mobile operating systems don't support "raw" sockets so you could do IMAPs. Windows Phone, for example, didn't support it on early versions. Plus there may be a certain irrational believe that using raw sockets is somehow bad, and you should have a layer in between.
Now if you actually control that server in the middle, the concept may actually even make sense. Done right, you can avoid having to store e-mail on your mobile device, which means that it'll be secure against theft. A server is much easier to secure than a mobile device since you can literally guard it from physical access by your attackers, and you can reach a far higher level of FOSS on your server.
A list of topics we don't want to see in this thread, because they've been done to death and totally discredited:
"If you've got nothing to hide, you've nothing to fear".
"Privacy is so last century, get over it".
"You're not a customer, you're the product".
"It's free, what do you expect".
"Our nation's security hinges on this. If we stop a single terrorist, it'll have been worth it".
"If these large corporations were really untrustworthy, surely they'd have been censured by now".
"Better Microsoft than ${other_company}".
Apple doesn't notify developers when an app is deleted and there is no explicit, positive & secure way of knowing if an app has been deleted. There is also zero trigger that tells the app that the user is deleting it, so it can't ask the user if cloud data should be deleted.
It's a fundamental iOS problem, not just for Accompli, but for everyone that stores data for users in a cloud back end. The net effect is that you never know if your app has been deleted or not, you can't tell if a user is deleting an app to re-install it and you don't really know what to do with user data when there is no communication with the app for a long time.
TL:DR, it's unfair to blame Accompi/MSFT for Apple's practices.
Also, it's unclear how Rene Winkelwyer expects 3rd party push to work without offline storing of user credentials. Blackberry does the same thing with BIS and no one is screaming about security in that context... Pretty much every push service (other than native IMAP push) requires some sort of buffer proxy to work properly, which in turn requires storing user credentials offline and they at least have to buffer the subject line + some preview text.
Seems like someone shouting fire who doesn't know much about either email transport or iOS limitations.
I'm just amused that, as much as Microsoft wants EVERYONE ELSE to use their cloud, that they are using AWS (Amazon Web Services) for their own product.
The poor security handling? That is just par for the course among some of these local/"cloud" hybrid services. Not that I condone it; far from it, I recommend not using "cloud" at all unless you know what it's doing with your information and especially security credentials. (To those who say this is OK and necessary -- no, it's obviously NOT necessary to keep your credentials when you've removed the app, or told it to delete your account.)