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: Wed, 27 Nov 2019 07:14:50 -0800 (PST) Message-ID: References: <20191117113054.49837.qmail@mail.muc.de> <87pnhq7mxg.fsf@gnus.org> <87bltaz9g4.fsf@telefonica.net> <834kz25qp9.fsf@gnu.org> <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> 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="148385"; mail-complaints-to="usenet@blaine.gmane.org" Cc: moasenwood@zoho.eu, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 27 16:25:38 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 1iZzCD-000cQp-Fn for ged-emacs-devel@m.gmane.org; Wed, 27 Nov 2019 16:25:37 +0100 Original-Received: from localhost ([::1]:39450 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZzCC-0005Si-0i for ged-emacs-devel@m.gmane.org; Wed, 27 Nov 2019 10:25:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50225) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZzBf-0005L4-Rv for emacs-devel@gnu.org; Wed, 27 Nov 2019 10:25:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZz2I-0007qK-MA for emacs-devel@gnu.org; Wed, 27 Nov 2019 10:15:23 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:47696) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iZz2I-0007oZ-DA; Wed, 27 Nov 2019 10:15:22 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xARFEY2U065218; Wed, 27 Nov 2019 15:15:18 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=9JW7jcRs35Gts0NHRsrQ5trKuiTznXyvr1pvXPwBDgE=; b=HXch4yra4EwpF9quQ3XwJ/ekNnuyaq7307eMWiyMHCkKFibDPfyJ5RAg/4qvY3fx71p3 MISbSQ0pWpbk+IjpVvcfvVbJGK7Kqf1guswRR5+v+azQmcFFHTXaONa8HFZ2kWYk1mu3 1ovr23S3fpPqrcPLcQcx5SyEvnZIazXThIl5ZdZ3pcNLs9nItLF8B4At6BTXzelxODJP u9xm/cIuCnvSRDSoAeFmDcTlLFPMyyXFTkNh3mPxvN3x64ccSGe14Sswbz/T/FoX6x3B otn5Sy0lTAn139JrXQ3eZ8Mu505EAPfuGMuPls59+l3nXtL9QxqQR89/fRbwZCTDQyYP 1Q== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 2wevqqe9qt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Nov 2019 15:15:17 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xARFEYQR055368; Wed, 27 Nov 2019 15:15:17 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 2wgwuupvc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Nov 2019 15:15:11 +0000 Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xARFEpqa009678; Wed, 27 Nov 2019 15:14:52 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=9454 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=29 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=905 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911270133 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9454 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=29 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=965 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911270133 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 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:242792 Archived-At: > > 1. There's an option that lets you choose which > > fields to include by default, when reporting > > a bug: `ebp-report-emacs-bug-included-fields'. >=20 > This would be extra complication, the opposite of what we want in > general. Why? What we have now is no possibility to express your preference of what to include (by default). With the option, if a user does nothing, she gets just what she gets now: everything included. Easy. All the option does is let you, a user, decide what to include by default, should you want to do that. What's the complication? Certainly there's nothing complicated for a user. Who's life is complicated by giving users such a choice? > The specific problem here is that report-emacs-bug includes data that > might be sensitive. The specific problem is that it includes data that some users might not want to send - for whatever reason. And it does so systematically. The only recourse for a user is to manually delete whatever info she doesn't want to send - each time, for each bug report. How is that helpful to users? > It would be good to remind people that they don't > have to send that data, And to tell them what all that data is - the various fields/sources. And to show them where it is (especially because the buffer does not make very clear which text gets sent and which does not (boilerplate instructions/help). Identify the data - point it out. > and help them avoid it if/when they want to. There's currently no way to "avoid" inclusion of any of the text. Users can only delete it manually before sending the message. Avoiding would prevent inclusion in the first place. All we have is after-the-fact, on-demand deletion. > But let's do that in the simplest possible way. The simplest way is to not make the user do anything, to send everything - like now. But to also let a user state her general preference. Let her decide what the default behavior is. Not that every user has to do that, or will want to do that, but that any user can. Alternatives that just point out the fields, or even provide easy ways to delete them, still make users to do that manually. And each time, for each report. How is that simpler and safer for users? > I think the simplest possible way is to identify the data that might > be sensitive, and help users exclude all that data. The best way to help users exclude any data they might want to exclude, by default, is to provide an option that lets them do just that: set their own preferred behavior. What's complicated is making a complicated issue out of this. There's a simple solution that has no effect on any user who doesn't care, and that lets any user who does care get exactly the behavior she wants, by default, and that lets her override her own default for any given report.