bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Don-t-include-section-Recent-messages-in-bug-reports.patch --]
[-- Type: text/x-diff, Size: 1436 bytes --]

From 74d5b879b42a7f3084910eda74b2b733ebe8984a Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@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

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Drew Adams]

> 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.

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Stefan Kangas]

Drew Adams <drew.adams@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

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 19 Jan 2020 03:39:41 +0100
> Cc: 39185@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>

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Stefan Kangas]

Eli Zaretskii <eliz@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

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Cc: 39185@debbugs.gnu.org,  drew.adams@oracle.com
> Date: Sun, 19 Jan 2020 16:27:45 +0100
> 
> Eli Zaretskii <eliz@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.

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefan@marxist.se>,  39185@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?

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Drew Adams]

> >> 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.

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Drew Adams]

> >> 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.

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Dmitry Gutov]

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.

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefan@marxist.se>,  39185@debbugs.gnu.org,
>   drew.adams@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.

bug#39185: [PATCH] Don't include section "Recent messages" in bug reports

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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