Re: [Imap-protocol] Seeking clarity on Gmail "Access for less secure apps" setting for non XOAuth2 access

On 08/29/2014 04:53 PM, Brandon Long wrote:
> I certainly don't want to treat this list like a Gmail specific list, 
> so it hasn't occurred to me to broadcast any of our changes to this 
> list specifically.
>
> And we did reach out to our larger clients, assuming we knew who they 
> were and how to reach out to them.... sending us the ID command is 
> certainly helpful in that instance to know who are larger clients are.

It doesn't need to be this list specifically.  I'm fine with joining a 
Gmail IMAP specific list or subscribing to a specific blog feed. It's 
even fine if it's a read-only announcement list or blog with comments 
turned off.  Gmail is a significant player in the mail server space and 
I don't think you'll hear a lot of complaints from people in the IMAP 
space being kept too up-to-date.  (Unless the 'status page' feed for 
Gmail gets forwarded!)


> Unfortunately, the bad guys aren't waiting for the standards to be 
> written.

I want to reiterate that I understand this and strongly agree with 
this.  Compromise of a user's email account is an extremely serious 
problem since not only is it used for private communication, it's also 
the gateway to compromise of the user's other accounts and a means of 
performing subsequent social engineering attacks on everyone they know 
or could potentially know.

My request is not that Google/Gmail slow down their protection of users, 
just more provide more updates with ideally a little more detail.  If 
the announcement has to come after the change or the details need to be 
a little nebulous, that's also okay.  Just knowing that the automated 
abuse-detection features are involved is useful, and hopefully doesn't 
provide would-be attackers with information they hadn't already figured out.

For example, we already explicitly detect the Gmail specific "NO 
[ALERT]" cases of things like the following:
- Application-specific password required
- Your account is not enabled for IMAP use.
- IMAP access is disabled for your domain.
and want to better handle:
- Please log in via your web browser: 
http://support.google.com/mail/accounts/bin/answer.py?answer=78754 (Failure)

I believe this new failure adds another specialized error code (and 
regrettably, we screw up here, mea culpa.)

Knowing what the string would be, whether it's localized, etc. would be 
handy.  We do these detections to try and provide appropriately 
localized error messages that might provide better context to the user 
and differentiate between persistent failures and transient failures 
(ex: NO [UNAVAILABLE]), although I should be clear these are 
insufficiently researched hacks.  I don't know if these strings are 
actually localized based on the user's locale or if they're always 
English and the URL is expected to do the localization fix-ups.

It's definitely clear we did the wrong thing for gmail, and maybe in 
general for ALERT, because even if there are other servers that might 
use ALERT in ways that are annoying to users if done naively, it's 
clearly not the case for gmail.  At the bare minimum we will make sure 
to detect and expose URLs in the errors in the future.


> Our abuse team is handling this, and so I'm not directly involved and 
> don't know the specifics to your questions.  I'll forward this to them 
> to see what we can say.

Thank you very much!


> I'm not really sure why the developer docs would link to the "how to 
> avoid using this" support page... I guess I can suggest it.

Apologies, I think I meant to link the page 
https://developers.google.com/gmail/oauth_overview instead of its 
child.  (Its heading in the sidebar is "IMAP and SMTP" but the page is 
"oauth_overview, which is how I got confused amongst my too many tabs.)

I don't mean this in a "how to avoid using this" context.  Mainly, I 
think it would be handy if it conveyed something like:

- If you don't use OAuth2, we will, to protect our users who are also 
your users, require users not using 2-factor authentication to 
explicitly enable support for plaintext logins via the Google Accounts 
Settings page.  Authentication will fail with a NO [ALERT] error that 
links to the support page 
https://support.google.com/accounts/answer/6010255?hl=en.

The goal is that if a client developer has a user who runs up against 
this problem, they can find some documentation on what's going on.  And 
if they're a new developer, they can be aware of the ramifications of 
cutting corners with security.  Importantly, they can do that during 
their planning stage too, not just after they implement it.

(And likewise on the support page side, linking to the XOAuth2 docs / 
elaborating on what makes an app "less secure" and how they can address 
it is also handy, just in that on the web it's not that hard to support 
statements that might otherwise be interpreted as FUD. I've already used 
the feedback mechanism to relay that, however.)


> Also, is the Gaia email app open source as well, ie is it something 
> you can reasonably use OAUTH2 with today?

Yes, the Gaia email app is open source[1].  And we are absolutely going 
to implement this on trunk/master over the next few weeks.  It was on 
our to-do list before the blog post, its priority went way up after the 
blog post, but unfortunately I made the wrong inferences from reading 
the blog post and so its relative priority still ended up beneath 
addressing some crasher blockers and other technical debt fires.

My concern and interest in how this affects our already shipped apps is 
because we are in the embarassing position where we are not currently 
able to to easily update the core Firefox OS apps that ship on the 
devices until a full Firefox OS upgrade version is released to phones 
via an over-the-air update.  Having more information lets us know how 
much of a problem this will pose to users of shipped devices and how 
much support can help affected users versus how hard we need to push on 
getting mitigating patches and/or smaller over-the-air updates rolled out.

As always, thanks for the quick response!
Andrew


1: And as of the last day or two our IMAP and SMTP protocols are now 
built on whiteout-io's open source mail library underpinnings as 
documented at http://emailjs.org/.  Woo!  (AKA a bunch of technical debt 
has now been addressed! :)
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol