I have an experimental patch for bug 135636.
I'd like to collect feedback from users who are asking to implement bug 135636.

I haven't yet discussed this approach with the Thunderbird's UI experts, so no guarantees are given that the feature will be implemented as shown in this experiment.

The patch can be found here:
https://phabricator.services.mozilla.com/D151915?id=636570 [edit: obsolete]

I'll add another comment shortly with the experimental binaries - they will be based on the latest development version of Thunderbird - it's highly recommended that you use a separate profile for this experiment. Don't use your regular profile. If you don't know yet how to so, read more about Thunderbird's profile manager. (In short: Start Thunderbird with parameter -P and use a dedicated profile for this test.)

In this build, the default behavior is unchanged.

In order to test the optional functionality, read the following description. Then use preferences, config editor, and set the configuration that you'd like to test.

// Automatically enable encryption if S/MIME certificates or OpenPGP keys are
// available for all recipients, and thus encryption is possible.
// This pref is only about enabling, and doesn't control automatic disabling.
pref("mail.e2ee.auto_enable", false);

// If end-to-end encryption with S/MIME or OpenPGP is enabled,
// and the user adds another recipient with unavailable certificate or key,
// and this preference is true, then automatically disable encryption.
// This pref is dangerous, and it is recommended to always keep it at false.
// If you change the pref to true, the user might assume that encryption
// is still enabled, and might not notice that encryption gets disabled.
// There is an exception: If encryption was enabled, because the message
// refers to an existing encrypted conversation (e.g. replying to an
// encrypted message), this preference is ignored, encryption will
// remain on. It isn't possible to override that behavior.
// Note that encryption will never be disabled automatically on sending,
// only when the list of recipients is changed.
pref("mail.e2ee.auto_disable", false);

// If end-to-end encryption gets automatically disabled, inform the user
// using a prompt.
pref("mail.e2ee.notify_on_auto_disable", true);

Experimental binaries:

Linux 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/WhtMUEpVQnihyquCTZ64XA/runs/0/artifacts/public/build/target.tar.bz2

Windows 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/RYgCN9oZRs-KGrfk8jM79w/runs/0/artifacts/public/build/target.zip

Windows 32bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/TxBS9GPnSAa-Yk_t1wzrsA/runs/0/artifacts/public/build/target.zip

[edit: from https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=4495bdd7a21d99ed1bea51a9730cd9ed1ff1c6c8]

[edit: obsolete]

A shorter summary of the three experimental prefs:

If you want encryption to be automatically enabled, but never automatically disabled, set mail.e2ee.auto_enable to true.

If you want encryption to automatically enabled and disabled, and get a warning whenever it gets automatically disabled, set mail.e2ee.auto_enable to true, and set mail.e2ee.auto_disable to true.

If you want encryption to automatically enabled and disabled without a warning (only feedback will be the encryption toolbar button that will change state), set mail.e2ee.auto_enable to true, and set mail.e2ee.auto_disable to true, and set mail.e2ee.notify_on_auto_disable to false.

Experimental macOS binary:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/BTeaMceJRzWStXSEGomahA/runs/0/artifacts/public/build/target.dmg

[edit: obsolete]

@kaie thanks for the macOS dmg, I'll give it a try tomorrow

Hello Kai,

thanks a lot for your beta of automatic (en/dis)abling the encryption.

I've tried the different versions and have the following comments:

"mail.e2ee.auto_enable=true" + "set mail.e2ee.auto_disable=true"

• when using it the first time and I open a new email a wrong message "encryption was disabled" occurs.
• the symbol in the subject does not change to "encryption not available" when inserting an address with an public key in the key store
• the option "encrypt" can't be disabled. When using auto (en/de)cryption it could make sense to disable the button? ;-)

"mail.e2ee.notify_on_auto_disable=false"

• works fine

Best regards from Rostock, Germany

Tino

Hi Kai,
Thank you for this patch and for providing binaries for easy testing!
I tried the variant with auto enable and auto disable both true. I got the warnings on auto disable.
I tested with mail accounts where encryption was on by default and also with an account where it is off.

For our company, I think I would choose your auto enable option together with no encryption by default. Then, all internal communication would automatically be encrypted and for external communication my colleagues wont be annoyed.

Thanks for the effort!

Before I reply to the above comments, one more thought. There's a detail missing that still needs to be implemented. The Encrypt button should be sticky, once the user clicks it for a manual decision. E.g. if encryption is currently disabled, and the user clicks the Encrypt button to enable it, that decision should be sticky, further changes to the recipient list should no longer change the Encrypt settings (in my opinion). I also think we might need a way to visualize whether the composer window is currently in "automatic decision" mode, or if the composer window has switched to "manual override" mode. I've also filed bug 1796807 to explore how we could potentially visualize that.

(In reply to t.korth from comment #5)

• the symbol in the subject does not change to "encryption not available" when inserting an address with an public key in the key store

The symbol in the subject line is specifically about encryption of the message subject.

Thunderbird never encrypts the message subject, even if encryption for the message body is enabled.
To remind the user that the subject will be sent in plain text, we show this reminder icon.

That behavior is already present in the 102.x release.

For an OpenPGP message, we don't show that icon, because Thunderbird can encrypt the subject.
If the user disables subject encryption for an encrypted OpenPGP message, the subject no-encryption icon will be shown, too.

(In reply to t.korth from comment #5)

"mail.e2ee.auto_enable=true" + "set mail.e2ee.auto_disable=true"

• when using it the first time and I open a new email a wrong message "encryption was disabled" occurs.

I cannot reproduce this. Can you please give a more detailed step-by-step description how you get that message?

(In reply to t.korth from comment #5)

• the option "encrypt" can't be disabled.

Confirming. That's a bug.

When using auto (en/de)cryption it could make sense to disable the button? ;-)

We have two choices.

(a) We could disable the Encrypt button - and force the user to go with the automatic decision.

(b) We could allow the user to toggle the button manually. If we allow that, and the user change the setting, then I think the user decision would have to be sticky (disable all automatic changes after the user has made a manual change).

I prefer (b).

I'm also for (b). A manual user choice in the compose window should have precedence and should be sticky. The hint "OpenPGP end-to-end encryption is available" at the bottom of the compose window (as in current Thunderbird 102) is still nice and should be preserved.

How to present the settings in the account settings? Currently we have

• do not use encryption for new messages
• do use encryption for new messages

Instead, the future options could be:

• "use encryption if possible" (that could be: off by default but auto_enable=true); I think that would be very user-friendly and good for "normal" users.
• "always enable encryption for new messages" (with auto_disable=false); because people who really want to encrypt also want to explicitly disable encryption
• "never encrypt (not recommended)" for cowards ^^

Explicit settings UI for your three options can still be made in the config editor.

• "use encryption if possible" (that could be: off by default but auto_enable=true); I think that would be very user-friendly and good for "normal" users.
• "always enable encryption for new messages" (with auto_disable=false); because people who really want to encrypt also want to explicitly disable encryption
• "never encrypt (not recommended)" for cowards ^^

For the first of my suggested three options: What, if the user first enters a mail address with known key and then another one with no key? I think auto_disable=true is good but notify_on_auto_disable=true would be annoying in that case.

Not sure if this discussion about UI went out of scope of your ticket – sorry if so!

(In reply to jschoett from comment #13)

How to present the settings in the account settings?

That's an open question. I've already spent some time thinking about possible options, but I'm not yet sure what's best.

It might be better to configure the automatism globally, not per account.

An argument is the ability to switch the "from" account in the compose window. If we allowed different settings per account/identity, what happens if the user switches the "from" account/identity? Or switches from an automatic account to a manual account, and then switches back to an automatic account? What behavior do you get after the second switch? I think this might be confusing to understand, and difficult to find an implementation that gives sane behavior.

If we have a global configuration for "allow automatic enabling/disabling of encryption", then it's much easier to implement. You may switch between accounts, and you always get the automatic enabling/disabling, as long as you haven't clicked Encrypt to override (which would then be a sticky decision, turning of the automatism).

I've spent some time today brainstorming about the consequences for account settings. I was also considering a third option. But my current opinion is, I'd rather avoid a third state in account settings.

We could potentially do it like this:

Change the wording for the existing "enable by default" and "disable by default" prefs. Clarify that those settings are only relevant when controlling encryption settings manually - if the global automatism is turned off.

And if the global automatism is turned off, the account settings could actually disable those prefs, and show an information text, something like "Encryption will be automatically enabled or disabled based on available recipient keys or certificates"

(In reply to Kai Engert (:KaiE:) from comment #12)

(In reply to t.korth from comment #5)

• the option "encrypt" can't be disabled.

Confirming. That's a bug.

I've updated the patch to fix this bug:
https://phabricator.services.mozilla.com/D151915?id=637792

With this update, it's possible to enable/disable encryption. And once the user toggles the setting, that choice is "sticky". In other words, as soon as the user clicks the Encrypt button once, it will no longer be updated automatically.

Updated binaries:

Linux 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/d8J9fWezSb6Um0KpKN-NrA/runs/0/artifacts/public/build/target.tar.bz2

Win 32bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GZ8Ij5zcRyOtHgaGpSFtGg/runs/0/artifacts/public/build/target.zip

Win 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/bhPlhc6QSU-5PWbBPY_8rQ/runs/0/artifacts/public/build/target.zip

macOS:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/RI92l7G4QR-iIb3Qhjiv8g/runs/1/artifacts/public/build/target.dmg

[from https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=7deaf637b79f66e591213277d63ad16c171afba1 ]

[edit: obsolete]

(In reply to Kai Engert (:KaiE:) from comment #11)

(In reply to t.korth from comment #5)

"mail.e2ee.auto_enable=true" + "set mail.e2ee.auto_disable=true"

• when using it the first time and I open a new email a wrong message "encryption was disabled" occurs.

I cannot reproduce this. Can you please give a more detailed step-by-step description how you get that message?

1.) I've zipped my old Thunderbird folder
2.) I've unzipped your 64bit file (I'll call that ThunderbirdDaily)
3.) I've started ThunderbirdDaily
4.) I've closed ThunderbirdDaily
5.) I've copied the "default" folder from my old Thunderbird folder to the new ThunderbirdDaily
6.) I've started the new ThunderbirdDaily

I remember that I've seen a wrong error message after step 6.
But it occured only one time, so I can't reproduce that anymore.

BR, Tino

You saw that error message immediately after starting up, even before you've opened a message compose window?
That seems very surprising. Unless you open a composer window, the code that displays that error shouldn't be reached.
(BTW the builds I'm uploading are based on the beta branch.)

(In reply to Kai Engert (:KaiE:) from comment #10)

(In reply to t.korth from comment #5)

• the symbol in the subject does not change to "encryption not available" when inserting an address with an public key in the key store

The symbol in the subject line is specifically about encryption of the message subject.

Thunderbird never encrypts the message subject, even if encryption for the message body is enabled.
To remind the user that the subject will be sent in plain text, we show this reminder icon.

That behavior is already present in the 102.x release.

For an OpenPGP message, we don't show that icon, because Thunderbird can encrypt the subject.
If the user disables subject encryption for an encrypted OpenPGP message, the subject no-encryption icon will be shown, too.

Thanks for the explanation.
I wondered because I've seen a different behaviour at different installations.
But with your help I saw that I'd on one computer a PGP key installed. So it makes sense.
My fault. ^^

(In reply to Kai Engert (:KaiE:) from comment #12)

(In reply to t.korth from comment #5)

• the option "encrypt" can't be disabled.

Confirming. That's a bug.

When using auto (en/de)cryption it could make sense to disable the button? ;-)

We have two choices.

(a) We could disable the Encrypt button - and force the user to go with the automatic decision.

(b) We could allow the user to toggle the button manually. If we allow that, and the user change the setting, then I think the user decision would have to be sticky (disable all automatic changes after the user has made a manual change).

I prefer (b).

I also prefer (b) - if there's a chance to turn on automatical encryption again on an easy way :-P

(In reply to Kai Engert (:KaiE:) from comment #15)

(In reply to jschoett from comment #13)

How to present the settings in the account settings?

That's an open question. I've already spent some time thinking about possible options, but I'm not yet sure what's best.

It might be better to configure the automatism globally, not per account.

An argument is the ability to switch the "from" account in the compose window. If we allowed different settings per account/identity, what happens if the user switches the "from" account/identity? Or switches from an automatic account to a manual account, and then switches back to an automatic account? What behavior do you get after the second switch? I think this might be confusing to understand, and difficult to find an implementation that gives sane behavior.

If we have a global configuration for "allow automatic enabling/disabling of encryption", then it's much easier to implement. You may switch between accounts, and you always get the automatic enabling/disabling, as long as you haven't clicked Encrypt to override (which would then be a sticky decision, turning of the automatism).

I've spent some time today brainstorming about the consequences for account settings. I was also considering a third option. But my current opinion is, I'd rather avoid a third state in account settings.

We could potentially do it like this:

Change the wording for the existing "enable by default" and "disable by default" prefs. Clarify that those settings are only relevant when controlling encryption settings manually - if the global automatism is turned off.

And if the global automatism is turned off, the account settings could actually disable those prefs, and show an information text, something like "Encryption will be automatically enabled or disabled based on available recipient keys or certificates"

I'd prefer also a global setting.
If there's no SMIME/PGP key available the encryption setting should be disabled (like it's done at the moment).
If there's a SMIME/PGP key available the encryption is enabled (and -in future- the "encrypt if possible" option, too).

(In reply to Kai Engert (:KaiE:) from comment #18)

You saw that error message immediately after starting up, even before you've opened a message compose window?
That seems very surprising. Unless you open a composer window, the code that displays that error shouldn't be reached.
(BTW the builds I'm uploading are based on the beta branch.)

Sorry. Yes. I opened a composing window.

(In reply to Kai Engert (:KaiE:) from comment #15)

(In reply to jschoett from comment #13)

How to present the settings in the account settings?

That's an open question. I've already spent some time thinking about possible options, but I'm not yet sure what's best.

It might be better to configure the automatism globally, not per account.

An argument is the ability to switch the "from" account in the compose window. If we allowed different settings per account/identity, what happens if the user switches the "from" account/identity? Or switches from an automatic account to a manual account, and then switches back to an automatic account? What behavior do you get after the second switch? I think this might be confusing to understand, and difficult to find an implementation that gives sane behavior.

On the other hand, some arguments speak against new global settings.

• Encryption is a complex topic and keeping related options closely together in the UI would simplify it for most users.
• Having one general setting "auto enable/disable" and the account settings "enable enc" or "disable enc" would lead to 2x2 possiblities (if not even 2x2x2 possibilities for separate auto_enable and auto_disable). Whereas my suggestion has only three possibilties. For a user, thinking through implications of 2x2 possibilities is much harder than just three options.
• Regarding the behavior on "from" switch in the compose window: I think it would be logical for users if on any switch the account default is applied – except when the user already manually changed the encryption state and made it sticky.

Could not test - setup is buggy, even on a brand new ~/.thunderbird dir.
Just wanted you to know someone else tried to help test and thanks for this effort!

(In reply to jschoett from comment #23)

On the other hand, some arguments speak against new global settings.

• Encryption is a complex topic and keeping related options closely together in the UI would simplify it for most users.
• Having one general setting "auto enable/disable" and the account settings "enable enc" or "disable enc" would lead to 2x2 possiblities (if not even 2x2x2 possibilities for separate auto_enable and auto_disable). Whereas my suggestion has only three possibilties. For a user, thinking through implications of 2x2 possibilities is much harder than just three options.

Please see comment 15, the last 2 paragraphs.
With the global automatism enabled, the existing account prefs would be shown as "disabled" and ignored.
I think I should add this immediately to the current patch.

• Regarding the behavior on "from" switch in the compose window: I think it would be logical for users if on any switch the account default is applied – except when the user already manually changed the encryption state and made it sticky.

Consider the following scenario:
Account A:

• automatism disabled
• enable encryption by default

Account B:

• automatism enabled

User starts with from=A.
Encryption is enabled.
User adds no-encryption recipient, "cannot encrypt" notification is shown.
User clicks "from", changes to B.
Encryption is turned off, notification is removed.
User clicks "from", changes to A.
Encryption is still turned off.
User clicks send.
Message is sent without encryption.

In this scenario, the user did NOT click the encrypt button at all.
However, despite account's A setting "enable encryption by default",
the message will be sent from account A without encryption.

There might be additional confusing scenarios like this, if the automatism depends on the "from" setting.
I think automatism shouldn't depend on "from".

I've updated the patch again.
In comparison to comment 16, the only changes are in account settings, end-to-end encryption view.

I've moved the label "Without end-to-end encryption..." to the top of the page.

The radio buttons "Disable encryption for new messages" and "Enable encryption for new messages" will continue to be shown with the DEFAULT prefs. If the user sets pref "mail.e2ee.auto_enable" to true, those radio buttons will be hidden.

If the radio buttons are hidden, a different information text will be shown. One of two versions of the text will be shown, depending on the value of the second pref "mail.e2ee.auto_disable".

It will say either "Encryption will be automatically ENABLED, based on available recipient keys or certificates. You may override the automatic decision." - or - "Encryption will be automatically ENABLED OR DISABLED, based on available recipient keys or certificates. You may override the automatic decision."

(I used uppercase to show the difference between the two versions of the text.)

I think with this change, the patch may be ready for code review.
However, I'm again inviting you to have another round of testing.

https://phabricator.services.mozilla.com/D151915?id=638164
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=c8ace17b0c9bb96db7783349d85b511af467873b

Linux 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/F4xbozK1Sh2BdXD0aGvC6A/runs/0/artifacts/public/build/target.tar.bz2

Win 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SQMJNfqNQyOYNGVo06KGZw/runs/0/artifacts/public/build/target.zip

Win 32bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/FvCo5Mw1TI-bmhtBDmKu-A/runs/0/artifacts/public/build/target.zip

macOS:
[link will be added soon]

Thanks for the new uploads! With auto_enable true, is it intended that for new, empty e-mails, encryption is enabled by default? If yes, auto_enable actually doesn't have an effect:

1. if enc is enabled, it can't be auto-enabled.
2. if I disable it, it's sticky disabled, so auto-enable also has no effect.

Or does that behavior maybe stem from my previous account settings (enable encryption by default)? Yes, looks like it does. That would be a bug because the account settings are not accessible anymore after auto_enable is set.

When not exposing the auto_enable/auto_disable options directly to the user and make three options in the account settings, instead, I think the intended behavior could be made more clear.

jschoett, thanks for your feedback.

I agree this needs a fix. With auto_enable=true the old settings (which are then hidden) should be ignored - and fresh emails (empty recipient list) should start with encryption turned off.

The switching of the from-identity also hasn't been implemented yet.
I've come to the conclusion that the current logic for adjusting the encryption related settings in composer needs a rewrite, to ensure it's maintainable and understandable.

I've worked on the issues from comment 28 and comment 29 in November.
Then there were lots of other distractions, but now I'm finally getting back to this task.

I've updated the patch in bug 135636.
I'm crossing fingers and hope that the behavior is much better now and mostly complete.

I'll provide new test builds, and would be thankful if you can test again and provide feedback.

New builds, based on the Thunderbird-Beta 112 branch.

Linux 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NgpTmfjzQpu6_7sZ37Nt0Q/runs/0/artifacts/public/build/target.tar.bz2

Windows 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/C4hzFKE3SzOwuA8H6PxFjg/runs/0/artifacts/public/build/target.zip

macOS:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/AJpBS7QwQruFZkH5-Du54Q/runs/0/artifacts/public/build/target.dmg
(If you want to test this, you need to override security protections for apps downloaded from the Internet - at your own risk! Download, and copy the App to a new folder on your desktop. Then open a terminal window, and change into that folder. Then execute xattr -cr Thunderbird\ Daily.app. Then ensure you execute it with a fresh profile. Start it with parameter -P, run this command: ./Thunderbird\ Daily.app/Contents/MacOS/thunderbird -P)

from:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=ef1d611c6174112dc68d933958b95dfc2184a395

An initial implementation was added to Thunderbird Daily.
Please help testing it and provide your feedback as explained in bug 135636 comment 250.