From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Never send user email address in HTTP requests Date: Sun, 17 Dec 2023 14:34:59 +0200 Message-ID: <83il4xj9cc.fsf@gnu.org> References: <8734ybkqf4.fsf@disroot.org> <87sf54q2t8.fsf@posteo.net> <87o7etlzx7.fsf@posteo.net> <83v88xjipo.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4081"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, philipk@posteo.net, akib@disroot.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 17 13:36:34 2023 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 1rEqNl-0000rF-Dx for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Dec 2023 13:36:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEqN3-0007m3-Ut; Sun, 17 Dec 2023 07:35:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEqN2-0007lq-6x for emacs-devel@gnu.org; Sun, 17 Dec 2023 07:35:48 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rEqMz-00067K-NK; Sun, 17 Dec 2023 07:35:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gDZz7qu0wq2WCA22Q8jjMSrVm/rIloR2T55TMZ2EOKA=; b=QKmzHnkSlD6l Vz8QAMaXYJAOkhqyzH5VBMPo9fbEEeZ57LcVW1PgZycDoTCFJK7NzyJPrSFXhKAyl6xIg4LZdHJIC bluinsCPgb7iyIvsj1tBliBfg3RasdQTdBEpiVV+bK3VhmNzqPtdS3AqdSCEO84HTI8XnvjvUe/Jg zlQ29Y5ImLk+TNheY1zt71ylmzT2bYW1TBnIUu9RRb/fkGxS1YZKOruo7zBrun6BtRF7UHrwrfLpD DBKHxXDzArEKlvp/ZDmTdRRzhNiS5UXdYnXXv7rr4Y1gIHnfCgiaZ41+ihc6kQeRGNqGkEFa8L2Lr txHuMbu6NucahFNdd2Pusw==; In-Reply-To: (message from Stefan Kangas on Sun, 17 Dec 2023 04:02:09 -0800) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:313924 Archived-At: > From: Stefan Kangas > Date: Sun, 17 Dec 2023 04:02:09 -0800 > Cc: rms@gnu.org, philipk@posteo.net, akib@disroot.org, emacs-devel@gnu.org, > Stefan Monnier > > Eli Zaretskii writes: > > > It looks like a changeset was installed on master which changes how > > URL behaves in this matter, see commit 346e571230. I'm worried that > > this is a backward-incompatible change which doesn't seem to have any > > way for users to get back old behavior. I think we should provide > > such a way, and I think this change should be called out in the > > "Incompatible changes" section of NEWS. > > Thanks, I moved it to "Incompatible changes". > > The TL;DR here is that I think the issue fixed in 346e571230 is a > serious issue, and that we should not provide a way to get back to the > old behavior. Sorry, but I disagree. Emacs should not second-guess the users, and should certainly NOT force them into what we consider to be the secure environment. It is okay to behave securely by default, but if someone wants to be insecure, for whatever reasons, we should let them have the old, insecure behavior. Certainly when we first change the default, since there's a possibility that something will break for someone due to this change, and we need to let users have a fire escape in those cases, until we get our act together in the next release. > The basic problem is that a mere misconfiguration of `url-privacy-level' > will lead a user's privacy to be fully compromised. > > For example, a typo like: > > (setq url-privacy-level '(eemail)) > > will make Emacs announce your email (that you customized separately, for > Gnus or Notmuch) to the remote server in every HTTP request. If typos are the problem, it should be okay to detect that and holler or signal an error. But the changes disallow even values that have no typos, under the premise that "we know better". I very much object to software that "knows better", and hope Emacs will never behave like that. > In fact, it's enough to customize that setting to anything that is not > `high', `paranoid', or a list containing the symbol `email'. > > You best not assume you can set it to `medium', or anything like that, > because trying that will be _silently_accepted_ and then: your email > will be revealed. That's a pretty huge gotcha, and certainly not the > way to design a security feature. Again: it is okay to refrain from silently accepting invalid values. That's not my concern. In the Emacs where I'm typing this the value of url-privacy-level is (email), and that has no typos. I see no reasons to disallow such values, as long as they are not the default. > But it gets even worse: url.el used to do these acrobatics to make sure > that there is indeed something privacy breaking in there: > > (or url-personal-mail-address > user-mail-address > (format "%s@%s" (user-real-login-name) > (system-name))) > > AFAIK, no other browser out there provide this misfeature. It seems > like something from the happy 1990's that has completely outlived any > usefulness, assuming that it was at all useful even to begin with. > > Providing a way to get back to the old behaviour is just re-introducing > a bad, bad footgun. Keeping it around puts users at risk. So I think > we shouldn't do that. See above: I don't agree to be smarter than everybody. The defaults should be secure, but completely locking out users is not.