#181 Auto-saved drafts can accidentally be saved unencrypted

When writing an email and taking some time for it, Thunderbird's auto-draft feature saves a draft of that email in the "Drafts" folder, which may be located on the IMAP server.

Thunderbird recognizes the OpenPGP setup and opens a confirmation dialog, as attached:
"Do you want to encrypt the message before saving"
- "Do _N_ot Encrypt Message"
- "_E_ncrypt Message"

The problem now is, that it may happen (and it already happended to me) that this dialog pops up when the user is currently typing in text.
When the user types in the letter "n", like in "and", the dialog closes and the message is saved unencrypted in the Drafts folder. The user may not even notice that this happened.

[Patrick Brunschwig]

Your observation is correct. I'll have to see if it's possible to disable alphanumeric keys. However, it is certainly impossible in Mozilla to disable the Return key for a dialog.

[Anonymous]

I vaguely remember there was a time when I was using Firefox under Microsoft Windows where Firefox would exhibit the following behavior when downloading a potentially malicious exe-file:
The open-file-dialog would open up, but the "Open" button would be grayed-out,
not possible to accidentally click on it.
Only after a short time intervall of say maybe 3 seconds passed without the user clicking somewhere or typing in text, the "Open" button would be made accessible again. Thus, firefox prevented the user from accidentally clicking on "Open" or accidentally using a key for selecting "Open".

I guess the above behavior was chosen deliberately for such a situation where the user must be intercepted from his current workflow. A similar behavior for Enigmail should be sufficient to solve this issue.

[Anonymous]

A different solution would be to make encrypted mails inside the draft folder the default, by adding an option under account-preferences "Encrypt draft-messages", which is checked by default. So you would have to opt-out of it if you wanted unencrypted draft-messages.
This solution would
- be simpler to implement,
- be secure by default,
- yield a better user experience (the annoying dialog pictured above would be gone).
The drawbacks would be that
- the user would have to enter his passphrase when he wants to continue a draft-message, and
- if the user has distinct machines, some with his private key, some without it, he will not be able to continue editing the draft on machines without the private key.

Imho, these two drawbacks are neglectable.
First, if he uses OpenPGP, then he is willing to type in his passphrase for additional security. Or he has his passphrase cached anyways.
Second, I believe the scenario I described above with distinct machines is not occurring very often. The user usually knows that he wants to have a draft on some other machine and takes care of this transfer himself.

This is why I suggest this second approach.

[Patrick Brunschwig]

Ah, right, disabling the buttons for a few seconds is a good idea.

[Patrick Brunschwig]

I decided to follow your suggestion and implement a per-identity default for encrypting drafts. Default is true