From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [ Date: Thu, 28 Nov 2019 08:30:27 -0800 (PST) Message-ID: References: <20191117113054.49837.qmail@mail.muc.de> <87y2wexsv1.fsf@telefonica.net> <20191118175639.08d02820@jabberwock.cb.piermont.com> <874kz0pa9y.fsf@gnus.org> <87sgmjyn60.fsf@gmx.de> <87imnezyt5.fsf@gmx.de> <481a1f16-d661-0f96-2f45-3d5ec9c1132e@yandex.ru> <871ru0t7p8.fsf@gnus.org> <7a7f8955-ec5f-4e1e-b258-19379588516a@default> <86sgmftq1m.fsf@zoho.eu> <87a78k8mka.fsf@osv.gnss.ru> <868so4bdsi.fsf@zoho.eu> <8736e9h7m1.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="93176"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Richard Stallman , Emanuel Berg , Emacs developers To: Stefan Kangas , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 28 19:56:30 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iaOxp-000O6h-OZ for ged-emacs-devel@m.gmane.org; Thu, 28 Nov 2019 19:56:29 +0100 Original-Received: from localhost ([::1]:52374 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaOxl-0003Oh-O9 for ged-emacs-devel@m.gmane.org; Thu, 28 Nov 2019 13:56:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37680) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaMii-0000nQ-8Q for emacs-devel@gnu.org; Thu, 28 Nov 2019 11:32:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaMib-0004rM-Ih for emacs-devel@gnu.org; Thu, 28 Nov 2019 11:32:39 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:42492) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iaMib-0004ep-7R; Thu, 28 Nov 2019 11:32:37 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xASGTmfn048214; Thu, 28 Nov 2019 16:32:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=xEPOGP2HwW2eLvYVgtONc1XOZlmAdYBuE+2h7QhGJ64=; b=au1oHWN6MnuaaOaA6PhfOEyNvMLQ29/XaNs23HyIAtCG+FulAfSBfkMPqQaZuLWG/a/4 muNNduVLR2bqF1iXkoOxk46da0ZocruPz5Jm8Pk/Q1UOprx4xSxsrou407jmZcoMYFie yJNQF5pexqk8sb/S39Y69q3/KGGjAlLIRDkXmdi77DuL3tC9GCBJFRrKpP3/S9jm9IYY ENeJTtG1ycaYP44rR0dMRTbR0qciFTDbc2nktDk/7SZgylWwXSBhYE94jSAInVcxn78m YxyUf5OZnQcM1vGjFBWnFiLLBAMXXrsAHJycvTZ7rkTGEN1GN8RFsEITfe7lBpjeH7Vh bw== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2wev6umeq5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Nov 2019 16:32:31 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xASGUA1D069202; Thu, 28 Nov 2019 16:30:30 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2wjh10sry4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Nov 2019 16:30:30 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xASGUSLx019723; Thu, 28 Nov 2019 16:30:28 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4927.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9455 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=829 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911280139 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9455 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=882 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911280139 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:242841 Archived-At: > > The "Recent messages" bit in the bug reports is a bomb just waiting > > to blow up. At some point somebody will be doing some mining of the bu= g > > repo for "interesting" messages and do a write-up of how horribly lax > > the GNU project it with people's privacy. >=20 > I agree. We should not automatically include potentially sensitive > user data in bug reports. We can ask for it in the (presumably rare) > cases when we do need to see those messages. >=20 > How about the attached patch? 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?