From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Making GNUS continue to work with Gmail Date: Sun, 16 Aug 2020 15:27:10 +0100 Message-ID: References: <87v9ienz6c.fsf@gnus.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5439"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 16 16:27:49 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 1k7JdT-0001Hk-Tc for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Aug 2020 16:27:47 +0200 Original-Received: from localhost ([::1]:50974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7JdT-0000sD-02 for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Aug 2020 10:27:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47076) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7Jcz-0000SE-Vu for emacs-devel@gnu.org; Sun, 16 Aug 2020 10:27:18 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:42578) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7Jcx-0003hx-0y for emacs-devel@gnu.org; Sun, 16 Aug 2020 10:27:17 -0400 Original-Received: from [192.168.1.103] (87-198-55-78.ptr.magnet.ie [87.198.55.78]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA 4" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id 59B1A3C07F for ; Sun, 16 Aug 2020 14:27:12 +0000 (UTC) In-Reply-To: <87364pbkn0.fsf@gnus.org> Content-Language: en-US Received-SPF: pass client-ip=65.99.215.13; envelope-from=david@harpegolden.net; helo=harpegolden.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/16 10:27:12 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] 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, URIBL_BLOCKED=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:253847 Archived-At: On 14/08/2020 11:13, Lars Ingebrigtsen wrote: >> *2. What Thunderbird does data point, and not just a google problem: > [...] >> Google, Yahoo, Mail.ru, Yandex, Aol and Microsoft >> >> https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2Providers.jsm#51 > > I guess it would be rude for Emacs to just use those credentials. :-) > Heh. Considering it for a sec, even if "borrowing" such other known client id and impersonating them is technically possible (in rough hypothetical, haven't looked what thunderbird registered in depth, particularly its redirect), it is not really viable in terms of ordinary user expectations: users would then presumably be asked a very confusing and suspicious "mozilla thunderbird wants access to your gmail email account, allow?" or something along those lines in their browser during the rfc8252 flow (if implemented) in what is actually a gnu emacs sign in, and an attentive user would presumably immediately abort and worry. Does remind me that different emacs-external elisp packages available from melpa etc. can (and might well already) have different client ids for various providers statically embedded for their own use. Of course that's pretty much just Not GNU's Problem in legal terms so long as they don't make their way into official emacs (+elpa) sources, just wanted to make a pedantic point that it's not 1:1, different things happening to run within a user's emacs can certainly have distinct client registrations even for the same provider at least technically.