On Wed, May 05, 2004 at 04:38:08PM +0900, invalid@xxxxxxxxxxxxxx wrote:
> I downloaded the latest CVS mutt code in order to get the fix for slang.
> I see that the encryption options menu behaviors have changed... IMNSHO
> they've gone from bad to worse.
Having just sent out an encrypted mail with the wrong options (using a
version of mutt compiled from CVS code from about 2 months ago), I feel
compelled to revisit the issue of the behavior of the encryption
options menus. While this is not a vulnerability in Mutt, it does
constitute a legitimate security issue. Please, please, please
reconsider the behavior of this menu! At least, please consider the
following discussion. I tried to submit it to the BTS but it seems to
be broken again...
The encryption options menu provides the following options (these are
PGP options, but the S/MIME options are similar):
PGP (e)ncrypt, (s)ign, sign (a)s, (b)oth, (i)nline, or (f)orget it?
By looking at these options, I'm not sure how anyone could possibly
get the idea that, for example, pressing (e) to encrypt a message
could actually TURN OFF encryption of the message. I personally find
that this behavior is not only unintuitive, it's completely
counterintuitive and potentially dangerous to the unsuspecting user.
For that matter, it's even dangerous to the suspecting user who's
unaccustomed to this new toggle behavior.
If I press (e) to encrypt, the most obvious interpretation of these
menu options is that encryption will be turned on. I can't see how it
makes sense to use the same key to also turn off encryption. After
all, we have an option for signing, and we have an option to clear all
encryption options (the poorly named (f)orget it option). So why
then, do we also need to toggle? When one looks at this menu, how is
one to glean even a hint that the behavior toggles options? It is
simply not possible. If the user didn't realize that encryption was
already set (i.e. via a sender-hook), then the user must notice that
encryption is not enabled, and press (e) again. The consequences
could be potentially serious... Envision a system administrator who
is under investigation reading accidentally unencrypted details of the
investigation! Many other such scenarios can be imagined...
Especially given that the behavior is a departure from the traditional
mutt behavior, I think it's quite clear that this change is a bad
change and a dangerous change. It is fine to argue that the user
should be careful about verifying encryption options, as this point is
very true. However, users notoriously make this kind of mistake, and
this fact is well known. The design of the software should,
therefore, be such that it is hard for the user to make this kind of
mistake. The current design of this menu fails to do so, and that
failure is a potentially serious security issue for the user who makes
a mistake.
If you really want these options to toggle, then I think the menu is
in dire need of being completely redesigned so that this behavior is
indicated clearly. However, there is no need to toggle given the
current set of options, because all possible combinations could be
acheived with one keystroke without any toggling. In fact, if the
options toggle, more keystrkes are required to fix them. This is
another reason why this choice of behavior is not a good one. As it
stands, I feel rather strongly that the current behavior exemplifies
bad UI design, and I hope that the above discussion, makes the fact
that it is bad UI design evident to others.
Given the options presented, the most obvious interpretation of what
they do is:
(e) ONLY encrypt the message (i.e. change the options to only
encrypt, regardless of what they currently are).
(s) ONLY sign the message, regardless of current options.
(a) change the key with which to sign, adding the sign option if
necessary
(b) do both, regardless of current options
(i) toggle in-line attachments (but change menu to indicate toggle)
(f) clear the encryption options
(b) currently behaves sensibly, turning on both options, regardless of
what options are set. (e) and (s) do not, which is not sensible, and
also happens to be inconsistent with the behavior of (b). (i) should
toggle, but it should be labeled as a toggle so that this is obvious.
Either that, or two options should be provided: one to turn it on, and
the other to turn it off.
Finally, if you press (f) to clear the options, after doing so the
"Security:" field is shown as "Clear". The choice of the option name
"forget it" is not only a little ugly, but also ambiguous. The name
of this option should likewise be (c)lear, to reflect both what the
option does, and the status that it provides.
Please, please, please reconsider the behavior of this menu!
I also want to encourage other list members to provide feedback about
this issue.
Thanks for listening.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpWlkHpfT096.pgp
Description: PGP signature