141 lines
6.7 KiB
Plaintext
141 lines
6.7 KiB
Plaintext
MBOX-Line: From asuth at mozilla.com Fri Aug 29 17:43:16 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Andrew Sutherland <asuth@mozilla.com>
|
|
Date: Fri Jun 8 12:34:53 2018
|
|
Subject: [Imap-protocol] Seeking clarity on Gmail "Access for less
|
|
secure apps" setting for non XOAuth2 access
|
|
In-Reply-To: <CABa8R6se2WefF4q-cFzR2qtU_5_jDL-wioPF+jPmOTdpCaJhtw@mail.gmail.com>
|
|
References: <5400A146.4020602@mozilla.com>
|
|
<CABa8R6se2WefF4q-cFzR2qtU_5_jDL-wioPF+jPmOTdpCaJhtw@mail.gmail.com>
|
|
Message-ID: <54011E24.4080209@mozilla.com>
|
|
|
|
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! :)
|
|
|