[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making GNUS continue to work with Gmail

From: David De La Harpe Golden
Subject: Re: Making GNUS continue to work with Gmail
Date: Mon, 17 Aug 2020 17:05:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]