From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Making GNUS continue to work with Gmail Date: Sun, 16 Aug 2020 08:17:30 +0000 Message-ID: References: <878sf9c69y.fsf@gnus.org> <871rkw62t3.fsf@gnus.org> <87bljki71n.fsf@mat.ucm.es> <87364wxlec.fsf@gnus.org> <87imdsgmlw.fsf@mat.ucm.es> <871rkfhkhc.fsf@mat.ucm.es> <875z9p5hnc.fsf@mat.ucm.es> <87364pbkn0.fsf@gnus.org> <87lfihe0zf.fsf@mat.ucm.es> <874kp55l8t.fsf@gnus.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27538"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.21 (NEB 202 2017-01-01) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 16 10:18:23 2020 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 1k7Dry-00072k-Rg for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Aug 2020 10:18:22 +0200 Original-Received: from localhost ([::1]:40066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7Drx-0007Cw-U7 for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Aug 2020 04:18:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52938) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7DrT-0006hH-F6 for emacs-devel@gnu.org; Sun, 16 Aug 2020 04:17:51 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:63982) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7DrR-0001Bo-6U for emacs-devel@gnu.org; Sun, 16 Aug 2020 04:17:51 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 07G8HXLw023688 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 16 Aug 2020 08:17:33 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 07G8HXo5010352; Sun, 16 Aug 2020 08:17:33 GMT In-Reply-To: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/16 04:17:37 X-ACL-Warn: Detected OS = ??? 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 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:253837 Archived-At: > > > The latter. Basically each user has to log in to the google developer > > 'console' with a web browser and register themselves, and then perform > > a set of steps to generate an OAuth2 token. > > I posted, around a week ago, why that is a bad approach (not merely > inconvenient). > I'm not sure to what message you refer, but I guess it is the following one, dated from August 7th: > > Does that web page function using nonfree software? (Javascript code, > for instance?) Knowing Google, I suspect that it does. > > If so, we cannot distribute that function, or suggest to users that they > use that page, or have code in Emacs which presumes that they do. > > This is a fundamental moral principle of the GNU Project: we hold that > running a nonfree program is never a legitimate solution to any problem. > > We cannot impose that principle on anyone, and we do not try; but we > have a duty not to speak in a way that contradicts it. > > It might be possible to write free code which talks to that page using > some (perhaps undocumented) API and avoids that issue. That would be > good. > This is not possible. There are only two solutions (each user creates their own OAuth credentials as if they were a developer of a different app, or the developer creates OAuth credentials and shares it with all users of the app), but in both cases this will involve nonfree software, by the user in the first case and by the developer _and_ the user in the second case. With the solution used by Kmail, Thunderbird and others, when a user adds a Google account to their mail client, a Google login page is opened in a browser, on which they indicate their login and password. This page is the https://accounts.google.com page, and it uses nonfree JavaScript code. As you write, it might be possible, at least in theory, to write free code which would behave as if it were a browser, thereby avoiding to run the nonfree code from Google. But this would be very hard to do, and it would be a fragile solution, because this code is itself not on API, so Google is free to change it at any time. Moreover Google has likely implemented ways to detect on their side that it is indeed their code that is run in a compatible browser, and to trigger a CAPTCHA request when this is not the case. Gregory