From: Fabio Natali via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 74218@debbugs.gnu.org, rpluim@gmail.com, me@eshelyaron.com,
stefankangas@gmail.com
Subject: bug#74218: [PATCH] Ask confirmation before sending region to search engine.
Date: Thu, 07 Nov 2024 14:04:46 +0000 [thread overview]
Message-ID: <87cyj7gmwx.fsf@fabionatali.com> (raw)
In-Reply-To: <86v7wzp8a7.fsf@gnu.org>
Hi Eli,
Thanks for getting back to me.
On 2024-11-07, 13:56 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Fabio Natali <me@fabionatali.com>
>> 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 <eliz@gnu.org> 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
next prev parent reply other threads:[~2024-11-07 14:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 0:46 bug#74218: [PATCH] Ask confirmation before sending region to search engine Fabio Natali via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-06 12:34 ` Eli Zaretskii
2024-11-06 13:18 ` Fabio Natali via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-06 13:38 ` Eli Zaretskii
2024-11-06 15:27 ` Fabio Natali via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-07 1:51 ` Stefan Kangas
2024-11-07 8:42 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-07 8:53 ` Eli Zaretskii
2024-11-07 9:02 ` Robert Pluim
2024-11-07 10:49 ` Eli Zaretskii
2024-11-07 11:03 ` Robert Pluim
2024-11-07 11:05 ` Eli Zaretskii
2024-11-07 11:19 ` Robert Pluim
2024-11-07 11:29 ` Fabio Natali via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-07 11:56 ` Eli Zaretskii
2024-11-07 14:04 ` Fabio Natali via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-11-07 9:12 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-07 10:52 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cyj7gmwx.fsf@fabionatali.com \
--to=bug-gnu-emacs@gnu.org \
--cc=74218@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=me@eshelyaron.com \
--cc=me@fabionatali.com \
--cc=rpluim@gmail.com \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).