GNU bug report logs - #39185
[PATCH] Don't include section "Recent messages" in bug reports

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39185 in the body.
You can then email your comments to 39185 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Don't include section "Recent messages" in bug reports
Date: Sun, 19 Jan 2020 00:58:18 +0100

[Message part 1 (text/plain, inline)]

Does anyone object to installing the below patch on master?

See here for background:
https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01099.html

Best regards,
Stefan Kangas

[0001-Don-t-include-section-Recent-messages-in-bug-reports.patch (text/x-diff, inline)]

From 74d5b879b42a7f3084910eda74b2b733ebe8984a Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas <at> gmail.com>
Date: Thu, 28 Nov 2019 10:30:30 +0100
Subject: [PATCH] Don't include section "Recent messages" in bug reports

* lisp/mail/emacsbug.el (report-emacs-bug): Don't include "Recent
messages" since it has privacy implications.
Problem reported by Lars Ingebrigtsen in:
https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01099.html
---
 lisp/mail/emacsbug.el | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
index fea7619b50..e4534746dd 100644
--- a/lisp/mail/emacsbug.el
+++ b/lisp/mail/emacsbug.el
@@ -320,18 +320,6 @@ report-emacs-bug
     (let ((os (ignore-errors (report-emacs-bug--os-description))))
       (if (stringp os)
           (insert "System Description: " os "\n\n")))
-    (let ((message-buf (get-buffer "*Messages*")))
-      (if message-buf
-	  (let (beg-pos
-		(end-pos message-end-point))
-	    (with-current-buffer message-buf
-	      (goto-char end-pos)
-	      (forward-line -10)
-	      (setq beg-pos (point)))
-            (terpri (current-buffer) t)
-	    (insert "Recent messages:\n")
-	    (insert-buffer-substring message-buf beg-pos end-pos))))
-    (insert "\n")
     (when (and system-configuration-options
 	       (not (equal system-configuration-options "")))
       (insert "Configured using:\n 'configure "
-- 
2.20.1

Message #8 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Kangas <stefan <at> marxist.se>, 39185 <at> debbugs.gnu.org
Subject: RE: bug#39185: [PATCH] Don't include section "Recent messages" in bug
 reports
Date: Sat, 18 Jan 2020 18:21:05 -0800 (PST)

> Does anyone object to installing the below patch on master?

I do.  What if a user wants to include that info in a
particular bug report, e.g., where it's relevant?
Why not make it easy for a user to include it, even
if by default it's excluded?

As I made clear in the thread you cite:

 It's not just about "Recent messages".  It's about
 anything we automatically insert into the report,
 which a user might not pay attention to, or even if
 she does, which she might not want to send.

 Let users decide.  A simple option takes care of
 this.  And separating the parts of the code that
 insert each different part of the automatic info
 means that we can also give users commands to
 insert any of them as one-offs, to override their
 chosen default preferred behavior.

 I see no reason why we wouldn't want to let users
 decide, in this regard - whether it's about privacy
 or any other reason a user might have for her
 preference.

 What's the difficulty or downside to doing this?

I agree with not including recent messages by
default.  My suggestion is to make it easy for a
user to:

1. Include/exclude any of the various parts that
   we currently exclude, by setting their own
   preferred default behavior.

2. Make it easy for a user to include/exclude any
   such parts for any given bug report, i.e., to
   include/exclude something different from what
   they choose as their default preference.

Anything you do in a hard-coded way makes it more
difficult for users.  It's good for Emacs to remove
recent messages _by default_.  It's better to go
further and make it easy for users to get the
behavior they want - generally and for any given
message.

And it's simple to do.  And it makes the Emacs code
more modular - separate pieces handled separately.

I don't see a downside, and AFAICT none was shown.

I don't claim that the code I use for this, or
what I suggest as the approach, is the only good
one.  I do think we can easily, and should, do
better than just remove recent messages.

Message #11 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 39185 <at> debbugs.gnu.org
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Sun, 19 Jan 2020 03:39:41 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

>> Does anyone object to installing the below patch on master?
>
> I do.  What if a user wants to include that info in a
> particular bug report, e.g., where it's relevant?
> Why not make it easy for a user to include it, even
> if by default it's excluded?

I don't think that feature request should stop us from moving ahead
with this potentially serious privacy issue.

If someone later wants to re-add an option to include messages, and
configure the bug reports along the lines you suggest, they are free
to work on that.

Best regards,
Stefan Kangas

Message #14 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 39185 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in bug
 reports
Date: Sun, 19 Jan 2020 17:13:28 +0200

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sun, 19 Jan 2020 03:39:41 +0100
> Cc: 39185 <at> debbugs.gnu.org
> 
> I don't think that feature request should stop us from moving ahead
> with this potentially serious privacy issue.

<rant>
The right way of dealing with these issues is to hide the parts which
could breach the privacy by converting the characters there into
something like "xxx" or "***", and leave the rest of the information
intact.  Instead, we consistently take the easy way out by removing
everything, and thus make the Emacs bug reports less and less useful
for investigating the problems.  Too bad.
</rant>

Message #17 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39185 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Sun, 19 Jan 2020 16:27:45 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> The right way of dealing with these issues is to hide the parts which
> could breach the privacy by converting the characters there into
> something like "xxx" or "***", and leave the rest of the information
> intact.

How would you propose to do that in the general case?

Best regards,
Stefan Kangas

Message #20 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 39185 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Sun, 19 Jan 2020 17:49:35 +0200

> From: Stefan Kangas <stefan <at> marxist.se>
> Cc: 39185 <at> debbugs.gnu.org,  drew.adams <at> oracle.com
> Date: Sun, 19 Jan 2020 16:27:45 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > The right way of dealing with these issues is to hide the parts which
> > could breach the privacy by converting the characters there into
> > something like "xxx" or "***", and leave the rest of the information
> > intact.
> 
> How would you propose to do that in the general case?

I'm not sure I understand what is the general case here.  Each part of
the report that could potentially disclose private information shall
be identified and dealt with.

Message #23 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39185 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Sun, 19 Jan 2020 17:07:09 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I'm not sure I understand what is the general case here.  Each part of
> the report that could potentially disclose private information shall
> be identified and dealt with.

There's little in the *Messages* buffer that isn't potentially private.
For instance, here's the last two lines of mine:

nnimap quimby.gnus.org splitting mail...done
nnimap read 6k from quimby.gnus.org

That could be private information.  It rather sounds like you're asking
us to get rid of the *Messages* buffer altogether.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #26 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39185 <at> debbugs.gnu.org, stefan <at> marxist.se
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Sun, 19 Jan 2020 18:43:52 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Stefan Kangas <stefan <at> marxist.se>,  39185 <at> debbugs.gnu.org
> Date: Sun, 19 Jan 2020 17:07:09 +0100
> 
> nnimap quimby.gnus.org splitting mail...done
> nnimap read 6k from quimby.gnus.org
> 
> That could be private information.

Is it?  Then perhaps the name of the system on which Emacs was built,
and the configuration used to build it are also private?

Message #29 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39185 <at> debbugs.gnu.org, stefan <at> marxist.se
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Sun, 19 Jan 2020 17:47:12 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Is it?  Then perhaps the name of the system on which Emacs was built,
> and the configuration used to build it are also private?

It's possible, but it sounds unlikely.  That it's private which servers
you're talking to is pretty likely, though.

And we've already established that we, as bug processors, have no use
for the data (you thought is was already gone?), it seems odd to spend a
lot of time making the *Messages* buffer less useful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #32 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 39185 <at> debbugs.gnu.org
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Sun, 19 Jan 2020 18:10:52 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> Is it?  Then perhaps the name of the system on which Emacs was built,
>> and the configuration used to build it are also private?
>
> It's possible, but it sounds unlikely.  That it's private which servers
> you're talking to is pretty likely, though.

In the messages buffer, file names, buffer names and email addresses
are some of the concerning examples of private data I've seen.  We
also have to consider that we have no control over what kind of
information third party or user code puts there.

Best regards,
Stefan Kangas

Message #35 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Kangas <stefan <at> marxist.se>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39185 <at> debbugs.gnu.org
Subject: RE: bug#39185: [PATCH] Don't include section "Recent messages" in bug
 reports
Date: Sun, 19 Jan 2020 11:20:32 -0800 (PST)

> >> Is it?  Then perhaps the name of the system on which Emacs was
> built,
> >> and the configuration used to build it are also private?
> >
> > It's possible, but it sounds unlikely.  That it's private which
> servers
> > you're talking to is pretty likely, though.
> 
> In the messages buffer, file names, buffer names and email addresses
> are some of the concerning examples of private data I've seen.  We
> also have to consider that we have no control over what kind of
> information third party or user code puts there.

Yes.

And as I said, the wrong approach, I think, is for
Emacs dev to make a once-and-for-all, fits-all-sizes
judgment as to what is or could be sensitive.

Instead, we should give users themselves a simple
way to express their own preferences.  Let them
(easily) decide what is or could be sensitive.  Let
them decide what information they want to send.

And let them do that easily, (1) by configuring the
reporting profile they want by default, and (2) by
giving them commands/keys to add or remove particular
parts.

Message #38 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 39185 <at> debbugs.gnu.org
Subject: RE: bug#39185: [PATCH] Don't include section "Recent messages" in bug
 reports
Date: Sun, 19 Jan 2020 11:24:32 -0800 (PST)

> >> Does anyone object to installing the below patch on master?
> >
> > I do.  What if a user wants to include that info in a
> > particular bug report, e.g., where it's relevant?
> > Why not make it easy for a user to include it, even
> > if by default it's excluded?
> 
> I don't think that feature request should stop us from moving ahead
> with this potentially serious privacy issue.

It's not about that.  It's not about preventing you
from avoiding such privacy problems.  It's all about
getting those fixed now.  And doing it right, in a
flexible way that covers everything that could - by
users' own determinations - be a privacy issue.

> If someone later wants to re-add an option to include messages, and
> configure the bug reports along the lines you suggest, they are free
> to work on that.

That's the wrong way to deal with this issue, IMO.
It's just punting - kicking the can down the road.

And it's not as if a general solution is somehow
difficult to conceive or hard to implement.  Not at
all.

I really don't understand the myopia that narrows the
focus to trying to decide what is _the_ potentially
private info, and then wants to hard-code its exclusion.

Message #41 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39185 <at> debbugs.gnu.org, stefan <at> marxist.se
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in bug
 reports
Date: Mon, 20 Jan 2020 15:33:46 +0300

On 19.01.2020 19:43, Eli Zaretskii wrote:
> Is it?  Then perhaps the name of the system on which Emacs was built,
> and the configuration used to build it are also private?

If the default contents of the bug report email are short enough, it 
should be easy for the user to scan and decide whether they want to 
remove some extra info manually.

Message #46 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39185 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>,
 drew.adams <at> oracle.com
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Tue, 18 Aug 2020 18:11:47 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I'm not sure I understand what is the general case here.  Each part of
> the report that could potentially disclose private information shall
> be identified and dealt with.

The proposal is to not include any output from the *Messages* buffer.  I
have never found that data interesting when doing bug triage, and it's a
potentially severe privacy violation.

Is it your stance that you don't want to change this behaviour?  If so,
I'll close this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #49 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 39185 <at> debbugs.gnu.org, stefan <at> marxist.se, drew.adams <at> oracle.com
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Tue, 18 Aug 2020 19:31:52 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Stefan Kangas <stefan <at> marxist.se>,  39185 <at> debbugs.gnu.org,
>   drew.adams <at> oracle.com
> Date: Tue, 18 Aug 2020 18:11:47 +0200
> 
> The proposal is to not include any output from the *Messages* buffer.  I
> have never found that data interesting when doing bug triage, and it's a
> potentially severe privacy violation.
> 
> Is it your stance that you don't want to change this behaviour?  If so,
> I'll close this bug report.

My opinion on this is that we slowly but consistently give up more and
more useful debugging information due to privacy considerations.
However, I seem to be the odd one out here, so feel free to disregard
my opinion on this matter.

Message #52 received at 39185 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39185 <at> debbugs.gnu.org, stefan <at> marxist.se, drew.adams <at> oracle.com
Subject: Re: bug#39185: [PATCH] Don't include section "Recent messages" in
 bug reports
Date: Tue, 18 Aug 2020 20:16:31 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> My opinion on this is that we slowly but consistently give up more and
> more useful debugging information due to privacy considerations.
> However, I seem to be the odd one out here, so feel free to disregard
> my opinion on this matter.

OK; I've now applied Stefan's patch to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.