Re: Never send user email address in HTTP requests

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> 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 <monnier@iro.umontreal.ca>
> 
> Eli Zaretskii <eliz@gnu.org> 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.