Educause Security Discussion mailing list archives

Re: Use of Acompli to accelerate email to IOS and Android


From: Mike Osterman <ostermmg () WHITMAN EDU>
Date: Fri, 30 Jan 2015 11:05:58 -0800

Steve:

I totally agree that on-prem is the exception, as it appears that the majority are using Google Apps, Office 365, or a 
combo of the two.

I did not mean to imply a value judgment about anyone's choices, but rather underline the institutional risks that come 
about with this new(ish) collection of apps that do a lot of remote mail parsing to provide these admittedly very 
beneficial features.

Acceptable or not is up to each institution (or individual, barring institutional policies/controls); my intent was 
only to highlight what risks need to be evaluated with this breed of apps to make that call.

From a pure risk analysis standpoint, I would say that the OAuth scenario adds a layer of complexity to the analysis, 
as an institution has a contract with Google or Microsoft about appropriate handling of data, but these apps often 
still "read" the user's mail on a server somewhere in the cloud, and the institution has no such contract with the app 
service providers. They allow end-users to make individual agreements with the service provider on behalf of the 
institution (if you take the stance that email data is an institutional and not individual concern). It's no different 
than someone using a non-institutional Dropbox, Box, or Google Drive account, and we're all still struggling to find 
ways to provide the same level of service as these tools offer yet in a way that enables us to protect the data for 
which we are (institutionally) responsible.

On a side note, I had high hopes for Google's Inbox to get up to speed with Mailbox.app and the like, so you're at 
least dealing with one company for your core mail services as well as the app add-ons, but it doesn't yet seem up to 
snuff.

-Mike

On Jan 30, 2015, at 10:48 AM, Steve Terry <terrys () DENISON EDU> wrote:

Mike:

How many schools are not already in the cloud with email?  Exchange, on-prim may be the exception, rather than the 
norm?  So if schools are already using cloud-based solutions (Gmail, Office365, etc.)  is the OAuth scenario still 
applicable?

Steve 

Steve Terry
Director of Enterprise Applications
ITS
Denison University
Fellows Hall - 102B
Granville, OH 43023 
740-587-8685 <> | www.denison.edu <http://www.denison.edu/>
On Fri, Jan 30, 2015 at 12:24 PM, Mike Osterman <ostermmg () whitman edu <mailto:ostermmg () whitman edu>> wrote:
I think the issue with Acompli (or CloudMagic, Inky and the others that support non-OAuth mail) password storage is 
that it's storing the password on a remote server rather than on the person's device. There's always the risk that 
the app itself could turn evil and leak your credentials, but in the remote server scenario, you're providing a 
credential to a third party that could prove very dangerous in SSO-enabled environments like the EDU space. Sure, 
it's encrypted, but if they lost their encryption keys and the database, that's a pretty substantial loss.

Worse still, I don't think anyone but IT folks really understand the distinction of the location of the password 
storage or cares to do the research to make an informed decision.

Even in the OAuth scenario, you're avoiding the credential issue, but do still have highly-sensitive mail data 
(except in the case of Inky - http://inky.com/faq/ <http://inky.com/faq/>) passing through 3rd party servers in most 
implementations. If an organization is using Exchange on-premise, then you'll lose the inherent data privacy benefit 
by having institutional mail data--"metadata" at a minimum--traveling outside the organization.

It's tough, because this new breed of mail clients offer some fantastic functionality (I personally love the Snooze 
feature in Mailbox.app and use it with my personal email), but there are privacy tradeoffs, and many of our 
institutions don't have the policies and/or technical controls in place to be able to address these risks.

Mike Osterman
Director, Enterprise Technology
Whitman College
(509) 527-5419 <tel:%28509%29%20527-5419>

On Jan 30, 2015, at 9:00 AM, Steve Terry <terrys () DENISON EDU <mailto:terrys () DENISON EDU>> wrote:

Dennis:

Microsoft purchased Acompli a short time ago and turned it into a new version of Outlook for iOS and Android devices:
http://www.theverge.com/2015/1/29/7936081/microsoft-outlook-app-ios-android-features 
<http://www.theverge.com/2015/1/29/7936081/microsoft-outlook-app-ios-android-features>

I have used Acompli for about a year and have found it to be a fantastic piece of software.  I have also downloaded 
and run the new version of Outlook to compare it to my previous version of Acompli - it is same, but better!  (Add 
file access to Dropbox and other services.)

As for authentication, (Denision is a Google Education shop) - it prompts and uses our SSO authentication services 
to establish the initial connection to (Gmail) for us.  I see no differences, in this new version of Outlook, in 
terms of "storing" account information over any other previous iOS email clients?  

Steve

Steve Terry
Director of Enterprise Applications
ITS
Denison University
Fellows Hall - 102B
Granville, OH 43023 
740-587-8685 <> | www.denison.edu <http://www.denison.edu/>
On Fri, Jan 30, 2015 at 10:11 AM, Dennis Levine <dennis_levine () emerson edu <mailto:dennis_levine () emerson edu>> 
wrote:
Hi All.

  Just wondering if anyone is using or is considering the use of Acompli (https://www.acompli.com 
<https://www.acompli.com/>) to accelerate email distribution to IOS and Android mobile devices.

I’m a bit hesitant because they require a login to the exchange server and then store the email and account 
information on their servers, though they say it’s encrypted.

Any thoughts,

Dennis

 

Dennis Levine | Network and Security Administrator | 120 Boylston Street  Boston, MA  02116-4624 | (617) 824-8972 
<tel:%28617%29%20824-8972> | Dennis_Levine () emerson edu <mailto:Dennis_Levine () emerson edu> | www.emerson.edu 
<http://www.emerson.edu/>
<image001.jpg>

 






Current thread: