bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support


From: David Engster
Subject: bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support
Date: Tue, 19 May 2020 18:00:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

> Maybe a solution could be found for Free Software like Emacs.
> Thunderbird is mentioned as a not-less-secure-app, so they seem to have
> solved this problem to Thunderbird/Google's satisfaction.

No, they haven't. It's just that at the moment, no one cares.

It is pretty obvious that OAuth2 client id/secrets do not make sense in
desktop applications (whether (F)OSS or not), making their whole point
moot. Google admits this much in their documentation, where they say

  The process results in a client ID and, in some cases, a client secret,
  which you embed in the source code of your application. (In this
  context, the client secret is obviously not treated as a secret.)

(see https://developers.google.com/identity/protocols/oauth2)

People took this paragraph as permission to simply put client id and
secret directly into the source code. However, Google *explicitly*
forbids this in their developer TOS:

  Developer credentials (such as passwords, keys, and client IDs) are
  intended to be used by you and identify your API Client. You will keep
  your credentials confidential and make reasonable efforts to prevent and
  discourage other API Clients from using your credentials. Developer
  credentials may not be embedded in open source projects.

(see https://developers.google.com/terms)

The Thunderbird people simply ignore this and do it anyway, but it's not
like they have much choice.

> OK, maybe Google could relax the secrecy requirement for Emacs though,
> since I'd hope they'd be sufficiently Free-Software-friendly to work
> something out.

Google does not care one bit.

The solution to this problem is to choose another mail provider.

-David





reply via email to

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