Re: gmail+imap+smtp (oauth2)

[Tim Cross <theophilusx@gmail.com>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I landed on the conclusion that SMTP 
>   > and IMAP should keep working as long as you use app-passwords for 
>   > logging in to your account.
>
> Can you explain what "app-passwords" are?  I have never used Gmail,
> and I don't need to know technical details, but I have to think
> about the ethical implications of this.

Google introduced the concept of app passwords back when they first
implemented 2FA. Basically, they are just a password based
authentication workflow which can be used with applications that do not
support 2FA or oauth2 based authentication and authorisation. Google
generates a long complex password which you can then use to authenticate
instead of your 'normal' password (and 2nd factor for 2FA). The app
passwords cannot be used to login via 'standard' web based mechanisms
(2FA/oauth2). 

You have to log into your google account and enable app passwords and
then generate 1 (or more) app passwords which you then use for imap/smtp
authentication instead of your 'normal' google password. 

Each app password can be given a name - for example, I have one called
'emacs' which is the password I use to connect to imap/smtp from Emacs.
You can view what app passwords you have defined and when they were last
used by logging into your google account and checking your settings
page. You cannot see the actual password though - that is only available
when you first create the password. If you forget it or lose it, you
have to create a new one (and delete the old one of course). 

Google is removing access to imap/smtp using your main google
login/password and will require 2FA and oauth2 for all web based
authn/authz. However, their documentation implies that app passwords
will remain as the standad solution for applications which cannot do 2FA
or oauth2. 

I don't know if app passwords are available for institution/enterprise
google users. It is possible that may be a configuration option and up
to the individual organisations to enable/disable. Google's advice would
be not to enable them unless there is a demonstrated need. Many larger
organisations will just follow Google's advice as they don't want users
using applications they haven't 'approved'.

I don't think there are any significant ethical considerations
associated with app passwords (in addition to those associated with
using Google/Gmail that is). It is likely that setting the app password
via the Google account settings page involves non-free Javascript, but I
think that boat sailed when you initially sign up for a gmail account
anyway. Some will probably have issue with the fact you cannot set the
specific app password and have no insight into the algorithm google uses
to generate the password, which are reasonable criticisms (though
experience has shown many people do better with even flawed password
generators than self selected passwords). At the end of the day, if you
trust Google with your email data, it probably isn't a long stretch to
trust they will generate a reasonably good password