I have a new idea. If OpenPGP encryption is turned on, but encryption isn't possible for at least one recipient, then as of today, we show a notification with the text "End-to-end encryption requires resolving key issues", with buttons "resolve" and "disable encryption". I suggest we change the text to say: "To use End-to-end encryption, either resolve key issues for ..., or add a password that recipients can use to decrypt the message." and we'd add another button: "add password…". If the user clicks "add password", we'd open a prompt that contains a brief explanation, and gets the users choice for the password. The explanation could say: "Adding a message encryption password allows recipients to decrypt the message, either using Thunderbird or using other OpenPGP compatible software. Use a method other than email to share the password with your correspondents that need it." Below that, I'd offer two choices with a radio button - Use a new randomly generated password: <random password showing here> - Use the following password: [input box] Repeat the password [inbox box] If the user choses to enter a password, the dialog would have to give feedback whether the user has entered a reasonably strong password. The dialog should offer the user to either repeat the password, or use an "eye" icon to view what the user types (in that case we don't need them to repeat it). If the user confirms the dialog, then the composer window changes behavior. The composer will no longer require that valid and accepted keys are available for all recipients. It would no longer warn at all. Rather, when sending the message, it would encrypt using the public keys that are available, and in addition encrypt using the password. (Decrypting will be possible with EITHER the matching private key that a correspondent owns, OR using the password. So the user has to pass on the password only to those recipients for whom no good public key is available.) I'd prefer to visualize in some way this current mode of operation. The visualization should mention something like "message encryption password set". Clicking it should allow the user to view, modify, or disable the message encryption password (while still in composer). In theory, offering this message encryption could work even when the user hasn't set up OpenPGP encryption for themselves. But I think we shouldn't offer it, because it would complicate the UI, it would also be in contradiction to our explanations (which we have in several places) that opting in to email encryption is required by setting a key for the user. We disable the encryption button if the user hasn't yet set up their own OpenPGP key, which would further complicate the UI to get this password based encryption turned on. And finally, if the user (sender) has set up their own encryption key, we'll also encrypt with that key, which means the sender will be able to view the encrypted copy in the Sent folder, even after forgetting/losing the message encryption password. In other words, I suggest: Only if the user is set up for OpenPGP e2ee already, only then offer the user the alternative to encrypt using a password.
Bug 1755650 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I have a new idea for the user interface. If OpenPGP encryption is turned on, but encryption isn't possible for at least one recipient, then as of today, we show a notification with the text "End-to-end encryption requires resolving key issues", with buttons "resolve" and "disable encryption". I suggest we change the text to say: "To use End-to-end encryption, either resolve key issues for ..., or add a password that recipients can use to decrypt the message." and we'd add another button: "add password…". If the user clicks "add password", we'd open a prompt that contains a brief explanation, and gets the users choice for the password. The explanation could say: "Adding a message encryption password allows recipients to decrypt the message, either using Thunderbird or using other OpenPGP compatible software. Use a method other than email to share the password with your correspondents that need it." Below that, I'd offer two choices with a radio button - Use a new randomly generated password: <random password showing here> - Use the following password: [input box] Repeat the password [inbox box] If the user choses to enter a password, the dialog would have to give feedback whether the user has entered a reasonably strong password. The dialog should offer the user to either repeat the password, or use an "eye" icon to view what the user types (in that case we don't need them to repeat it). If the user confirms the dialog, then the composer window changes behavior. The composer will no longer require that valid and accepted keys are available for all recipients. It would no longer warn at all. Rather, when sending the message, it would encrypt using the public keys that are available, and in addition encrypt using the password. (Decrypting will be possible with EITHER the matching private key that a correspondent owns, OR using the password. So the user has to pass on the password only to those recipients for whom no good public key is available.) I'd prefer to visualize in some way this current mode of operation. The visualization should mention something like "message encryption password set". Clicking it should allow the user to view, modify, or disable the message encryption password (while still in composer). In theory, offering this message encryption could work even when the user hasn't set up OpenPGP encryption for themselves. But I think we shouldn't offer it, because it would complicate the UI, it would also be in contradiction to our explanations (which we have in several places) that opting in to email encryption is required by setting a key for the user. We disable the encryption button if the user hasn't yet set up their own OpenPGP key, which would further complicate the UI to get this password based encryption turned on. And finally, if the user (sender) has set up their own encryption key, we'll also encrypt with that key, which means the sender will be able to view the encrypted copy in the Sent folder, even after forgetting/losing the message encryption password. In other words, I suggest: Only if the user is set up for OpenPGP e2ee already, only then offer the user the alternative to encrypt using a password.