The "Encrypt if possible" and also the Enigmail-Autocrypt feature aren't working anymore in Thundebird-78.4.
https://addons.thunderbird.net/de/thunderbird/addon/encrypt-if-possible/
https://addons.thunderbird.net/de/thunderbird/addon/enigmail/
Please provide an alternative.

Adding the phrase "opportunistic encryption" since it took me a long time to find this issue after my search for opportunistic returned no results.

As Comment 86 noted, for wider adoption of encryption, it's critical that its usage not interrupt workflow too much. I set up multiple friends and colleagues with Enigmail, and opportunistic encryption made privacy transparently easy, aside from occasional refreshing or new importation of keys. The new integration into Thunderbird is a huge step backwards, and makes PGP nearly unusable for most users. (Either they set to always encrypt, then have their workflow interrupted whenever they send to someone without a key; or they set to never encrypt, and inevitably forget to manually set encryption on every single email for which they do have recipient key(s).)

(In reply to norristh from comment #92)

Adding the phrase "opportunistic encryption" since it took me a long time to find this issue after my search for opportunistic returned no results.

As Comment 86 noted, for wider adoption of encryption, it's critical that its usage not interrupt workflow too much. I set up multiple friends and colleagues with Enigmail, and opportunistic encryption made privacy transparently easy, aside from occasional refreshing or new importation of keys. The new integration into Thunderbird is a huge step backwards, and makes PGP nearly unusable for most users. (Either they set to always encrypt, then have their workflow interrupted whenever they send to someone without a key; or they set to never encrypt, and inevitably forget to manually set encryption on every single email for which they do have recipient key(s).)

In general, I'd say the PGP integration is a step forward, but the design decision that encryption can only be globally enabled or disabled seems, with all due respect, brain dead. For 20 years, I had a very hard time getting non tech savvy users to adopt PGP, and thus when TB announced their built-in support, I was received. But this is a real bummer, because I know that most users I am interacting with will not think of having to enable encryption for the current message.

One compromise would be that TB, whenever it finds a matching key, it should, prior to sending the message, ask the user whether or not encryption should be enabled.

We're planning to support this, just didn't have time to finish it for 78.

(In reply to Magnus Melin [:mkmelin] from comment #94)

We're planning to support this, just didn't have time to finish it for 78.

Sorry for bothering, and I know the old rule of "it's ready when it's ready", but is the current plan to have it ready for one of the next point releases? I'd love to know in order to understand what to tell my users.

No this needs a lot of new UI, so won't be available until the next major release mid 2021 (well, in betas some time prior to that yes).

Although Bug #1654950 was fixed without any UI for now - just with a hidden config option. I guess that would suffice for a lot of people. And, actually, the UI could be just a checkbox:
[x] Automatically switch on encryption if a public key is available for all recipients
Does this basic functionality really have to wait more than half a year?
Currently, I'm sending all mails without any encryption because it's so cumbersome...

(In reply to r from comment #97)

Although Bug #1654950 was fixed without any UI for now - just with a hidden config option. I guess that would suffice for a lot of people. And, actually, the UI could be just a checkbox:
[x] Automatically switch on encryption if a public key is available for all recipients
Does this basic functionality really have to wait more than half a year?
Currently, I'm sending all mails without any encryption because it's so cumbersome...

This is just about attaching the pubkey, not about automatically encrypting when a pubkey for the recipient is available, right?

Yes, it's a totally different issue. I used it as an example to show that there are different/easier options than implementing a full-fledge UI to realize what probably most of those following this issue are looking for: Basically a simple option, to turn on encryption automatically only when there are public keys available for all recipients. Currently there is only on and off. What we need is a third option: "On if there is a known public key for all recipients - otherwise off". That would solve perhaps not all situations, but would massively alleviate the current problems and disappointment many have after upgrading from the old Thunderbird with Enigmail.

(In reply to Magnus Melin [:mkmelin] from comment #96)

No this needs a lot of new UI, so won't be available until the next major release mid 2021 (well, in betas some time prior to that yes).

This is deplorable, because, even though TB 78 provides the technical underpinnings for making end-to-end encryption easier, this limitation, according to the feedback I get, make it very unlikely for anyone to effectively start using PGP if they haven't, because they will always just forget to check the box, and for anyone who has been using enigmail in the past, this is a major nuisance. As much as I appreciate that TB is committed to making PGP use more common, I have again downgraded to 68 because of this.
The thing is: In any other encrypted communication channel, such as Signal, Whatsapp, even facebook messager, you don't have to do anything to make encryption work. It just works transparently. If prior to sending a Signal message I would have to tick a box saying "encrypt this message", few people would do it.

So, this should really get priorised, I feel. Again, I really value the efforts you are making here. I just feel that abolishing Enigmail at this stage was premature.

Wow, this bug is 19 years old! I was about to report exactly the same issue.
Currently, one can only choose between "Require encryption by default" or "Do not enable encryption by default".

What happens with "Require encryption by default":

• every message that I send to people who do not use OpenPGP (and I do not have their key) needs to be manually unticked so that Thunderbird does not try to encrypt them.

What happens with "Do not enable encryption by default":

• every message that I send to people who use OpenPGP (and I do have imported their key into TB) needs to be manually ticked so that Thunderbird does encrypt them. Unless I reply to a message that was encrypted.

The option "Require encryption when possible" would mitigate both unusable cases described above.
As Johannes Rohr says, look at Signal. You can see on one eye blink that your message will be encrypted (blue arrow) or not (grey arrow and text saying "Send message unencrypted"). This simplicity/transparency of use is missing in TB's implementation of OpenPGP. In 2020 this should be a standard.

Also see bug 1681938

I agree, Enigmail was better with that regards.
I am very disappointed with the deprecation of Enigmail and the move to a feature that is not ready yet.
(btw I do contribute to the Mozilla foundation)

Bug 1684783 is not a duplicate of this bug. This bug is a feature request and Bug 1684783 is a serious defect that prevents mail from being sent if it was PGP encrypted.

It's still a duplicate.

Can you explain why the defect of having TB set to "Do not enable encryption by default" but it refuses to send mail because a public key is missing is related to this feature request to prefer encryption?

Currently we support "require encryption" or unencrypted. For encrypted mails we will try to reply encrypted (totally per design).
If you don't have the key, you can switch that mail to be sent unencrypted. Perhaps the UX could be better, but the better UX would basically be this bug.

I was about to request this feature, and I found out that request is open for almost two decades... LOL

Third option for encryption would be nice:

• Use encryption if possible (if key is available)

Possibly another configuration option for multiple recipients:

1. abort if not all keys available
2. send encrypted to recipients with keys and send unencrypted to recipients without keys (and display warning?)
3. Ask

i'd like to see(In reply to darthbolek4 from comment #111)

I was about to request this feature, and I found out that request is open for almost two decades... LOL

Third option for encryption would be nice:

• Use encryption if possible (if key is available)

Possibly another configuration option for multiple recipients:

1. abort if not all keys available
2. send encrypted to recipients with keys and send unencrypted to recipients without keys (and display warning?)
3. Ask

To have some popup coming up for asking for confirmation if the message could not get encrypted is exactly what i'd like to see!

The basic solution is checking if a key exists and flipping the preexisting encryption option, which should take 5 minutes to code. I can't think of any reasonable explanation of why something so simple and that only benefits illegal mass surveillance has been open for 19 years except due to an NSA influence operation.

I'd also like a function like the outdated "Encrypt if possible". 👍

Fully agree with schaum.
Third option "Use encryption if possible" is neccessary in order to promote encryption and avoid annoying users by letting them always check or uncheck encryption settings.

For mails with multiple recipients:
If "require encryption" is set as default and (one of) the recipients key is missing the popup could ask what to do

• send encrypted to recipients with keys and send unencrypted to recipients without keys (which should also be the case when "Use encryption if possible" is set
• do not encrypt mail
• abort (in order let user get recipients key)

We recently switched to TB78 and not having a simple way to disable encryption is really confusing to our users. With enigmail/TB68 we have configured encrypt+sign by default. Whenever there was a public key missing, users could simply uncheck encryption, and could send the email (one additional click)

Now this option is hidden behind security and is much less intuitive, and takes 2 clicks, and also disables signing (which might not be what we want, because maybe the recipient has my public key and would like to verify my signature). Maybe not the right bug here, but as a first step, to have 2 buttons in the composer window to toggle encryption, and signing, that would improve workflow tremendously.

If users have one account, on which they communicate with some people with PGP and with some people unencrypted, they now have a bad expirience.

Either we can disable automatic encryption, and need to remember each time to enable it for the conversations that use it, or have it on, but get a annoying window everytime we communicate with people that don't have a key.
Also I sometimes get so used that I have to disable the encryption, that I routinely disable it, even when sending an email to someone who has a key.

This all leads to frequent problems, and can lead users to accidentally send information that should be encrypted in plain text.

Having no option to use encryption if possible (if key is available) makes PGP nearly unusable for many of our users. Either they choose "always encrypt", then have their workflow interrupted whenever they send to someone without a key; or they choose "never encrypt", and inevitably forget to manually set encryption on every single email for which they do have recipient keys. This leads users to accidentally send information that should be encrypted in plain text.

To our descendants: please time travel back to 2002-04-05 to convince the community to give birth to a child with the name #135636.

To our contemporaries: It should be fixed now by any minute.

Since this ticket was created I have taught quite many people how to encrypt their email communication using Thunderbird and Enigmail. After Enigmail was dropped, this issue kind of ruins this effort, because it just won't work like this and those with good will but without dedication are repelled. It does real damage to the goal of promoting e2e encryption for email - please consider raising the severity of the issue.

Anyway, it was an honor to be part of this historic ticket.

I can only agree. The current situation is repelling users - even me - to used e2e encryption with Thunderbird.

How difficult can it be to develop an add-on that will fix the issue?

Is it not possible to just let enigmail extension works again ?

I understand it is quite frustrating for Thunderbird developer and you may have other priorities than security and user privacy
but currently Thunderbird encryption even in beta 91 version is not as functional as 68+enigmail.

If development has to be halted it may be a good compromise to just let the old extension provides what users need.

If you wish to fix the bug, please do it. But this evangelising has to stop.
There is a discussion forum for E2EE here https://thunderbird.topicbox.com/groups/e2ee
I suggest you start using it I try and follow significant bugs for developments. All this noise is making that very difficult and it is not contributing to getting the bug looked at.

I strongly encourage you to read the guidelines https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before you post in this or any bug.

(In reply to Matt from comment #124)

If you wish to fix the bug, please do it. But this evangelising has to stop.
There is a discussion forum for E2EE here https://thunderbird.topicbox.com/groups/e2ee
I suggest you start using it I try and follow significant bugs for developments. All this noise is making that very difficult and it is not contributing to getting the bug looked at.

I strongly encourage you to read the guidelines https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before you post in this or any bug.

Hi,

I would like to work on this bug.
Would you or Mozilla take a PR?

If yes, could you give me some pointers where to implement this?
I am the maintainer of multiple Android apps, but have never looked at the Thunderbird source.

Thanks for offering to help. This bug is unlikely to be a good candidate to work on for a first patch though.
We are currently evaluating what route we would take here.

Hi Kiebitz,

thanks for your offer to help. I'm not a developer myself, but I'm managing Thunderbird within my organization (80+ staff), advocate for it for 10+ years, and an author of a small TB addon.

I think what gave this bug renewed attention is not only the fact that it is 20 years old, but also the fact that sending unencrypted emails with encryption enabled in TB78+ (still the case in TB91) is more complex than with TB68 and enigmail.

There is are quite some discussions, bugs about this e.g.:
https://bugzilla.mozilla.org/show_bug.cgi?id=1710453
https://thunderbird.topicbox.com/groups/e2ee/Tcb4b3decdb7e66ce/require-encryption-vs-optional-encryption
(there is much more, esp bugs.)

I'm just a person trying to keep my colleagues motivated to continue using encryption, and Thunderbird. The introduction of TB78 severely complicates sending unencrypted emails (which is the majority) while having encryption enabled (some emails per day to certain people, and those emails must be encrypted, so no way to make it optional, as my colleagues will simply forget to check the (hidden) checkbox).

So if you have time, and motivation to help improving the workflow of sending (un)encrypted emails, and it doesn't have to be this bug, I think there are many other possibilities.

As TB91 is out since a couple of days and it retained the complex workflow of TB78, I fear that any improvement could only come with TB2022 (in one year?).

Some practical examples to improve the workflow in the meantime:

1. an addon/setting which simplifies user-interaction to disable/enable encryption in the composer (right now, the "do not encrypt" button is hidden behind a small arrow - this is already a big obstacle for the majority of users).
2. an addon/setting which improves the error messages when you miss public keys of recipients (right now, there are 2 popups, and no way to simply click "send unencrypted")

I'm sure there is more, these are just my ideas.

thanks,

(In reply to Magnus Melin [:mkmelin] from comment #126)

Thanks for offering to help. This bug is unlikely to be a good candidate to work on for a first patch though.
We are currently evaluating what route we would take here.

I do wonder why this has been released in the first place. Enigmail has served us really well for many years, it did everything we needed.
I understand that there is ample reason to have it tighter integrated into Thunderbird, but how it was done has had the opposite effect of what was intended and I submit that this was no surprise.

For me, convincing any of my peers to use PGP has become not only not easier but more difficult, and the absence of an "encrypt whenever possible" switch is a big part of the problem. Another is that Thunderbird hasn't made it easier to exchange keys. This is the greatest showstopper. In any other trusted channels, key exchange happens without user interference in the background. With email this isn't possible because encryption is tagged on, rather than built in. But Thunderbird could at least work to make it as seamless as possible. But ok, this is for another bug report. Anyway, I hope we don't have to wait another full year for a fix.

As someone who has been educating individuals on security practices for over a decade and a half, and whose feedback has been integrated in various tools, including Enigmail, I have to say that I agree with those who see the lack of this functionality as a hindrance to the adoption of using PGP by users.

Related to the regression usability issues, I also submitted this suggestion today. Comments and critique are encouraged.

Nobody has mentioned that TB has created a separate keyring, which is as backwards as FF trying to replace the system DNS resolver. The separate keyring functionality needs removed and it should use the system keyring. It's not noise Matt and this ticket is old enough to have protests in the street. Less than 5 lines of code would resolve most of the problem, this ticket isn't complicated, it's political. The EFF should get involved.

"Implement encrypt when possible" is easy to implement.

The funktion encrypt all email already checks if there is a pgp key for encryption. If there is no key, it shows an error message. Instead of the error message just send the email unenrypted and rename the funktion encrypt all in auto encrypt.
This is may be one line of code.

As long as it's all or nothing, and it should warn. You don't want to be sending the same message both encrypted and unencrypted. Even so, it still seems like a simple fix and it's astonishing that it's been decades now...

If I may add my 2ct here: There should be (at least) two modes here: Opportunistic and strict. Where opportunistic encrypts mail, if possible. Strict does not send out any thing unencrypted.

We need this feature:
S/Mime: Standard encrypt Email - Better solution if recipient has no certificate (Great was: Encrypt if possible Add-On) an Error doesen't make sence. Better: Do you want to send the email uncrypted, the recipient has no Key. Better for my old mother and other no tech people. I found an S/Mime Key do you want to send email encrypt? The Add/On do that perfect but you change the API.

(In reply to Bob Nelson from comment #131)

Nobody has mentioned that TB has created a separate keyring, which is as backwards as FF trying to replace the system DNS resolver. The separate keyring functionality needs removed and it should use the system keyring. It's not noise Matt and this ticket is old enough to have protests in the street. Less than 5 lines of code would resolve most of the problem, this ticket isn't complicated, it's political. The EFF should get involved.

Please contribute to the discussion in that ticket. The current owner of the issue thinks it should not be fixed for reasons that have not been totally explained, and which I do not find reasonable.

(In reply to Ahmad Gharbeia from comment #136)

(In reply to Bob Nelson from comment #131)

Nobody has mentioned that TB has created a separate keyring, which is as backwards as FF trying to replace the system DNS resolver. The separate keyring functionality needs removed and it should use the system keyring. It's not noise Matt and this ticket is old enough to have protests in the street. Less than 5 lines of code would resolve most of the problem, this ticket isn't complicated, it's political. The EFF should get involved.

Please contribute to the discussion in that ticket. The current owner of the issue thinks it should not be fixed for reasons that have not been totally explained, and which I do not find reasonable.

The NSA spends millions of dollars per year specifically to corrupt "security by default" and their biggest enemy is PGP because it uses secure and quantum resistant RSA, so it's no coincidence that this ticket exists for a "security by default" problem in the most used PGP email implementation.

A similar "security by default" corruption was the multi-million dollar PR campaign to remove DHE from browsers because services started using custom generated parameters, which was replaced by ECC with unexplained fixed parameters and DUAL-EC-DRBG which has been confirmed to have an NSA backdoor. The internet is littered with government paid articles claiming ECC is more secure when all of the evidence says RSA/DHE is more secure and mathematically 521-bit ECC will be broken by quantum computers years before RSA-2048.

The explanation is an organized infiltration of OSS communities to weaken security standards.

sorry (digital security has a problem fine): But please use other plattforms to discuss that not a bug ticket. thanks. Otherwise nobody will implement that feature.

(In reply to berggeist01 from comment #138)

sorry (digital security has a problem fine): But please use other plattforms to discuss that not a bug ticket. thanks. Otherwise nobody will implement that feature.

I'm not discussing implementing a feature, my ticket was for an introduced security vulnerability related to an already existing feature which has been merged into this 19 year old "dump ticket" as a duplicate.

I add information related to other intentionally introduced security vulnerabilities because it links them together for future investigations, especially when a big company gets behind the accusation of NIST curves being backdoored, like when Microsoft got behind the accusation of DUAL EC DRBG being backdoored after 7 years of people drawing attention to it just like this.

If this isn't the correct ticket for this discussion then my merged defect ticket isn't a duplicate and needs reopened.

I think klaus.r (in comment #132 ) is right.
This option should be easy to implement:
For the start we just need a hidden config option (about:config) like "mail.openpgp.encryptWhenPossible".

• If the setting for an account is set to "do not activate encryption by default", and a pgp key exists for the recipient, the Email will be encrypted.
• If the setting for an account is set to "require encryption by default", and no pgp key exists for the recipient, the behaviour is as before: a warnig message will be displayed.

I need that feature for my "family". Default -> no encryption otherwise to many errors and handling problems. If encryption is possible ask user to encrypt this message or do it by default. Keep in mind it must work for sMime too (I use that for the family) family == no technical user. With the addOn encryption if possible it works perfect.

What do you mean with

the addOn encryption if possible

Is there an addOn, that already does that?

yes until the new API and now it is not possible any more. https://addons.thunderbird.net/de/thunderbird/addon/encrypt-if-possible/

During the past months, a group of Thunderbird developers and UI designers has spent a significant amount of time to discuss and plan improvements around the Thunderbird composer UI and its encryption settings. I want to inform you about a decision that is related to the enhancement request discussed in this bugzilla ticket.

We have come to the conclusion that we want the user to be in control, but that we want to make it as easy as possible for the user to control the encryption settings for an email.

Enabling or disabling encryption for an email should be a single click.
The toolbar should have a clear visual indicator, next to the "Send" button, whether encryption for this message is enabled or disabled.

If encryption is currently disabled for an individual message, Thunderbird should automatically check whether using encryption for the current message is possible (without further user action). The check should be automatically repeated on every change to the recipient list. If the check discovers that encryption is possible, because we have valid and accepted keys for every entry in the recipient list, then Thunderbird will show a clear notification, reminding the user about the possibility to enable encryption. If the user wants to use encryption, the user can click the control to enable encryption.

If encryption is turned on in the composer window for an individual message (either because you have enabled encryption for new messages by default, or you are replying to a message that was encrypted, or because the user has manually turned on encryption for the individual message), but it is impossible to encrypt, because for at least one recipient we don't have a valid and accepted key available, then Thunderbird will show a clear notification about this fact, and the notification will offer the user a path to discover how to resolve the problem.

In other words, the configuration options will remain limited to "encryption on" or "encryption off".

We do NOT want to implement a third option "automatically encrypt if possible". There have been suggestions to automatically enable encryption whenever it is possible, and automatically disable encryption as soon as encryption isn't possible. We have discussed this, but we consider it a risk.

We want to put the user in control, allow the user to control easily, and avoid surprising the user with unexpected behavior.

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

We do NOT want to implement a third option "automatically encrypt if possible".

... at least not at this time or in the immediate future.

Thank you for the detailed plan. Finally we can know what we can and can not expect from Thunderbird going forward. For me, this is a dealbreaker, unfortunately. This is just too complicated for me to constantly switch encryption on and off - even if it's just a single click. These clicks add up for every single mail when instead computers should be there to save us from useless repetitive work. Nevertheless I won't look back in anger. Thank you for a great piece of software which I happily used for over a decade. Time for something new, now. Bye.

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

During the past months, a group of Thunderbird developers and UI designers has spent a significant amount of time to discuss and plan improvements around the Thunderbird composer UI and its encryption settings. I want to inform you about a decision that is related to the enhancement request discussed in this bugzilla ticket.

We have come to the conclusion that we want the user to be in control, but that we want to make it as easy as possible for the user to control the encryption settings for an email.

Enabling or disabling encryption for an email should be a single click.
The toolbar should have a clear visual indicator, next to the "Send" button, whether encryption for this message is enabled or disabled.

If encryption is currently disabled for an individual message, Thunderbird should automatically check whether using encryption for the current message is possible (without further user action). The check should be automatically repeated on every change to the recipient list. If the check discovers that encryption is possible, because we have valid and accepted keys for every entry in the recipient list, then Thunderbird will show a clear notification, reminding the user about the possibility to enable encryption. If the user wants to use encryption, the user can click the control to enable encryption.

If encryption is turned on in the composer window for an individual message (either because you have enabled encryption for new messages by default, or you are replying to a message that was encrypted, or because the user has manually turned on encryption for the individual message), but it is impossible to encrypt, because for at least one recipient we don't have a valid and accepted key available, then Thunderbird will show a clear notification about this fact, and the notification will offer the user a path to discover how to resolve the problem.

In other words, the configuration options will remain limited to "encryption on" or "encryption off".

We do NOT want to implement a third option "automatically encrypt if possible". There have been suggestions to automatically enable encryption whenever it is possible, and automatically disable encryption as soon as encryption isn't possible. We have discussed this, but we consider it a risk.

We want to put the user in control, allow the user to control easily, and avoid surprising the user with unexpected behavior.

@Kai thank you for the feedback, the complete explanation and for all the people effort to design a good solution !

As for me and my teams, privacy coming first, it marks the end of Thunderbird as email client for us.
Good luck for the next step of this eMail client ! Thanks for all those years of services.

Thanks Kai for letting us know.
The design flaws of the current implementation make it hard for users to understand what is happening and what to do and make it too complicated to control, therefore it made sense to have automatic encryption.

Explained like this, it seems quite straightforward, but could you at least post a few screen shots with the new desing during the change, so that there is feedback from this community of passionate people before it’s too late again.

You mentioned encryption, but cryptographic signing should be managed the same way. However, encryption without signing shouldn’t be allowed, like other software already do (the reasons are explained here https://k9mail.app/2017/01/30/OpenPGP-Considerations-Part-II.html)

I agree that encryption (or even signing) shouldn’t be disabled automatically without the user being able to make a decision. That is a risk indeed.

What will happen with the surrogate openpgp-alias-rules.json as described in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1644085 ?

May I let you know that there are instances when the encryption or signing appear or disappear randomly, which should be mended as well: see bug https://bugzilla.mozilla.org/show_bug.cgi?id=1744835

This would also help make the one click interaction design simpler: https://bugzilla.mozilla.org/show_bug.cgi?id=1744757

And other annoying PGP bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=1743690
https://bugzilla.mozilla.org/show_bug.cgi?id=1656670

And this improvement https://bugzilla.mozilla.org/show_bug.cgi?id=1732074

That is the reason, why I must find a better solution for my whole family. bye bye thunderbird. I never understand, why it is not possible to implement a self configurable option. I work in the IT security more than 25 years. that behavior is the reason, why email encrypt is not mainstream. I believe what is better for people, close AddOn options with a new API and at the end after 20 years software is less helpful than before, unbelievable.

What is so difficult about an option "Would you like to be informed when you can send an encrypted e-mail? Yes / no / automatically"
yes >> You can encrypt the email. Send encrypted or unencrypted?
auto works automatically.
As an option - standard off. But you change the API and say, "Please explain to an 80 year old woman you have to select encryption before emailing me" >> Great job - user centered - agile focus on user and so on totally crazy.

But unfortunately that is normal, I see this behavior all day and then the companies wonder why more and more their software .... find it and it doesn't work.

It’s time to start contacting organizations who fund Mozilla and demand that they cut funding until Mozilla purges the NSA linked bad actors.

This isn’t the only ticket where they’ve intentionally removed preexisting security features, claimed it’s a “feature” to re-add the removed features, and let the ticket sit for years (some 19 years) but never do anything with it.

I won’t trust Mozilla again until they re-add DHE, HPKP, TLS Session Binding, and this ticket.

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

If encryption is turned on in the composer window for an individual message (either because you have enabled encryption for new messages by default, or you are replying to a message that was encrypted, or because the user has manually turned on encryption for the individual message), but it is impossible to encrypt, because for at least one recipient we don't have a valid and accepted key available, then Thunderbird will show a clear notification about this fact, and the notification will offer the user a path to discover how to resolve the problem.

Can you give a bit more detail about the "clear notification" when encryption is enabled (by default) but impossible? - I hope there is no messing around with disabling the send-Button. That would be cumbersome.
Maybe some kind of Popup, before sending? ("Encryption not possible, because of missing key for a, b, c." "Send unencrypted"/"Abort" - And maybe a third button: "Send encrypted to all possible recipients."?)

In other words, the configuration options will remain limited to "encryption on" or "encryption off".

We do NOT want to implement a third option "automatically encrypt if possible". There have been suggestions to automatically enable encryption whenever it is possible, and automatically disable encryption as soon as encryption isn't possible. We have discussed this, but we consider it a risk.

We want to put the user in control, allow the user to control easily, and avoid surprising the user with unexpected behavior.

About "user in control": At least a part of the users (already the 81 here - CC-Size of this Bug), want control in that way, that they can say Thunderbird: "Whenever I have the needed Keys, encrypt my messages." - In their situation, that's exactly the expected behavior.

I agree to the Risk of accidentally send sensitive information unencrypted. But in my opinion this consideration (vs. the risk of sending everything unencrypted - including possible sensitive information, because of "encryption is too cumbersome") can't be solved globally. The option "send encrypted if possible" is requested and imho it should be made available, at least to users that are able to use about:config.

(In reply to maison from comment #149)

However, encryption without signing shouldn’t be allowed, like other software already do (the reasons are explained here https://k9mail.app/2017/01/30/OpenPGP-Considerations-Part-II.html)

I absolutely disagree on that opinion.
The behavior described on the link doesn't convince me in any way. They write, in their client an encrypted but unsigned mail looks less secure than a plaintext mail. Well observed, but the problem isn't the encrypted-only mail, it's their decision to place a fullscreen warning on such mails. Is that some kind of joke?
The Enigmail styling looks absolutely fine for me: A pale information, that the mail was decrypted/is encrypted. No green sign, or anything else misleading towards authentication of the sender.

(In reply to deep_blue_ from comment #148)

As for me and my teams, privacy coming first,

If you argue about privacy, you should be worried about losing your
privacy accidentally. With an automatic behavior, you cannot rely on having
encryption in place.

I would like to share arguments to support the plan from comment 145.

I think it is very important that the user knows what will happen on send,
prior to hitting send.

With old Enigmail I remember that I saw the following behavior:

• I started to compose an email, and typed the first recipient.
• I saw that the user interface showed the icon for "encryption on",
  and I felt reassured, because that was what I wanted.
• I typed the email
• I added another recipient
• I didn't look at the message status agin, I was convinced that encryption
  was turned on
• However, I didn't have a key for the other recipient
• When I hit send, the message was sent without encryption,
  and when I found out, I was very unhappy.

I later tried to reproduce the scenario. At the time that
I entered the additional recipient, the UI element switched to "encryption off".
But I didn't notice when I was typing the message.

The problem with that UI was, shared controls were used for
"what does the user want" and "what is possible".

In my opinion, to avoid the confusion that I ran into, an implementation would
have to use separate UI elements for "what does the user want" (e.g. a three
state button being either "off" or "on" or "decide automatically"), and
"what is possible".

With an UI like that, at the time I checked the message settings, I would have
seen that the current setting was "encryption setting: decide automatically"
and would have gotten a current feedback item like
"it is possible to encrypt to this list of recipients".

Because I really wanted that email to be encrypted, I could have changed to
"encryption setting: on (required)" and it would have prevented
me from sending without encryption after adding the additional recipient.

I think the above would require us to reserve a lot of space for these
two UI elements, I think it would have to be done with text explanations
to ensure it can be understood well by the user.

(Remember, we need to implement a UI that works for users who don't
have a deep understanding of email encryption.)

If there was agreement to use a sufficient amount of space for the UI
elements, the above would be possible, but it might not look pretty.
(We'd have to find a way to make the UI still be acceptable for users who
don't use email encryption, i.e. don't reserve too much space.)

Let's look at another example.

Alice and Bob have exchanged keys once. Alice once configured the setting
"encrypt if possible". Alice sends emails to Bob. The mail client automatically
enables encryption. Bob receives encrypted email, and all is well.
Now, Bob's key expired. Bob didn't extend the key, or didn't send it to Alice.
Alice composes an email to Bob, and because Bob's key is no longer valid,
she sends an unencrypted email. Alice didn't even notice, because the user
interface didn't clearly warn her about it.

I think this is a good argument for not simply making automatic decisions in the
background. At the very least, a strong UI feedback would be necessary to remind
Alice that the message cannot be encrypted (contrary to her assumption).

You could argue that Alice might not care, because she has once enabled "encrypt
if possible". But is she fully aware of the consequences? Maybe someone else
helped her to set it up once. Or she simply gotten used to the fact that
encryption with Bob is on, and she relies on that, without being aware of the
setting that may disable encryption at any time.

A user interface like the one I described above (separate "want" and "can")
would be necessary to clearly inform Alice that encryption currently isn't
possible, and the message will be sent without encryption.

Requiring the user to manually switch between encryption and encryption off
avoids the risk that the user doesn't notice and that the message is sent
incorrectly.

There has also been the suggestion to use a prompt at send time, that tells
the user whether the message will be encrypted or not, and asks the user to
confirm. But I think these prompts aren't sufficiently helpful. With muscle
memory, it's easy to accidentally press enter again to confirm such
a prompt, without having read it.

My point is, an encryption of "implement if possible" has risks, and it would
require a complex UI to avoid confusion.

It seems like a helpful improvement to start by giving good feedback to the
user, that will say what's possible or what's wrong with the current encryption
setting.

We're currently hoping that the intended implementation will be sufficiently
clear and simple, and that it will make it unnecessary to implement
"encrypt if possible".

Once we have reached that milestone, if there's still a desire for an
encrypt if possible mode, we can potentially revisit the idea.

If you want to make sure encryption is in place, you need a flag in your address book that says "this recipient should always be encrypted" so it can pop up a warning if the key is missing or expired.

You never want to send the same message both encrypted and unencrypted - it needs to be all or nothing.

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

I would like to share arguments to support the plan from comment 145.
[...]

Thanks a lot for all the effort spent in the discussions and explaining this in detail!

(In reply to tkitt from comment #153)

About "user in control": At least a part of the users (already the 81 here - CC-Size of this Bug), want control in that way, that they can say Thunderbird: "Whenever I have the needed Keys, encrypt my messages." - In their situation, that's exactly the expected behavior.

I agree to the Risk of accidentally send sensitive information unencrypted. But in my opinion this consideration (vs. the risk of sending everything unencrypted - including possible sensitive information, because of "encryption is too cumbersome") can't be solved globally. The option "send encrypted if possible" is requested and imho it should be made available, at least to users that are able to use about:config.

I completely agree with this.

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

In my opinion, to avoid the confusion that I ran into, an implementation would
have to use separate UI elements for "what does the user want" (e.g. a three
state button being either "off" or "on" or "decide automatically"), and
"what is possible".
[...]

If you think adding an "Encryption if possible" option would require that, I'd much prefer those extra UI elements to not having an "Encryption if possible" option at all. I personally don't see this as absolutely necessary, since users who select that "Encryption if possible" option have to do so explicitly, and maybe another option would be to show a huge warning sign in the options when doing so, explaining why this is "dangerous"?

We're currently hoping that the intended implementation will be sufficiently
clear and simple, and that it will make it unnecessary to implement
"encrypt if possible".

Once we have reached that milestone, if there's still a desire for an
encrypt if possible mode, we can potentially revisit the idea.

I'm happy to try this out once it's there, but I'm sceptical. So far, the missing "Encryption if possible" option has been what has bothered me most since the Thunderbird 78 upgrade that made Enigmail non-working. For me a "It may come back, we just didn't have the time to implement it yet" perspective was more motivating to wait than "We don't want to have it back". So personally, I'm at least considering to try out alternative email clients (like KMail, which has a "Encrypt whenever encryption is possible") in the meantime as well.

The whole point is paternalism.

They say what is good for us users and what we don't want you to allow stupid users to do.

Your arguments (on safety) and ours (on usage) are both correct.

The point is that everyone has to decide for themselves. It's like a corona vaccination. Everyone can decide for themselves. But for that there has to be an option.

Conclusion: Install the option and, if in doubt, knowingly activate it via about: Config and everyone would be very happy. Bissel maybe even build in more configuration options -> everyone can do it as they want. If you hack the Thunderbird settings, you will be able to read the email even after it is decrypted. Why do we talk here as long as politicians? Let's just implement it and the citizen decides for himself which option he wants to use. DEFAULT-off

E.g. I do not need an automatic I need a semi-automatic with a note when sending an email: You can send encrypted, if you want yes / no.

(In reply to berggeist01 from comment #159)

The whole point is paternalism.

They say what is good for us users and what we don't want you to allow stupid users to do.

Your arguments (on safety) and ours (on usage) are both correct.

The point is that everyone has to decide for themselves. It's like a corona vaccination. Everyone can decide for themselves. But for that there has to be an option.

Conclusion: Install the option and, if in doubt, knowingly activate it via about: Config and everyone would be very happy. Bissel maybe even build in more configuration options -> everyone can do it as they want. If you hack the Thunderbird settings, you will be able to read the email even after it is decrypted. Why do we talk here as long as politicians? Let's just implement it and the citizen decides for himself which option he wants to use. DEFAULT-off

E.g. I do not need an automatic I need a semi-automatic with a note when sending an email: You can send encrypted, if you want yes / no.

why is that way not possible?

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

I would like to share arguments to support the plan from comment 145.

I think it is very important that the user knows what will happen on send,
prior to hitting send.

With old Enigmail I remember that I saw the following behavior:

• I started to compose an email, and typed the first recipient.
• I saw that the user interface showed the icon for "encryption on",
  and I felt reassured, because that was what I wanted.
• I typed the email
• I added another recipient
• I didn't look at the message status agin, I was convinced that encryption
  was turned on
• However, I didn't have a key for the other recipient
• When I hit send, the message was sent without encryption,
  and when I found out, I was very unhappy.

The old Enigmail, has an option, to show confirmation dialoge windows with info: send OpenPGP/S-MIME + signed/not signed + encrypted/unencrypted - Do you want to send ?

look at this screen of enigmail setting: https://www.enigmail.net/documentation/5-02-1.9.png

(In reply to berggeist01 from comment #159)

E.g. I do not need an automatic I need a semi-automatic with a note when sending an email: You can send encrypted, if you want yes / no.

This is basically the plan for how it will work yes (with a notification bar, not confirm dialog). Like Kai wrote, we hope that the implementation will be easy/clear enough that there is no need for automatics. Yes, it will be one click more for some situations. I think that is a reasonable weigh-off though.

(In reply to berggeist01 from comment #151)

As an option - standard off. But you change the API and say, "Please explain to an 80 year old woman you have to select encryption before emailing me"

With what we plan you would not have to do that. If you want her to use encryption, you set up to use encryption. She would have to click a button in a notification if she wishes to NOT use encryption for that email.

I am excited.

Sorry, then my misunderstanding is due to my poor English.

My family members (the normal user) just need to see it and be asked to take action.

I still think that if you want it automatically, you should get it. I think in the end you could even make 2 e-mails out of it, if the e-mail cannot be encrypted because of a recipient (incl. Warning & option :))

(In reply to Magnus Melin [:mkmelin] from comment #163)

(In reply to berggeist01 from comment #151)

As an option - standard off. But you change the API and say, "Please explain to an 80 year old woman you have to select encryption before emailing me"

With what we plan you would not have to do that. If you want her to use encryption, you set up to use encryption. She would have to click a button in a notification if she wishes to NOT use encryption for that email.

Most people don't have encryption. My mom would get a "Cannot send error message" if the encryption is standard. She never understood that. She never finds a deactivation, and she thinks she can't send emails. And I have the next service call :)

We'll add a key assistant to guide the user through sending if there is trouble.
I think we should also guide the user through setting up their own keys in the first place - but that is for some other bug.

Dear Kai,
thanks for the explanation, and I hope this clarification/simplification will speed up (TB 103?) the implementation of the improved UX/workflow to send unencrypted emails with "require encryption by default": something that was already implemented for years in enigmail, see comment 161 https://bugzilla.mozilla.org/show_bug.cgi?id=135636#c161). I think its very important to note how challenging the everyday use (not setup!) of encryption is for normal users: if an email cannot be sent because of missing/expired key, a lot of people will think they have a mailserver problem (see comment 165 https://bugzilla.mozilla.org/show_bug.cgi?id=135636#c165), and this will cause frustration on both ends (user + IT personnel). But it seems this will be fixed now, thanks!

Can it be assured that the openpgp-alias functionality will stay: https://bugzilla.mozilla.org/show_bug.cgi?id=1644085 (?)

It would be great if encryption settings during composing would be available via an API, so a "encrypt if possible" would be an option after all via an addon. BTW: protonmail silently sends encrypted/unencrypted messages with one click of the send-button, with not even a warning. I'm not agreeing with this behaviour myself, but it may give an indication how much one of the more secure email providers (I would say) compromises security in favor of workflow/usability.

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

(In reply to deep_blue_ from comment #148)

As for me and my teams, privacy coming first,

If you argue about privacy, you should be worried about losing your
privacy accidentally. With an automatic behavior, you cannot rely on having
encryption in place.

Not only my privacy. Privacy of my teams.

Most of our external contact do not use pgp. My Teamates are awesome but most of them won't accept or bother to click on 80 percent of their mail to acknowledge that it won't be encrypted.

In UX point of view the implementation you want to set up add a quasi systematic click. Which add a huge usage cost on one of the primary feature of a mail client, in fact it double it as we pass from a simple click to 2 in most cases. I'm pretty sure it won't help to democratize pgp feature.

In my case I send around fifty mail a day. around 30 can't be ciphered. With your implementation it means it add 30 popup and 30 click to do what I want. If you look at KMAIL it propose different behavior from automatic to ask anytime, letsencrypt extension let you do the same.

Just to be clear, I'm nobody to say that you should implement it this way or another. I'm just saying for my philosophy and usage the orientation of Thunderbird is not the good one for my personal use. I'm pretty sure that not even 1% of the user use pgp en half of them don't bother to understand how it to work and pick up a random mail provider such as protonMail.

Beside the usage cost. I think Mail client nowadays should focus on democratizing privacy technology. Democratization come with easiness not difficulties. Ones again it's just a personal opinion from a simple user..

(In reply to tkitt from comment #154)

(In reply to maison from comment #149)

However, encryption without signing shouldn’t be allowed, like other software already do (the reasons are explained here https://k9mail.app/2017/01/30/OpenPGP-Considerations-Part-II.html)

I absolutely disagree on that opinion.
The behavior described on the link doesn't convince me in any way. They write, in their client an encrypted but unsigned mail looks less secure than a plaintext mail. Well observed, but the problem isn't the encrypted-only mail, it's their decision to place a fullscreen warning on such mails. Is that some kind of joke?
The Enigmail styling looks absolutely fine for me: A pale information, that the mail was decrypted/is encrypted. No green sign, or anything else misleading towards authentication of the sender.

This thread is about email compose and there is absolutely no logical or cryptological reason to send encrypted email without signing.
What you are describing is different. Of course if other software still sends encrypted and not signed email, you receive it and you have to do something about it. How to present it is a different debate which can be done on another thread.

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

Thanks, for the explanation, and for everyone's effort to discuss it and their attempt at improvement.

I find the solution you propose acceptable.

Silently encrypting only to a subset of recipients but not others is not a sound practice, leading to a false sense of security, because the same message which is believed to warrant encryption will still be sent on the wire unencrypted, thus defying the aim of encryption. The message is -- generally -- the determinant here, not the recipient.

It could be argued that each recipient's threat analysis could dictate different choices in regard to encryption, even when the message is the same, for example when one recipient is in political/legal environment where certain communications could criminalise them but not the sender or other recipients. However, approaching the complexity of cases such as these can be left to supplementary implementations, i.e. extensions, the likes of which did exist for previous versions of Thunderbird/Enigmail. So the proper thing to ask for here is a good API that would allow others to build such more complex and customisable functionality on top of this most likely use-case.

(In reply to maison from comment #169)

How to present it is a different debate which can be done on another thread.

You are right, sorry for my little rant. It was just the most obvious point in the linked article and the one that raged me a bit.

[...] there is absolutely no logical or cryptological reason to send encrypted email without signing.

As stated above, I disagree. - Signing and encryption are measures to reach different security goals.

The primary security property reached by encryption is confidentiality. The primary security property reached with asymetric signatures is non-repudiation.
I know authenticated encryption is a good thing, some nice CCA-Proofs and so on. But authenticated encryption regularly is achieved via symmetric signatures (linke AEAD), because they give authentication but not non-repudiation/ don't deny "plausible deniability".

In the article they neglect the possibility of plausible deniability by making assumptions about the environment. While these assumptions are an option to decide which default settings to choose, this is imho no valid option when deciding which things to allow at all, because they are what they are - assumptions. And assumptions could, but don't have to be true - especially not always.
(And yes, in most cases I argue against reducing configuration options, and enforcing to do things, like the developer think, they are right. - Haven't found any better translation for the term that comes to my mind in these situations: "bevormunden".
And especially in this case, on top, it would be a regression, too.)

(Sorry for the a bit poor language quality. While writing I got some ideas regarding actual limits of my English language skills... I hope it's comprehensible.)

Regarding the discussion to encrypt without signing.

We don't need to discuss this in this ticket. We already support it, and currently we don't intend to remove this functionality. Each of signing and encryption can be separately used, or both, or none.

We think that there is value in enabling signing whenever you encrypt, that's why we automatically enable it for an individual message, if you enable encryption. However, we don't enforce it, and you can always manually disable signing.

I'm very disappointed by this decision and as it looks like a lot of people are too. Why can't the developers acknowledge that there are use cases where "encrypt if possible" is the desired and needed option. Instead they're constructing cases where the user makes an error and then decide that nobody should have this option because of that. If you want to avoid user errors, have a clear indicator next to the "To" field with the status of the email encryption with green and red colours. At the moment it's "hidden away" grey on grey in the far right corner of the status bar.

Other email clients/plugins like K-9 Mail, PGP4Win (GPGOL) and Thunderbird <78 have the option to auto encrypt. Have a read how K-9 handles it.

https://k9mail.app/2018/02/26/OpenPGP-Considerations-Part-III-Autocrypt.html

If you think "encrypt if possible" is unsafe, just don't use that option for yourself. But don't make this decision for other users. If you wish, hide that option from the average user or have a big warning sign next to it.

If you stand by your decision, most users who use TB with encryption will have only 2 options, either stay with TB 68 or use another email client.

Let me know write about my use case which worked for many years until you broke it in two ways. I administer an office with about 20 users. All emails between these users should be encrypted. External emails are usually not encrypted, apart from emails to the accountant. I, as admin, set up all keys for the users and store all public keys in a read-only share. When the user logs in, all public keys get imported into the user's key ring. This way new keys will get populated automatically without user intervention. Now you broke this workflow too by using your own key store without providing tools to automatically import new public keys. All users know that all internal email is encrypted by default. Now I can't use this option anymore without requiring a degree in computer science from my users.

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

Regarding the discussion to encrypt without signing.

We don't need to discuss this in this ticket. We already support it, and currently we don't intend to remove this functionality. Each of signing and encryption can be separately used, or both, or none.

We think that there is value in enabling signing whenever you encrypt, that's why we automatically enable it for an individual message, if you enable encryption. However, we don't enforce it, and you can always manually disable signing.

Well, only in theory. Currently TB forgets the sign settings and it can send email the wrong way without user notice: see the case study in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1744835 It happened to me that unsigned email was sent several times in spite of the identity requiring it. In this regard the automatic signature joins the current debate: if your settings require a signature, but it can’t be provided, then the user should be warned as well and offered to remedy it.

(In reply to mozilla.org from comment #173)

I administer an office with about 20 users. All emails between these users should be encrypted. External emails are usually not encrypted, apart from emails to the accountant.

Alice and Bob work at your company. Charlies is not a member of your group.

Alice sends an email to Bob. In your setup, the email is encrypted. Bob reads the email. Bob clicks reply, which will quote the original email. Bob decides to CC Charlie, because he thinks the information may be useful to him.

In your setup, the encryption for the message is automatically and silently disabled, because there is no public key for Charlie. The previously exchanged message is now sent in plain text, including Bob's reply.

It sounds very risky to me to break the assumption that internal email is encrypted, simply by adding another recipient.

With the UI we're suggesting to implement, we'd show a warning that encryption isn't possible. It would require Bob to think about the contents of the email, and whether it really should be sent to Charlie without encryption.

TL;DR: Please spare me any extra click for encryption.

I can understand the developers latest decision from a fundamentalist point of view. However, on the long term, it won't benefit proliferation of e2e encryption in emails -- and thus I can understand why some think this is intentional, given the hassles of operating encryption in TB in recent versions. (I still find myself checking in the options menu and do up to four clicks to select the correct encryption setting... I know there are two rather unimposing icons in the status bar but never got used to look there first as this would be an additional step. It really would help me if the send button had a green padlock or certificate icon.)

I'm extremely unhappy with the situation a.t.m. and I'm curious about the planned GUI and how it will work out for me.

If this is really about space, remove the security button and move it left next to the send button, naming it 'send encrypted' (maybe with a drop-down 'send encrypted and unsigned' + 'unencrypted but signed') and show it only if encryption is possible. If the accounts default is 'encrypt', change the send button to 'send unencrypted' to make it clear.

Alice sends an email to Bob. In your setup, the email is encrypted. Bob reads the email. Bob clicks reply, which will quote the original email. Bob decides to CC Charlie, because he thinks the information may be useful to him.

In your setup, the encryption for the message is automatically and silently disabled, because there is no public key for Charlie. The previously exchanged message is now sent in plain text, including Bob's reply.

"Unencrypted quote-reply to encrypted message" is a separate issue. Replies to encrypted messages MUST be encrypted by default regardless of whether a global "encrypt where possible" feature is implemented.

I propose a compromise: that the encrypted/unencrypted state change should be asymmetric. If an MUA decides that encryption is possible, it MAY enable encryption without prompting the user, so long as it indicates this state change clearly in the UI. If the MUA later decides (e.g. if another recipient has been added) that encryption will no longer be possible, it MUST prompt the user to choose a resolution. This way, upgrades are smooth and downgrades are noisy.

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

Alice and Bob work at your company. Charlies is not a member of your group.

Alice sends an email to Bob. In your setup, the email is encrypted. Bob reads the email. Bob clicks reply, which will quote the original email. Bob decides to CC Charlie, because he thinks the information may be useful to him.

In your setup, the encryption for the message is automatically and silently disabled, because there is no public key for Charlie. The previously exchanged message is now sent in plain text, including Bob's reply.

In our setup Charlie will be also one of the 20 internal users. We don't CC external parties. When we email external parties, then these emails contain only this one address in the To header.

It sounds very risky to me to break the assumption that internal email is encrypted, simply by adding another recipient.

See above and that's why there should be a visible (red) indicator, if the encryption status changes to unencrypted for any reason.

With the UI we're suggesting to implement, we'd show a warning that encryption isn't possible. It would require Bob to think about the contents of the email, and whether it really should be sent to Charlie without encryption.

I guess we need to see what you mean by a "notification will offer the user a path to discover how to resolve the problem". If it's a red indicator near the send button or the To field, that would be fine. If it's a popup "Do you want to send this email without encryption" with a OK button, then it might be ok. Anything more than this with several clicks and changing some settings which the average user won't understand is not ok.

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

Alice sends an email to Bob. In your setup, the email is encrypted. Bob reads the email. Bob clicks reply, which will quote the original email. Bob decides to CC Charlie, because he thinks the information may be useful to him.

In your setup, the encryption for the message is automatically and silently disabled, because there is no public key for Charlie. The previously exchanged message is now sent in plain text, including Bob's reply.

You can't control what a recipient does with a message - Bob could just as easily have forwarded it to Charlie. You are inherently trusting the recipient when you send them a message.

The solution proposed in https://bugzilla.mozilla.org/show_bug.cgi?id=135636#c145 would already be a huge improvement, so thanks for giving it some thought! What would be more useful than a bunch of people figuring out the supposedly best solution based on their old habits would be to actually implement a prototype, do some user testing with that, and then improve things incrementally based on the observations of that user testing. Having actual people test prototypes is the only thing that will help developers understand how users interact with a graphical interface, which is often quite different from how they imagined it would be used. Thanks for your work!

Which problem are we trying to solve

1. Make it easy for the 1% of power users to use encryption safely in Thunderbird?
2. Get the 99% of users who do not use encryption to start using encryption?

I want to solve question #2. For these users, convenience always wins over privacy/security. We should compare no encryption, which is what they use today, with automatically encrypt when possible. For these users, nothing is less safe/private than what they do today.
One extra click or sometimes a different behavior will put them back in to 'never use encryption'.
I have gotten my 80-year grandmother to use VPN because nothing changes for her. Email encryption with Thunderbird is not even close.

I and all the users in this thread can do encryption with or without Thunderbird but are we designing for the existing users of encryption (us) or the untaped 99% of the market?

Regards, Hagar

Thanks so much @hagar and @kai for the hard work and for providing us an update.

My use case, which I believe is at the core of this ticket: I frequently email family and non-family.

1. When family emails each other, we want encryption to be automatic and impossible to get wrong. No dialog boxes, no checking of indicators, no having to remember to click on something. Anything but this risks sending an unencrypted email.

2. If I cc other people, I need a warning.

3. If I mail non-family, no encryption. No dialog box, no clicking anything.

This way I can send emails all day, every day, and not have to think or perform extra steps. And I can't make a mistake.

Can you confirm this behavior will be possible with your changes or that a plugin will be able to implement it?

(Other readers: What client have you switched to that allows this?)

Thanks for the update, Kai.

I'd be happy if the proposed solution would suffice, but I'm convinced, that the psychic effort of a click each mail is the actual problem here. Imagine, one day your favorite e2e encrypted chat messenger starts to expect you to activate encryption for each message. This is, what Thunderbird feels like since the upgrade and this won't change, until it works without that click.

It worked perfectly fine with enigmail for years. Neither I nor the people I taught mail encryption had any serious problems. I can't remember to send or receive any accidentally unencrypted mail ever. If you had higher security requirements, it was easily possible to choose the "always encrypt" option, so you could be really sure that no information is leaked. This could still be the default setting to reach your goal of security by default, even if "encrypt if possible" is offered as another choice. With regards to that I don't get the "we want the user to be in control" part to be honest. I think, there's a reasonably save way to implement "encrypt if possible", which does neither violate the user expectations nor put them at risk. At the risk of repeating, what others brought up so far and essentially describing, how enigmail worked - with some tweaks - I want to address your concerns on the basis of the former working solution.

With respect to the distinction of the indicators for "want/can encrypt" i differentiate between "want encrypt" and "will encrypt":

• The "want" state could be determined once in the settings as default (maybe offered as wizard on first keypair generation and maybe additionally overwritable per mail in the current dropdown), which frames the user expectation with the choices
  • No encryption
  • Encrypt if possible
  • Force encryption
• The "will" state - indicating if it will be effectively encrypted (on) or not (off) - should be placed as prominent indicator icon with intuitive feedback (like green/red). It should be possible to check the state with one glance before sending and to be sure, that the indicated action will be performed. Clicking on this indicator will switch between forced encrypted (on state) or forced unencrypted (off state) sending (so there is no way back to encrypt if possible, which is ok, as user interaction means, that some behavior should be enforced). Maybe some additional Icon hint could be added to see, if the choice is made automatically, which would vanish on the first manual interaction (like a star in the corner or a border color). On mouseover, additional information could be provided, why some state was chosen ("manually switched on/off", "key for X missing/expired/revoked"). To address your concerns about missing the state change, when the recipient list is changed, an Icon/Color/Bordercolor could be added to the recipient itself. Another way to mitigate this would be an optional additional dialog to confirm the state, as enigmail offered it with a checkbox in the settings to activate the confirmation. In my experience the dialog is not needed, if the indicator is good enough.

There would be no need to place another want indicator on a prominent place, as

• users with No encryption setting don't expect mails to be encrypted, but could turn it on for each mail via the will indicator
• users with Encrypt if possible setting expect it to work out of the box, can check the effective state with a glance, and can enforce encryption on demand with one click (this would be the same user effort and outcome as in your current plans) or deactivate encryption with two clicks on the will indicator
• users with Force encryption setting expect all mails to be encrypted, but could turn it off for each mail via the will indicator

Addressing your further remarks about breaking the user expectation, there are two cases which should be handled differently:

• New mail / Reply to unencrypted mail (upgrading to encryption should never hurt)
  • No encryption: Nothing to do
  • Encrypt if possible
    • On recipient change: Update will indicator (maybe recipient indicator), on if keys exist for all recipient emails, off otherwise
    • On send: Provide resolution path if some key is expired/revoked, send encrypted mail otherwise
  • Force encryption:
    • On send: Provide resolution path if some key is missing/expired/revoked, send encrypted mail otherwise
• Reply to encrypted mail: Never downgrade to unencrypted. Provide resolution path, if some key is missing/expired/revoked, send encrypted mail otherwise

The resolution path could include the options:

• try an update of the key via WKD / PKI
• choose a key manually for each missing/expired/revoked key (a big enhancement here would be instructions, what to to - in my experience key expiration is the most confusing part for non-technical users some years after the workshop)
• send unencrypted

As far as i can tell, all of your concerns should be addressed with this approach. People with higher security standards could keep the default force encryption setting. The user expectations for the encrypt if possible are met in a save way, as replies to encrypted mails and all mails to recipients with expired/revoked keys never downgrade silently but lead to one general resolution dialog instead (where it could be sent unencrypted with one click). It would work perfectly well with your current plans of one prominent indicator and resolution path without additional UI changes. Am I missing something?

I also want to emphasize, that simplicity is the key to scale mail e2e encryption beyond the group of technical experienced people and firmly believe, that the option encrypt if possible will do way more good than harm. Please reconsider your decision and enable the user to choose a mostly frictionless encryption mode, which already has proven to work for years.

IMHO your threat models are wrong.

Doing proper security is first having a proper threat model (= what are the most likely attackers and flaws). A good part of this issue at stake seems to revolve around the fact that threat models appear to be wrong.

1/ The idea of never sending both encrypted and unencrypted relies on the hypothesis of an omniscient attacker, like a powerful state spying on people. It's a common scenario, but far from the only one. Your company, tech-savvy revengeful roommate, local restaurant with poor Wifi+poor server TLS... there are many credible scenarios without an omniscient attacker. If your recipient with encryption is the only possible victim amongst other recipients, it makes sense to still send it (now it gets trickier in multi-party discussions, but for a one-time send esp. Bcc the point is obvious) . In fact, even if you don't know who are the most likely victims, it still makes more sense to encrypt some than to encrypt none, statistically. Not to mention, of course, getting e2ee to the general public.

2/ The idea of never sending unsigned encrypted messages is a good one in theory, but relies on the hypothesis of an active attacker (= that can modify content). Same as previous point : it's common, but far from the only one. There are many (more) passive attacks, and if you consider the ergonomy problems we're having regarding encryption, you know you WILL find yourself in situations where you NEED to send an email immediately, but have no private key on the current computer for some reason. Better to send it encrypted than not encrypted at all : for all you know, the attacker may not be more than passive, and you can still confirm with your recipient via other channel that it's unsigned. STILL better than unencrypted.

There definitely IS value in not having all settings at mandatory maximum security all the time. All I'm saying is "false sense of security" can't be an excuse for everything. Case in point : it has lead to less security.

As for the GUI : it seems to me the encryption state (encrypted, signed, both or none) in the context of encrypt-if-possible CAN be displayed per recipient easily, in the autocomplete field. Look at how Vuetify does it : https://vuetifyjs.com/en/components/autocompletes/#item-and-selection

You shouldn't shy away from using colors, icons, and maybe tooltip for a full user help.

(Sorry I didn't mean to teach you security, more like get the point across for all participants)

If I may reformulate : you need a better UI to dissipate the false sense of security & clarify the situtation before sending, not block the feature (nor hide it behind dialogs). Thank you.

(In reply to damien.d from comment #184)

IMHO your threat models are wrong...

• 1

Not sure why my plus 1 did not show properly +1

Now, the current mode is still relevant for a minority of people who really can't afford a mistake (but this means they can afford to read the guide and take proper precautions). Maybe that can be present but disabled by default ? Thanks again.

Email use on Thunderbird, I'm sure, will be on average less secure because of this regression: now you have to choose between "all encrypted" and "never encrypted", and if you choose "all encrypted", then you have to lose three seconds per email sent on average, because most sent email is unencrypted. So anyone will end up going "never encrypted" and then forget to encrypt.

Thus it is a regression from the former behaviour of Thunderbird (with Enigmail), even though I acknowledge the fact the latter was not perfect, however it worked better on average. To want a UI experience 100% perfect, you need to overhaul everything, I understand, but meanwhile you'll have thousands of people deactivating encryption because it is too much a hassle.

This regression is equivalent to put up a new notification after an upgrade that reads “now encryption is very difficult to use, would you like us to deactivate it for you?”

+1

(In reply to nucleos from comment #190)

... but meanwhile you'll have thousands of people deactivating encryption because it is too much a hassle.

... or not updating and staying with 68.x where everything works as it should.

How can this be a problem 20 years later??? wtf

I just sent an email and forgot to encrypt it, found my way here trying to find out why a email cannot automatically select encrypted where a key exists for the destination address, or a flag in the address book to always encrypt for this address.

How on earth does this problem exist so long, I'm shocked at the 20 year age of this bug.

You guys have a fantastic product, and a tremendous thank you is in order, but please at the very least put a check box in the address book for always encrypt this address.
It appears that Thunderbird already peeks into the address book for the Prefers message format (Unknown, HTML, Plain text), just stick a check box under there for "Always Encrypt messages" or (Yes/No)

I'd say it's time to wrap this one up, please give it consideration.

Bless you all and Thank you;

(In reply to George from comment #195)

I just sent an email and forgot to encrypt it,

While we're not yet ready to provide automatic encryption, we'll try to add a reminder, shown in that situation, in bug 1771122.

I'll also land a few strings here, that we could potentially need later.

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

(In reply to George from comment #195)

I just sent an email and forgot to encrypt it,

While we're not yet ready to provide automatic encryption, we'll try to add a reminder, shown in that situation, in bug 1771122.

I'll also land a few strings here, that we could potentially need later.

Bless you, that would be fantastic.

Thank you.

In the meantime we have released Thunderbird 102, which has the improvements that were previously announced.
It should make it much more easier to enable or disable encryption.
If the user's account is configured to support encryption (have own keys/certificates), and the user starts to compose an email, and Thunderbird notices that there are valid and accepted OpenPGP keys, or valid S/MIME certificates, available for all recipients, then Thunderbird will remind the user that encryption is possible for this message, by showing a notification bar. It then takes just clicking a single button (inside the notification or on the toolbar) to enable encryption.

Despite that, I understand that this doesn't yet address the request of this bug, which asks for fullly automated enabling or disabling of encryption.

I would like to make an attempt to offer this functionality, I have an experimental patch that I would like to offer for testing, and I'm interested in feedback.

To enable the functionality, in account settings, besides the choices to enable or disable encryption for new message, the experimental patch adds a new third choice, which offers to automatically enable or disable encryption.

The thoughts behind the experimental implementation are:

• the user must be able to see on screen what will happen at the time the message will sent (prior to clicking the "send" button)
• no prompts (the user shouldn't be required to perform any choice)
• ensure the user can notice if encryption is automatically disabled

The last point is my primary concern of any solution that we consider.
I'm worried about the following scenario:

• The user composes an email, and enters one initial email address.
• We can encrypt, we automatically enable encryption. We show status in the UI that encryption is enabled.
• The user notices that encryption is enabled, makes a mental note that it is enabled, and feels safe about typing sensitive information.
• The user prepares the email, writes all the text, and the user is almost ready to send it.
• In the last minute, the user decides to add another recipient. But we cannot encrypt to that recipient.
• Because the user is in automatic mode, we automatically disable encryption.
• However, the user might not notice that we automatically disabled encryption

It is very important to me that we'd use an implementation that strongly makes the user aware, whenever encryption was previously enabled, but Thunderbird decides to automatically disable encryption (because it isn't possible, and because of the configured mode to automatically decide).

WIth the experimental patch that I'm providing, a warning notification will be shown on screen, in bright yellow, which says "End to end encryption was automatically disabled, because you cannot encrypt to at least one recipient."

My questions are:

• is this warning sufficient to address my concern? For users who had previously noticed that encryption was automatically turned on (visualized by the changing state of the encryption toolbar button), can we assume that this notification is sufficient for those users to realize that encryption turned off again?
• can everyone asking for the full automatic behavior tolerate this notification?

(If you were reading this from the email notification, please read the updated comment in bugzilla, I've fixed a few typos/mistakes.)

I like your approach in principle. I would just add that if a warning message is displayed, it should always be as specific as possible. “You cannot encrypt to at least one recipient” is good, but vague. “You cannot encrypt to the following recipients: <foo> <bar>” is much better. Warning messages that could have supplied more information but didn't are one of my pet hates. ;-) If there is too much detail to display at once, hide it under a dropdown or a link, but still make it available for those who really want it.

As a further enhancement, you could have hot buttons for remediation actions, e.g. "remove these recipients" or "send without encryption", and refuse to send until the user explicitly picks one. This might be too intrusive for most though, so should probably be opt-in (and doesn't have to be addressed right away).

Andrew, thanks for your feedback. Did you already try the Thunderbird 102 release, and have you already experienced the improvements we made to encryption settings in the composer window?

(In reply to andrewg from comment #202)

“You cannot encrypt to at least one recipient” is good, but vague. “You cannot encrypt to the following recipients: <foo> <bar>” is much better.

If there are many, the list can get long. We already have a way to communicate problematic recipients.

If the user explicitly enables encryption (either because that's the default setting for new messages, or because the user has explicitly clicked the "encrypt" toolbar button in an individal message), then we already give visual feedback about the encryption-incompatible recipients: We show the problematic email addresses with highlighting color.

But we do so, because in "requested encryption" mode, those really are causing a problem - cannot send encrypted.

Please remember that we're talking about this new mode, when the user has explicitly stated they simply want it to be handled automatically. If the user has said they want it to be automatically decided, then why should we highlight what the problematic recipients are? They are no problematic recipients in automatic mode, because we can send without encryption.

My impression is, the request for an automatic mode is "don't bother me if encryption isn't possible". And highlighting problematic recipients, whether it's with a color, or listing them in a text message, could be considered as too much bothering. The user might still get the impression that something is wrong and must be fixed. But in automatic mode, there is no need to fix anything.

I see three scenarios:

• the user really doesn't care, then the user will be ok with not encrypting, and doesn't need the information what's causing the non-encryption
• the user really wants to encrypt. In that case, the user should override the automatic decision and click the encryption button to require it. And that, already today in the production 102 version, will give the user the feedback you're asking for. Thunderbird will highlight all recipients that are problematic, will display a summary, and will offer to open a key assistant, which will show in detail which users are problematic, and will even attempt to assist the user to resolve this situation
• the user doesn't think encryption is necessary, but the user is simply curious to learn what's causing the problem. In this scenario, I'd prefer to avoid that we have to introduce an additional mechanism to give this feedback to the user, I'd prefer to reuse the feedback described above. If the user is curious, they can enable encryption, look at the state, and if they decide they don't want to encrypt, they can manually turn it off again.

So in order to fulfil your request, we'd have to make the user aware of the above approach that can be used to see the list of problematic users.

Maybe this could be achieved by using a different notification message, like:
"End to end encryption was automatically disabled, because you cannot encrypt to at least one recipient. You may manually enable encryption to learn more."

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

My questions are:

• is this warning sufficient to address my concern?

Yes

• can everyone asking for the full automatic behavior tolerate this notification?

I worry that noob users are confused about it and any user gets annoyed about it if they often write to several people in one email and at least to one of the recepients can not be encrypted. I worry that users say "this encryption thing is just complicated annoying, I just disable it to get rid of this warning every time, so all just works fine again like in the good old time."
The every day "Warning" could disturb users or they get used to that everyday warning and at the end click away any warnings at all.
Alternative without "Warning": If encryption is not possible for all recipients, after clicking on send button open a rather neutral popup saying "Send mail unencrypted. <OK> / <Cancel>"

I would prefer not to have any whistles and bells in automatic mode.

Thunderbird decides to automatically disable encryption (because it isn't possible, and because of the configured mode to automatically decide).

If sending to two recepients, and to one can be encrypted and to the other not, will in automatic mode the mail to the encrypt-possible recipient be encrypted but to the other recipient sent in plain text, or will be sent to both in plain text? The latter case I think would not be "Encryption when possible" that is the title of this bug? Maybe there should be a visual toggle for every recipient that shows if for that recipient encryption is enabled or not, and it should be encrypted for all recipients where possible?

Andrew, thanks for your feedback. Did you already try the Thunderbird 102 release, and have you already experienced the improvements we made to encryption settings in the composer window?

Yes, I did! The changes do look good, they're a great improvement so far.

If there are many, the list can get long. We already have a way to communicate problematic recipients.

Yes, and these are great for must-encrypt mode, as they clearly indicate problems that must be addressed. But do you intend that these will also be used in opportunistic-encryption mode? If so, they seem visually too strong for what we're talking about here, as they imply an error rather than a warning. Or do you mean a similar kind of notification with different (less urgent) styling?

If we want to remain consistent with the To: field notifications, maybe a better idea would be to highlight (subtly) which recipients can be encrypted to, rather than those which can't. This way, the user would still get visual feedback but in a much less intrusive manner. These could even be displayed regardless of the opportunistic-encryption setting (a gentle reminder of what is possible, rather than what is impossible).

After thinking about it a bit more, there are four classes of recipient in a 2x2 matrix of "encryption possible" (i.e. valid key available) vs "encryption required". It is no longer possible to set "encryption required" per recipient, but the concept is still useful when thinking about visual cues in the (must|may|don't) encrypt operation modes.

If encryption is impossible but required, then the current yellow warnings are perfect. If encryption is impossible but not required, then the default styling is appropriate. Considering the other two possibilities:

• If encryption is possible but not required, then perhaps a subtle decoration (e.g. a lock badge) could be added to the name, similar to the address-book dot (and with a similar tooltip explanation).
• If encryption is possible and required, then should the default styling be used (since no action need be taken), or something distinct (as a visual confirmation)?

One big caveat is that putting a lock symbol of any kind in the To: field has a variety of possible (mis)interpretations. But relying solely on colours raises accessibility concerns.

Also re styling, is it intentional that the "Encrypt" button in the compose window doesn't darken when selected, even though similar buttons elsewhere in the UI (e.g. "Quick Filter") do? I think if the "Encrypt" button darkened on selection then encryption mode changes would be much less likely to get overlooked.

Regarding visualization: I agree with andrewg, that an information about the recipients without key would be good.
If you care about too long lists, than I would propose: Under a limit of maybe 2, 3 the recipients are shown in the warning and above a hint like "Press the <Encrypt> Button, if you want see all unsupported recipients." ("Encrypt" maybe could be a link/"hot button".)

If you disagree with showing them entirely, at least the (text) hint how to get them visible would be good.

I haven't tested 102 or the patch so far, but both sounds like good improvements.

Perhaps the simplest UX change would be to alter the address-book dot from a two-state to a three-state field: "not in address book", "in address book", "in address book and has an encryption key". The third state could be denoted by a rosette.

(In reply to Arvidt from comment #204)

Alternative without "Warning": If encryption is not possible for all recipients, after clicking on send button open a rather neutral popup saying "Send mail unencrypted. <OK> / <Cancel>"

My understanding of advice from UI designers is, such prompts really need to be avoided, this idea is also an important part of our recent rework of the user interface.

Prompts in the middle are surprising, and it's far too easy to click the wrong button (muscle memory).

If sending to two recepients, and to one can be encrypted and to the other not, will in automatic mode the mail to the encrypt-possible recipient be encrypted but to the other recipient sent in plain text, or will be sent to both in plain text?

No, I'm convinced that a message must be sent consistently. Either encrypt to everyone, or not encrypt to anyone.

If a recipient receives an encrypted message, and the client shows that the message is encrypted, the recipient should be safely able to conclude that the message content traveled with encryption to everyone.

(In reply to andrewg from comment #205)

If there are many, the list can get long. We already have a way to communicate problematic recipients.

Yes, and these are great for must-encrypt mode, as they clearly indicate problems that must be addressed. But do you intend that these will also be used in opportunistic-encryption mode? If so, they seem visually too strong for what we're talking about here, as they imply an error rather than a warning. Or do you mean a similar kind of notification with different (less urgent) styling?

No. If encryption is optional, I do NOT want highlighting of missing-key-recipients, to avoid that the user perceives them as problematic/blocking. (They aren't in optional/automatic mode.)

If we want to remain consistent with the To: field notifications, maybe a better idea would be to highlight (subtly) which recipients can be encrypted to, rather than those which can't. This way, the user would still get visual feedback but in a much less intrusive manner. These could even be displayed regardless of the opportunistic-encryption setting (a gentle reminder of what is possible, rather than what is impossible).

(In reply to andrewg from comment #206)

• If encryption is possible but not required, then perhaps a subtle decoration (e.g. a lock badge) could be added to the name, similar to the address-book dot (and with a similar tooltip explanation).
  ...
  One big caveat is that putting a lock symbol of any kind in the To: field has a variety of possible (mis)interpretations. But relying solely on colours raises accessibility concerns.

As you say, there's the risk of misinterpretation. The user could falsely conclude that recipient-shown-with-lock means that the message WILL be encrypted to that recipient.

I think we shouldn't overload the UI. If the user wants that information, they can get it. FYI, I didn't mention this yet, but another way to get this information is by opening the "Key Assistant" from the OpenPGP/SMIME toolbar button, it will explain exactly what you have and what is missing.

• If encryption is possible and required, then should the default styling be used (since no action need be taken), or something distinct (as a visual confirmation)?

If all is good, the enabled encryption button seems sufficient feedback, there's no need to stress the user's attention further.

(In reply to andrewg from comment #207)

Also re styling, is it intentional that the "Encrypt" button in the compose window doesn't darken when selected, even though similar buttons elsewhere in the UI (e.g. "Quick Filter") do? I think if the "Encrypt" button darkened on selection then encryption mode changes would be much less likely to get overlooked.

For me, both buttons already darken in the same way when clicked/selected. If they aren't for you, please file a separate bug. (Let's try to keep this long bug focussed.)

(In reply to andrewg from comment #209)

Perhaps the simplest UX change would be to alter the address-book dot from a two-state to a three-state field: "not in address book", "in address book", "in address book and has an encryption key". The third state could be denoted by a rosette.

I've never noticed such a "dot" and cannot even find it now. I think such subtle notifications cannot be understood (or even noticed) without a clear explanation.

However, what I'm learning from your feedback, you really want some kind of feedback, that immediately answers the question "WHO are the recipients that caused automatic encryption to get disabled?".

The solution that would require the least amount of new work, and reuse as much of what we already have, would be like this:

"Automatic End-to-end encryption was disabled, because you cannot encrypt to at least one recipient. [Learn More...]"

If the user clicks the "Learn More" button, we bring up the "Key Assistant" popup (the same one that you can access at any time from the toolbar button). That dialog already explains it in detail, and provides assistance, if desired.

I've never noticed such a "dot" and cannot even find it now. I think such subtle notifications cannot be understood (or even noticed) without a clear explanation.

There is a tooltip that appears on mouse hover, but I agree this may not be sufficiently intuitive.

The solution that would require the least amount of new work, and reuse as much of what we already have, would be like this:
"Automatic End-to-end encryption was disabled, because you cannot encrypt to at least one recipient. [Learn More...]"
If the user clicks the "Learn More" button, we bring up the "Key Assistant" popup (the same one that you can access at any time from the toolbar button). That dialog already explains it in detail, and provides assistance, if desired.

This sounds perfect. As you say, it would be wise to keep the UX changes to a minimum; there is nothing fundamentally wrong with what is there now.

Thanks, and sorry for the flood of half-baked ideas... ;-)

We must make a decision for the following scenario.

Today, with manual encryption control, when replying to an encrypted message, we automatically enable encryption for the reply. (The idea is, because we're quoting the original message by default, sending a reply unencrypted would leak the original message.)

Today, if the reply cannot be sent encrypted, the user is forced to manually and deliberately disable encryption.

What should happen in automatic mode?
If we automatically disabled encryption because of a missing/unusable recipient key, we'd leak the original message automatically.

To find a decision, we should ask, what's the purpose of this automatic encryption mode?

In my opinion, the intention is to have an automatic upgrade to more security, if easily possible. But the mode shouldn't result in a downgrade of security for existing conversations.

In my opinion, even in automatic mode, we should require the user to manually disable encryption, when replying to an encrypted message.

My view is that the old behavior was for the knowledgeable people who really cared about encryption, who were willing to use Thunderbird for encrypted messages (manual mode)

The new automatic mode is for everyone else who did not use encryption because it was too much trouble.
Therefore the metric that we should judge the success is how many people use encryption not how safe the automatic mode is, if you want safe use manual mode.
The automatic mode should not require any manual disable encryption, since the goal is to get more people to use encryption.

The question we should ask ourselves is, does this automatic mode make emails more secure in total, for all Thunderbird users? Improving the experience for the tiny tiny group of people who used manual mode, is the thinking that made this bug be ignored for 20+ years.

(In reply to hagar2272 from comment #214)

The question we should ask ourselves is, does this automatic mode make emails more secure in total, for all Thunderbird users? Improving the experience for the tiny tiny group of people who used manual mode, is the thinking that made this bug be ignored for 20+ years.

No. Automatically disabling encryption without the user’s agreement is a bad idea, especially if you received the message encrypted. You take the responsibility of divulging it in spite of the sender putting trust in you. It can’t be the developer’s “fault”.

I totally agree with Kai’s experienced point of view: in case of an impossible automatic decision, the user should be the decision maker. Since the automatic mode is enabled, it’s not preposterous that the user knows encryption is still working and they can do something about improving the situation (like deciding to not send, but find the PGP key before another action or whatever they decide).

As with your home, no matter what kind of doors and keys you have, you still see your doors and windows; and sometimes there is something that makes that they don’t work properly.

I agree with maison completely - it's never right to auto disable encryption when it's expected. The user can easily disable it if need be...

(In reply to maison from comment #215)

It depends on what goals and assumptions you are making.
What percentage of users are using encryption is Thunderbird? I do not have the data but I think it is a tiny percentage (my assumption 1).

You are trying to avoid harm, minimizing unencrypted messages sent that were meant to be sent encrypted or not at all.
I try to maximize potential benefits, maximizing the number of messages that are sent encrypted (my goal 1)

The majority of Thunderbird's encryption thinking is following the minimizing harm strategy.
Remove all the encryption capabilities of Thunderbird and you will have zero harm described above.
Do you see the problem with only focusing on the minimizing harm strategy?

You need to balance both strategies. This bug has been open for 20 years because not enough people were using encryption for it to be a priority. Is that not a bigger problem than a few emails sent unencrypted by mistake?

(In reply to hagar2272 from comment #214)

Completely agree. This is a new perspective stated in RFC7435 (“Opportunistic Security: Some Protection Most of the Time”) (implemented e.g. by Autocrypt). Search also for "opportunistic" in this thread.

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

have an automatic upgrade to more security, if easily possible. But the mode shouldn't result in a downgrade of security

Well, could be that the sender encrypted automatically without the sender knowing anything about encryption (and therefore not as maison wrote, have "putting trust" in the receiver), which would be perfect automatic "encrypt when possible" security upgrade. When the receiver then cannot reply encrypted, than it's just back to the baseline (unencrypted) that would have been also when the automatic "upgrade" would not have taken place in the first step.

We should look at the whole conversation (message thread) as one. If the conversation is encrypted I think it's totally fine to require action to break out of that mode.

(In reply to hagar2272 from comment #217)

You are trying to avoid harm, minimizing unencrypted messages sent that were meant to be sent encrypted or not at all.
I try to maximize potential benefits, maximizing the number of messages that are sent encrypted (my goal 1)

You need to balance both strategies. This bug has been open for 20 years because not enough people were using encryption for it to be a priority. Is that not a bigger problem than a few emails sent unencrypted by mistake?

It might not be a problem in some cases, but in some cases it might be, you can only speculate. Downgrading security is not maximizing the benefits; say it to activists, journalists, doctors, people living in dictatorship.
Encryption is not about maximizing the user base in spite of them, it’s about keeping data safe when it is deemed so. Education is a side benefit rather than hiding control.

(In reply to Arvidt from comment #218)

Well, could be that the sender encrypted automatically without the sender knowing anything about encryption (and therefore not as maison wrote, have "putting trust" in the receiver), which would be perfect automatic "encrypt when possible" security upgrade. When the receiver then cannot reply encrypted, than it's just back to the baseline (unencrypted) that would have been also when the automatic "upgrade" would not have taken place in the first step.

This is pure speculation. You can’t assume that someone didn’t know what they were doing, unless you have proof to that and even that is a case by case. When you don’t know, you have to take the conservative hypothesis.
The baseline is how the conversation was previously, which might be encrypted or unencrypted.

I would like to clarify the scope of this bug. It is NOT about opportunistic encryption. The bug here is not about automatically trusting keys.

The enhancement proposed here still requires that the user has marked OpenPGP public keys as accepted. For OpenPGP, I define the feature request "encrypt when possible" as "it is already possible, because the user has already configured a recipient's public key: obtained and accepted".

This enhancement is strictly limited to automatically enabling or disabling the encryption flag for individual messages, depending on what's already possible based on existing configuration.

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

I would like to clarify the scope of this bug. It is NOT about opportunistic encryption. The bug here is not about automatically trusting keys.

Thank you for clarifying but I am still confused.
How can the user be unhappy with automatically not trusting a key that the user has not marked as accepted? The automation is consistent and does exactly what it is supposed to do automatically.
Why are you assuming that the user wants to encrypt if they did not mark accept the keys as accepted?

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

I would like to clarify the scope of this bug. It is NOT about opportunistic encryption.

Sure, not as a whole, the scope of this bug touches only a small part of the concept of opportunistic security.
And one part of the concept answers your concrete question, if it would be ok to reply in cleartext to a received encrypted message without bothering the user.
For RFC 7435 this would be perfectly ok, because "the default protection is no protection, and anything more than that is an improvement."

BTW I recommend to read Kai's very fine TB user group analysis on the mailing list where this bug was referred to as the implementation of a "relaxed mode".

(In reply to hagar2272 from comment #222)

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

I would like to clarify the scope of this bug. It is NOT about opportunistic encryption. The bug here is not about automatically trusting keys.

Thank you for clarifying but I am still confused.
How can the user be unhappy with automatically not trusting a key that the user has not marked as accepted? The automation is consistent and does exactly what it is supposed to do automatically.

I see the answer to your question is in the comment of Kai you partly cited: Automatic accepting keys is just not in scope. The problem of getting the needed keys (and accept them) is not addressed in this bug.

Why are you assuming that the user wants to encrypt if they did not mark accept the keys as accepted?

Kai wrote the opposite of your presumption:
(Kai Engert (:KaiE:) comment #221)

[...] The enhancement proposed here still requires that the user has marked OpenPGP public keys as accepted. [...]

Imho your questions are just not relevant in context of this bug. And solving this bug will not address them. The first one might be a topic for another bug. (if not already existing)

I would advocate for enabled encryption and ask if it is not possible, if the user replies to an encrypted message.

In my opinion it is a narrow case. So the number of mails where the user has to take manual action is quite limited.
And for one sub-case (Key exchange, where the user hasn't imported the key of the sender of the answered message/ recipient) it even would be a good reminder to import and accept the key. (if there is no automatic import& acceptance)

If encryption get's disabled I see the already stated problem: The content of the encrypted message is leaked and I think it's a good idea to avoid this. - This sounds like a downgrade for me, too.

To keep encryption enabled also ensures consistent behavior: In manual mode encryption would be active (btw: automatic!).

(In reply to Arvidt from comment #218)

[...] Well, could be that the sender encrypted automatically without the sender knowing anything about encryption [...]

I see absolutely no evidence to assume, that the sender doesn't know anything about encryption.
Imho it's not feasible to make any assumptions about the knowledge of the sender. What we know is: The sender has the key of the user and he used it to encrypt the message. He is capable of dealing with encrypted messages and he decided (maybe manual, maybe by configuring his MUA to send encrypted, maybe automatic if possible :-) ) to send the message encrypted.
So the sender prefers encrypted messages, at least in this conversation. - If the user/ the MUA should divert from this decision, it should be done by explicit choice of the user.

(In reply to hagar2272 from comment #222)

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

I would like to clarify the scope of this bug. It is NOT about opportunistic encryption. The bug here is not about automatically trusting keys.

Ignore my message 222, I missread KaiE 221, sorry for any confusion it causes.

My goal is not to design this small automatic vs manual action, but to change the mindset of how Thunderbird think about encryption and security.
Convenience vs sececurity conviniece will win.
I would like more emails to be encrypted so people who use encryption do not stick out as a sore thumb.
I want a world where all non-encrypted emails are viewed as spam, it would be a better world.

In my opinion, even in automatic mode, we should require the user to manually disable encryption, when replying to an encrypted message.

This is the only correct approach. Consider the following scenario:

Alice sends an encrypted message to Bob. Mallory cannot read or modify the encrypted message body in transit, but may be able to modify the headers. If Mallory were to (say) add a Reply-to: header so that replies were directed to an address visually similar to Alice’s, Bob may inadvertently reply to that address instead, and is likely to quote-include Alice’s original plaintext. Silently disabling encryption for yhe reply enables a downgrade attack on Alice’s original message, regardless of Alice’s encryption preferences.

There are ways to mitigate this attack (signed headers etc) but there are no circumstances in which silent downgrades in the middle of conversation threads are desitable, so they should be made impossible in principle.

The same considerations also apply to forwarded messages, so the same downgrade protections should be enforced there also.

Off-topic but an honest question to all in this thread, trying to understand where people are coming from.

How many of you regularly send or receive encrypted emails in Thunderbird? If so how are you handling reading the email on your phone?

I know there are secure email phone apps but I am too lazy to set up and maintain all of that, since I basically get zero encrypted emails.
I use point-to-point apps like Signal if I want to communicate securely.

hagar2272, this bug is already very long and complicated to follow, and for anyone who wants to join the discussion, it's already hard to jump in. Please move side questions to the e2e mailing list:
https://thunderbird.topicbox.com/groups/e2ee

The discussion in this bug should focus on the described enhancement, on the decisions we need to make, and the directly related arguments.
Thank you

Sadly, this issue is blocking me from implementing encryption in our company for internal mails. Either our employees have to explicitly enable encryption for all internal mails or they have to explicitly disable encryption for all external mails. This is neither accepted nor practical.

If you are interested to test an experimental implementation and give feedback, please see bug 1795981.
For that experiment, please ONLY comment in bug 1795981.

Once the experiment is completed, I will provide a summary of the results here.

I'm doing this separation to keep this long ticket here as short as possible.

I'm surprised nobody has yet given feedback for the experimental implementation in bug 1795981.
I'd strongly encourage everyone waiting for this addition to give feedback in bug 1795981, to let us know if this seems useful.

While we're waiting for test feedback, let me continue here with more general comments.

I would like to update the bug subject to make it more obvious that this ticket is NOT about opportunistic encryption.
It's more about "automation".
IFF, the user has already configured Thunderbird to be ready for using e2ee, and IFF the user has already obtained and accepted keys/certificates for all recipients of a specific email the user is composing, then enable encryption automatically for that email.

Once we have that "automation" ability, we need to offer the ability to the user.

Currently, the initial experimental implementation in bug 1795981 offers that through hidden preferences, only.

One option is to start with this limitation. Only offer it through hidden prefs, and allow interested parties (like you) to start experimenting with it, and identify bugs.

In a second step, we could eventually offer discoverable preferences in the standard Thunderbird settings.

An important question for that is:
Is it sufficient to have those prefs global, once, covering all accounts?
Or, is it desirable to offer those prefs per account?

In other words - do you think users might want this automation for their first email account, but not for their second email account?

(And we'd need to make a decision. If we think that some users need different configuration per account, and we want to offer that flexibility, then it would be a per-account configuration for everyone.)

In a third step, we could consider to advertise this "automation" ability to the user, and make it easy to enable it.

For example, we have recently introduced reminder notifications, that can remind the user that encryption is possible.
Potentially, we could improve those notifications. A notification "encryption is possible" currently offers to "enable encryption".
We could add another button saying "automatically enable encryption if it's possible", which turns on the pref.

Likewise, currently we have a notification if encryption is already enabled, but NOT possible. (This currently offers the choices "disable encryption" and "resolve" for OpenPGP, only.)
In this prompt, we could offer another choice "automatically disable encryption if it isn't possible".

As explained further above, the current suggestion is, whenever we automatically disable encryption (after it was already enabled), we inform the user - in the initial experiment implemented using a prompt. This prompt could offer a checkbox for the third pref "never notify me when encryption is automatically disabled".

If we decided to have those interactive ways to enable the prefs, here's a worry: If we make those prefs per-account, then users might be confused why in emails for another account those actions are not happening automatically.

To avoid this potential confusion we could make the prefs global (same automation configuration for all email accounts).

I would like to limit this bug to the "first step" that I described above, and start with hidden prefs for the initial implementation.

I would like to file follow-up bugs for step 2 (user visible configuration) and step 3 (interactively assist the user to enable encryption automation).

After, or in parallel to steps 2 and 3, we could also discuss if it makes sense to change the defaults (e.g. use the automation to enable encryption by default).

I'll file yet another bug to track the default decision.

So, we're still at step 1. Please comment in this bug if you have general comments on step 1 - or - comment in bug 1795981 if you're willing to participate in testing the initial implementation attempt for step 1.

I'll shortly file the other bugs. If you have comments on step 2, step 3 or the default, please make them in the new bugs that I'll announce in the next comment.

Depends on D151915

Depends on D160133

Comment on attachment 9278126 [details]
Bug 135636 - Add a few strings that we could potentially use later. r=aleca

Revision D147287 was moved to bug 1796631. Setting attachment 9278126 [details] to obsolete.