Re: Making GNUS continue to work with Gmail

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

On 17/08/2020 08:51, Gregory Heytings via Emacs development discussions. 
wrote:

> (Note that doing this (that is, including an app key in free software) 
> also violates Google's terms of service.  But apparently Google 
> tolerates that these terms are violated by Kmail, Thunderbird and 
> others, so would presumably also tolerate that they be violated by GNUS.)
>

Well, they're legal terms not program code.  Apart from them just 
tolerating/overlooking it, things can also happen between parties under 
terms different to or supplemental to some generic published standard 
terms, Cesar's point that the FSF could talk to Google about it on an 
official basis certainly stands.

The legal side may just not have caught up with evolving native app / 
public client not-a-secret usage anyway, the terms seem more suited to 
traditional server-side web apps, still a common use case for oauth2 
(contrast e.g. [1] and [2]).

I expect it's actually Mozilla and KDE representatives that self-service 
manage their respective registrations via the relevant google api 
console, not Google employees, in their cases,  but it is also possible 
to imagine (however unlikely in practice) Google and the FSF taking a 
different approach and agreeing to a Google employee instead managing 
and issuing on their side some  client id(s) for various uses to the FSF 
i.e. rather than an FSF representative agreeing to the generic terms and 
logging in and self-service managing clients (though that has associated 
loss of self-service control e.g. branding during the auth flow etc).

Then sending the client to the FSF under some sort of alternative legal 
terms along the lines of "actually this here client id can be embedded 
in emacs gnus sources under the GPL, it's fine, despite what those 
generic terms say, Note it will only actually work for oauth2 if auth 
code with pkce and a localhost redirect_uri flow is used. And google may 
also temporarily or permanently cease recognising this client id at any 
time for any reason, and a new client id may or may not be issued".  A 
Google employee contributing an actual source code patch with such a 
client id embedded would make that rather on-the-record.  Not saying 
that is especially desirable or google would be likely to go for that 
option anwyay, just seems another possible in principle thing worth 
mentioning.


[1] https://auth0.com/docs/flows/authorization-code-flow

"""
Because regular web apps are server-side apps where the source code is 
not publicly exposed, they can use the Authorization Code Flow (defined 
in OAuth 2.0 RFC 6749, section 4.1), which exchanges an Authorization 
Code for a token. Your app must be server-side because during this 
exchange, you must also pass along your application's Client Secret, 
which must always be kept secure, and you will have to store it in your 
client.
"""

[2] 
https://auth0.com/docs/flows/authorization-code-flow-with-proof-key-for-code-exchange-pkce

"""
When public clients (e.g., native and single-page applications) request 
Access Tokens, some additional security concerns are posed that are not 
mitigated by the Authorization Code Flow alone. This is because:
Native apps Cannot securely store a Client Secret. Decompiling the app 
will reveal the Client Secret, which is bound to the app and is the same 
for all users and devices.

[...]

To mitigate this, OAuth 2.0 provides a version of the Authorization Code 
Flow which makes use of a Proof Key for Code Exchange (PKCE) (defined in 
OAuth 2.0 RFC 7636).
"""