Version 1.6.4-dev1.1 - "work in progress", Exchange push mail

[pyler]

https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

Does this apply for AquaMail?

[Kostya Vasilyev]

Re: Does this apply for AquaMail

I think it might.

BUT! WHAT! THE! FUCK!

1 - When it's a @gmail account NOT present in system settings --> the user has to enter a password anyway, since the account is NOT in system settings, the user is not signed into it, Android is not aware of the account.

--> No benefit from the change

2 - When it's @gmail account which IS present in system settings -> I have a checkbox to still use "web based login" because Google Play Services assisted OAUTH sometimes, for some users, gives network errors on mobile networks.

--> No benefit, may make the "web based login" workaround impossible -> users get network errors from Google Play Services -> nobody's going to fix those

3 - And when it's an account present in system settings -> the user does not select "use web based login", so it's the default flow -> it authenticates via Google Play Services, with no need to enter the password

--> No benefit

But hey look at those enthusiastic comments!

"the outdated method of using embedded browsers for OAuth"

Simple as that. Just use the word "outdated" -> magic!

[StR]

Kostya,

Please excuse me for providing my amateur-ish thoughts about this.

I was reading that news a few hours ago, and was thinking about it.
I have very mixed feelings. I immediately understood that most likely it would affect (break) Aquamail, which was unpleasant. So, I understand your reaction.

My other thought was that Google is making sure people are entering all their google accounts into the device, so that it is easier for Google to cross-track multiple accounts.

As for people's reaction and sentiments, I think it is all about who (and how) people trust.
Some (many?) people trust Google unconditionally and without limits. (I've always been surprised by that.) So, [at least] for [some of] them, OAUTH is the way to authenticate with Google in the apps without giving the app their credentials. I might be wrong, but I think their are grossly misguided: that is a false "security". Either you trust an app (taking into account the permissions it has, especially on pre-5.x Android where you have no selection of the permissions you allow or don't allow), and then you install it, or you don't trust it, and you shouldn't install it at all.
E.g. if the app has "access to accounts on the device", my understanding that it can do a bunch of things on behalf of those accounts (is this right?), - even those that it didn't create in the first place.
If the app can "draw over the screen/other apps", it can easily spoof other apps' dialogues, and snatch authentication credentials.
So, the argument that an app can, in principle, intercept the web-view-based window is probably correct (?), but that app is likely able to do other malicious things.

In my opinion, the overall security design in Android is broken, where users have to allow the apps "all [what is requested] or nothing". It would've been ok in 90's. But today, I would think a much more secure design would be to run apps in their own "jails"/"sandboxes". I understand that it would've made coding apps (and Android itself) more difficult. But it would've improved the security of the devices that we trust with our private communication, banking, etc. But I digress.

[Kostya Vasilyev]

StR:

Yes, "either you trust the app or not" -- I suppose they're trying to prevent apps from stealing passwords right from the login page, this would be bad, providing access to all of user's data, and not just the requested "scopes" (with OAUTH, you get fine-grained access just to certain things).

But you're right, a malicious email app could do all kinds of bad things if its developer wanted to... This one doesn't, but it's technically possible.

Then again, email apps are not really their most common use case -- it's mostly for apps that need access to basic info (user's email and name maybe), think of "login with Google" into all kinds of apps / web sites.

And then it's strange, since for those, there are Google Play assisted APIs / functions which don't use a WebView at all and are fully integrated with system accounts, i.e. the user doesn't need to re-enter the password, and the user's "main Gmail account" should be just fine.

On the technical side, not all Android devices have Chrome installed (one of those new preferred methods is using Chrome Tabs, where you can run a Chrome tab / window inside your own app's UI). Amazon tablets, maybe Xiaomi devices, etc. I think Chrome is pre-installed only since 4.4 or so and maybe can't be installed on lower Android versions (AquaMail supports 4.0.3+).

So this is going to leave a fairly large number of users not able to add @gmail accounts which don't already exist in system settings.


In a broader context, I think Google's "losing it" maybe for the last 1-2 years.

My impression, from the outside, is a lot of times there are groups each with its own agendas, surfacing, struggling for power, advancing those agendas and ignoring the context and the impact. Think Material Design, Doze Mode, now this.


But then again, look at Yahoo.

They've recently started blocking password-based login (for email), the preferred way is OAUTH2, OK, fine, I'll be happy to implement, but...

... there is NO WAY to register an OAUTH app (with Yahoo) and include "email access" in its OAUTH scopes.

Already a few messages on their developer forums, still no response and no solution.

This one is a different kind of screw-up though, people just not dotting the i's and not even aware of it, a more typical corporate screw-up I suppose. Still, not good.

[StR]

Yahoo seems to be falling apart.
That's a pity. It was a good company in the early days. I used to know some developers from there.

[Kostya Vasilyev]

If only they would just fall apart and stop breaking more things!

Just look at all the mail app developers ready to add OAUTH (since it's now required) and not able to:

https://developer.yahoo.com/forums/#/categories/oauth-and-openid

[Finferlo]

The same for me...

Push email is not working for me at the moment.  Just so my understanding is clear, does Push email work with an Exchange account configured via EWS? If yes, what are the proper settings to enable Push email?  My current settings are illustrated in the pictures below.  Thanks in advance to anyone offering suggestions and/or assistance.

[Kostya Vasilyev]

@Finferlo

To enable, long press the account -> options and folders -> enable "Push mail".

This will switch the "messages to sync" to "14 days" (it has to be a "days" value if you use push).

If still not working:

I'd need to see a debug log. Please see the link in my signature for instructions and be sure to enable "raw session data".

Then leave the log enabled for 1-2 hours and send me the fine.

[dcortez]

.
Re: Looks like company IT policies are keeping push sync from working visa EWS

Um, did you ask them about it and this is what they said? And how is this related to access / control of your phone?

I *think* that your Exchange server may have something called "push subscriptions" turned off, this is a feature of Exchange that Aqua requires (for push mail).

By IT policies, I meant internal company policies and procedures not MS Exchange (software policies). My employer requires installation of third-party software that validates the device meets internal IT policies.  If the third-party software is installed and your device complies with internal policies, push e-mail works. Regarding access to my phone, with the third-party software installed, my employer can wipe my phone (including all internal and SD card data) and block access. Will maintain status quo, e.g., use Aqua Mail to check via 15 minute intervals. Not pushing my luck.



Sent from my SM-N930F using Tapatalk

[Kostya Vasilyev]

Re: By IT policies, I meant internal company policies and procedures

Got it. Thanks.

You should still be able to benefit from my recent Exchange work if you leave the "messages to sync" setting at a "number of DAYS" type value -- this uses "incremental" sync, just the changes every time, faster, lower traffic and battery use compared to the older AquaMail versions.