Re: Making GNUS continue to work with Gmail

[David De La Harpe Golden <david@harpegolden.net>]

On 11/08/2020 17:11, Robert Pluim wrote:

> 
> The alternative is to register an 'Emacs' app, do the hoop jumping,
> and stick the various secret tokens in the Emacs sources, but as I
> understand it thatʼs expressly forbidden by Google's terms-of-use
> (correct me if Iʼm wrong, I haven't read them).


Just looked vaguely into this as a thunderbird and emacs user / 
emacs-devel ghost. I was left seriously wondering how+why thunderbird 
was still working with a gmail account (just a secondary email in my 
case, fortunately), having seen this thread. Anyway, decided to write it 
up and share it in case it's useful.  Sorry for wall of text, tried to 
structure it somewhat:

*1. Non-secret "client secrets".
*2. What Thunderbird does data point, and not just a google problem
*3. End-User supply of and/or override of client id and secret
*4. Technical implementation note, separation of implementation vs 
official id concerns

*1. Non-secret "client secrets":

That  assumption that people including google really think these 
particular "secrets" are real secrets that are required to be be kept 
secret may be false?   Google do appear to recognise and accept such 
desktop app hardcoded static client ids and "secrets" they issue aren't 
actually secret in this case, just some bits anyone can easily snaffle e.g.

https://developers.google.com/identity/protocols/oauth2/native-app

"""
Note: incremental authorization with installed apps is not supported due 
to the fact that the client cannot keep the client_secret confidential.
"""

Regarding "not supported" there - in context that doesn't mean authc and 
non-incremental authz don't work, my point quoting the above was not 
that aspect of it, just that you can see they appear to be well aware 
the so-called client secret is not a secret in any meaningful sense in 
the overall native-app-installed-on-client-desktops flow they are 
talking about.

And let's see the rfc8252 google cite, note it says (quite amusingly):

https://tools.ietf.org/html/rfc8252#section-8.5

""""
Secrets that are statically included as part of an app distributed to
multiple users should not be treated as confidential secrets, as one
user may inspect their copy and learn the shared secret.
"""

And IIUC a near-mandatory protocol extension (pkce rfc7636, 
https://oauth.net/2/pkce/ ) means core security properties are not or no 
longer strongly linked to these particular "secrets" being secret.

=> I think they're not real secrets?  Not to say a lot of attention to 
the legal side wouldn't still be required if an official  client id and 
secret were sought.

Google further apparently doesn't support "dynamic client registration" 
(I think unlike a lot of in-house corporate auth servers using oauth2 on 
intranets as a "modern" kerberos replacement?), so such valid static app 
client ids and secrets can only be obtained via their full web interface 
for issuing and approval workflow, which would certainly still involve 
agreeing to lots of incomprehensible legalese things.

https://stackoverflow.com/questions/36260097/is-openid-connect-dynamic-client-registration-possible-with-google


*2. What Thunderbird does data point, and not just a google problem:

Now, definitely no idea of legalities it happens under either, nor 
advocating emacs should necessarily take the same approach, but as a 
data point, it looks to me like Mozilla Thunderbird (MPL2.0 licensed) at 
time of writing does appear to be simply openly embedding a bunch of 
static oauth2 app client ids and client (non-)secrets for

Google, Yahoo, Mail.ru, Yandex, Aol and Microsoft

https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2Providers.jsm#51


*** If nothing else, seems clear it is already becoming not just a 
google problem.

Presumably someone from Mozilla applied for and got those ids and 
secrets from each provider.

And of course, even if it's legally okay for someone acting for GNU to 
similarly get some static client ids and (non-)secrets issued from 
google (and the others) to similarly embed openly in the GNU Emacs 
official sources, subject to their approval whims whatever they may be - 
and seems like a "pray I do not alter the deal further" scenario, sigh, 
can certainly imagine them just turning it off later. Or turning on 
billing: given google, I'd also be vaguely suspicious about them not 
using it super-maliciously, but being able to use it as a key (in a db 
sense) for trying to charge an app developer instead of an end user,



*3. End-User supply of and/or override of client id and secret:

There is strong precedent there in that the chromium codebase itself 
also supports  env vars setting of arbitrary user-specified runtime 
override api access client ids and secrets when it doesn't have its own 
hardcoded embedded ones compiled in, or if a dev just wants to use 
different ones:

https://www.chromium.org/developers/how-tos/api-keys

I believe e.g. debian doesn't or didn't build their chromium with them, 
but still allows users to supply their own if they want by that mechanism.



*4. Technical implementation note, separation of implementation vs 
official id concerns:

Also to note Julien Danjou appears to have already written an emacs 
oauth2 package:

https://elpa.gnu.org/packages/oauth2.html

(defun oauth2-auth-and-store (auth-url token-url scope client-id 
client-secret &optional redirect-uri state)

(and with the likes of elnode, I guess the open a transient localhost 
port redirect uri flow is viable to streamline token acquisition)

Presumably any emacs implementation for imap access use could easily 
allow for end-user customizable override of either a prepopulated table, 
or an empty table of the required provider, static client id, client 
secret, mappings.

=> the technical side looks doable (especially since a lot of it looks 
already done by Julien) and is not actually google specific (and may be 
useful for both other public providers and private in-house ones in 
companies etc.), it does look to me like the decision of whether to 
implement the facility at all (that may still be playing into their 
hands in a sense of course) could be made independently of whether to 
actually apply for and embed an official static client ids and secrets 
for the various public providers who apparently want one, including, but 
not limited to, google in particular?