From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.devel Subject: Re: gmail+imap+smtp (oauth2) Date: Thu, 12 May 2022 01:38:52 +0200 Message-ID: <87lev7iqr7.fsf@logand.com> References: <871qxbdulc.fsf@mat.ucm.es> <87k0b2tkg1.fsf@mat.ucm.es> <87zgjx4qhs.fsf@gmail.com> <87bkwcgmr3.fsf@mat.ucm.es> <87levfzqj2.fsf@yale.edu> <871qx7scvi.fsf@gmail.com> <87v8ujqec5.fsf@logand.com> <87ee172fjz.fsf@gmail.com> <87a6bur4z7.fsf@logand.com> <871qx6e96v.fsf@gmail.com> <87r151q3o1.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29481"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theophilusx@gmail.com, jorge@democraciareal.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 12 01:41:41 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1novxc-0007V4-Sw for ged-emacs-devel@m.gmane-mx.org; Thu, 12 May 2022 01:41:40 +0200 Original-Received: from localhost ([::1]:56142 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1novxb-0000i4-9B for ged-emacs-devel@m.gmane-mx.org; Wed, 11 May 2022 19:41:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1novvC-00062W-D8 for emacs-devel@gnu.org; Wed, 11 May 2022 19:39:10 -0400 Original-Received: from logand.com ([37.48.87.44]:56778) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1novv8-0005VK-Vy; Wed, 11 May 2022 19:39:08 -0400 Original-Received: by logand.com (Postfix, from userid 1001) id 2EDDD19FFF8; Thu, 12 May 2022 01:38:54 +0200 (CEST) X-Mailer: emacs 27.2 (via feedmail 11-beta-1 I) In-Reply-To: Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:289652 Archived-At: On Wed 11 May 2022 at 05:04, Richard Stallman wrote: > > > Our concern is whether the Oauth2 protocol can be used to communicate > > > with Gmail without using any non-libre software. > > > oauth2 mandates whitelist of allowed clients > > the issue is getting on and staying on that whitelist controlled by google > > There is a leap between the concern I mentined and your reply. > I don't know how to relate the two. I think Oauth2 protocol could theoretically be used to communicate with Gmail without using any non-libre software. Writing an oauth2 client software is not that difficult. But having an oauth2 client software is useless without having the software on a whitelist. In the case of gmail, on two whitelists. 1) client_id whitelist oauth2 requires the client_id parameter. It means getting the software whitelisted by X. Who X is depends on the use-case. It is not clear to me yet, who X is in this particular use-case, Google or the school/university? oauth2 says client_id should be secret. Having the client_id public would obviously break the whitelist. 2) application id whitelist In case of gmail, google apparently requires the application id parameter. Google T&C apparently says application id should be secret. Having the application id public would obviously break the whitelist. This is not a problem for services where there usually is a business incentive to put those parameters on the whitelist(s) and keep those values secret, per service. In case of programs, this gets problematic. For example, what is an application for the purpose of application id? If oauth2 client software was a standalone program, would it be a value specific to that program? Or would it be a value specific to the actual mail client, e.g. gnus? Would each fork (what would that mean exactly?) need to get own application id? Etc Some people suggested ignoring Googles T&C, citing Thunderbird as precedent. That seems wrong. The way to comply for a program seems that each user should get his own application id. Likely inconvenient, that is why they decided to ignore (or dispute?) Google T&C and apparently publish the application id. What incentive would an organisation have to deal with whitelisting programs? Similar for client_id.