From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Fabio Natali via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74218: [PATCH] Ask confirmation before sending region to search engine. Date: Thu, 07 Nov 2024 14:04:46 +0000 Message-ID: <87cyj7gmwx.fsf@fabionatali.com> References: <20241106005544.26516-1-me@fabionatali.com> <86pln8sfqe.fsf@gnu.org> <87ikt0gz7b.fsf@fabionatali.com> <86bjyrqvb0.fsf@gnu.org> <877c9fmn7b.fsf@gmail.com> <867c9fqpx0.fsf@gnu.org> <87v7wzl30n.fsf@gmail.com> <86zfmbpam0.fsf@gnu.org> <87fro3gu3i.fsf@fabionatali.com> <86v7wzp8a7.fsf@gnu.org> Reply-To: Fabio Natali Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12807"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74218@debbugs.gnu.org, rpluim@gmail.com, me@eshelyaron.com, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 07 15:05:32 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t938e-0003DR-FC for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Nov 2024 15:05:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t938D-0006k4-3Z; Thu, 07 Nov 2024 09:05:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t938B-0006jY-5J for bug-gnu-emacs@gnu.org; Thu, 07 Nov 2024 09:05:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t938A-00021m-SQ for bug-gnu-emacs@gnu.org; Thu, 07 Nov 2024 09:05:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=V70D4QVFyPpCocjL9WxlNhybTNAfwl/fK2v0nqZcPOc=; b=DuqgKameo57CWd3rSToOF2OD+Xz9sSAwNrEBbgcioD15Lw22Xg2h2hGveDYtyUh61xN3kPOMXRPLyOIdVX5YR+5KcY3aMvebf06B8n+Elib+pvbhkaDtrX8x83hnNlC/xgUBwGasMrROoVBHlMu3mMZK1uz4kOFs+Dn3bappkMgK4VvGM7W2D43TQoaiXYW758GL6QHTBDshOW8A4cgZ+6EBKtDo8CQpCddodFpkvQxizjFqrKiX8JMJ9eESICqPK4/D2wiURqCZiB7ZUe6kgcmCgLfVD1Dp8XDqHzpz9ykfCd4wZCvt1Yba2ajevKYrZSh5mGxotajF3S1MVU8riw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t938A-0000h1-NG for bug-gnu-emacs@gnu.org; Thu, 07 Nov 2024 09:05:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Fabio Natali Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Nov 2024 14:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74218 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74218-submit@debbugs.gnu.org id=B74218.17309883002642 (code B ref 74218); Thu, 07 Nov 2024 14:05:02 +0000 Original-Received: (at 74218) by debbugs.gnu.org; 7 Nov 2024 14:05:00 +0000 Original-Received: from localhost ([127.0.0.1]:47608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9387-0000gX-8L for submit@debbugs.gnu.org; Thu, 07 Nov 2024 09:04:59 -0500 Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]:35029) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9383-0000gI-Sp for 74218@debbugs.gnu.org; Thu, 07 Nov 2024 09:04:57 -0500 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id E750EE0008; Thu, 7 Nov 2024 14:04:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fabionatali.com; s=gm1; t=1730988289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=V70D4QVFyPpCocjL9WxlNhybTNAfwl/fK2v0nqZcPOc=; b=GOa+EtdWiWlRBxlB1Yzz5E6/e2o8zdJzitpRcQ2nE5ivJbsl1YQmRjEwUG3Yn8U/oCJr8P 5pkoA83xyufc1Hc49KBbHSj1bGguHKF144u6AjSfagp2a5soluVqjeE1RAPXH/I7rCCCJ6 x5QLFzbltSha0FIUAqRqgzx695T+N3pGq8FztrQEnQzCJXD0lupZlucBu6IQwUeLI1cRmD ejerhcG1iFuc414D1+3XNMHOuzxj95Sb0pgQgos/i5/nyCuJBVg0qsElwNoP08bTvIP6pH Gu7DBC2ykFTw052xLsXZz3CHOu+MS+ebcgulXhpZABG1DM8D0UaHe0ogFRSxww== In-Reply-To: <86v7wzp8a7.fsf@gnu.org> X-GND-Sasl: me@fabionatali.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295023 Archived-At: Hi Eli, Thanks for getting back to me. On 2024-11-07, 13:56 +0200, Eli Zaretskii wrote: >> From: Fabio Natali >> Cc: me@eshelyaron.com, 74218@debbugs.gnu.org, stefankangas@gmail.com >> Date: Thu, 07 Nov 2024 11:29:37 +0000 >> >> On 2024-11-07, 13:05 +0200, Eli Zaretskii wrote: >> > My take on it is that the user might not realize that the region is >> > very large and includes parts she didn't intend to send. IOW, a >> > cockpit error. >> >> It's not only that. Commands can be typed by mistake. The fact that the >> command's docstring warns about its effects is not enough. >> >> By default, 'eww-search-words' is bound to 'M-s M-w'. The probability of >> accidentally mistyping that combination is not at all negligible. I did >> discover the command's beheaviour via view-lossage after mistyping 'M-s >> M-w', for example. > > Those are still "cockpit errors", aren't they? True, you're right. What I meant is that there are at least two scenarios that might lead to an involuntary data leak. - I deliberately type 'M-x eww-search-words', it's just that I haven't read how the function behaves, I haven't taken the time to read its docstring. - I clumsily mistype 'M-s M-w' while I wanted to do something else. I suppose they might both fall under the cockpit error umbrella, but they're somehow different. I'm particularly worried about the latter scenario. (Which is what happened to me by the way, so I know this *can* happen.) > Did it happen to you that you typed incorrect phrase into a browser's > search window? Does a browser always unconditionally ask you whether > you really meant that? As I said, there's always a chance to mistype a series of keys, steps, or commands, no matter how long/complicated the combination is. Yes, you're right, I might have copy-and-paste'd sensitive information in my browser's URL bar at some point. However, I think that the data leak risk associated with 'eww-search-words', in its current implementation, is higher that similar other examples and that this should be fixed. I suppose the correct way of going at this would be to involve a security and usability expert to assess the severity of this particular scenario and to compare it to others. I'm not a usability expert, but I do have first-hand experience of fumbling up a 'M-s M-w'! :) >> One might argue that, no matter how long, all sequences of keys and >> commands could be mistyped, but that'd be a bit misleading. I think >> that adding a warning and a yes-or-no confirmation request would make >> 'eww-search-words' sufficiently safe, that's the assumption behind my >> patch. > > You ask a valid question, but don't answer it. Indeed, why would we > treat this particular command differently from others? "Would be > misleading" doesn't provide an answer to the question; instead, it > seems to claim that the question itself is invalid. Why is it? The answer is: because this scenario is more risky. It's easier to mistype 'M-s M-w' as opposed to other commands and the consequences of such mistake are more serious than other commands. It's the very definition of risk, i.e. likelihood times severity. >> As I said above, I don't think that the sensitivity of a block of >> text is a function of its length. Case in point, a password, an >> address, any piece of Personally Identifiable Information. > > Is this the only command which sends user-typed text to the Internet? > I don't think so: the first example I could think about is sending > email. Do we ask the user for confirmation each time the user types > the command to send a message? Why not, and how is this command > different, in the general sense? The way my email client is configured, it takes more steps to mistakenly leak sensitive information. For the sake of argument, if I type 'M-x notmuch-mua-new-mail' when a region is selected, that doesn't lead to that region being sent straightaway to the first contact in my email address book! However, should there be cases similar to 'eww-search-words' I'd be definitely up for having them fixed. You're orders of magnitude more familiar with Emacs than I am, but 'eww-search-words' is the first command that struck me as so risky - we're only a selected region and a 'M-s M-w' away from sending data to a third-party. >> Users can always override the default and might decide to customise >> 'eww-search-words' as they like - but I still think it's important to >> provide a safe default, something safer than what we have today. > > I'm asking why requesting a confirmation in every case is a reasonable > default. It is safe, I agree, but it is also annoying in many cases. If the user makes heavy use of 'eww-search-words', they can still permanently or temporarily disable the confirmation step. But I think that the default should be the safer alternative, not the more convenient (but risky!) one. I hope this brings further context and clarifies my point of view. Thanks, cheers, Fabio. -- Fabio Natali https://fabionatali.com