Open Bug 135636 Opened 19 years ago Updated 13 days ago

Implement "Encryption when possible" option for OpenPGP and S/MIME

Categories

(MailNews Core :: Security: S/MIME, enhancement, P2)

Product:
MailNews Core
Component:
Security: S/MIME
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: 2009-bugzilla, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [kerh-eha] [GS])

Attachments

(4 files)

Account Manager Screenshot
16.24 KB, image/png
Details
screen shot of composition window status bar S/MIME icons
6.93 KB, image/gif
Details
encrypted and signed
38.65 KB, image/png
Details
compose signed only
37.72 KB, image/png
Details 
Right now I only have two options is MailNews Account Manager / Security /
Encryption :
 o Never encrypt messages
 o Require message encryption

As far as I can remember, Netscape 4.x offered "Encrypt by default" - which
allowed you to send mail to users who don't have S/MIME-keys after dismissing an
alert. In Mozilla you currently have to select "Never Encrypt" in the
preferences and disable encryption every time you want to send a mail manually
(and hopefully don't forget to enable) - or select "Require Encryption" which
requires you to manually disable (after an alert) encryption to send a mail.

I think there should be a third option "Encrypt when possible", which does not
require the user to enable and disable encryption manually.

I don't know to what extend the backend is capable of doing so, and didn't find
a duplicate bug. Since I don't think of this as an enhancement, severity has
been set to normal.
QA Contact: nbaca → junruh

*** This bug has been marked as a duplicate of 117763 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Verified. Actually a dupe of bug 129100
Status: RESOLVED → VERIFIED
It seems like there are preparations for this, but no implementation yet. And no
bug dealing with this issue specifically.

http://bugzilla.mozilla.org/show_bug.cgi?id=117763#c10 :
------- Kai Engert 2002-04-23 12:54 -------
> Kai, is there an open bug for the 'if possible' option now ?
Not sure, if you can't find one under PSM/S/Mime, feel free to file one, but
please mark it as "request for enhancement".
Severity: normal → enhancement
Status: VERIFIED → REOPENED
Component: Account Manager → S/MIME
Product: MailNews → PSM
Hardware: PC → All
Resolution: DUPLICATE → ---
Summary: Need "Encryption when possible" option → Implement "Encryption when possible" option
Version: other → unspecified
Reassigning and adding Kai
Assignee: racham → ssaux
Status: REOPENED → NEW
QA Contact: junruh → carosendahl
Keywords: regression
Summary: Implement "Encryption when possible" option → [UE] Implement "Encryption when possible" option
Blocks: 74157
I'd like to add that I think this would be a great feature.  For me, it makes
the security/crypto stuff almost unusable...
Altering - actually not an enhancement, but a regression from NS4.79
Severity: enhancement → normal
Priority: -- → P3
Version: unspecified → 2.3
I was asking Charles privately why he thinks it is a regression. He pointed me
to the wording in Communicator, which indeed says "encrypt if possible" in the
default configuration.

However, the option in an individual message is simply called "encrypt".

I don't want to start a discussion on whether it is indeed a regression or not,
but note the following:

Communicator *only* had the "if possible" default option.
If encryption is not possible, it *always* bothers the user with an allowance
question.

Mozilla currently has a require option.

What we want for the "Mozilla when possible" behaviour is:
- if possible, send encrypted
- do never show a warning, just send in the plain, if encryption is not possible.

It was said, the warning is bothering and should be avoid.
If a user is picky about using encryption, he would configure the application to
require encryption.
"When possible" is for users who don't care.

In that sense, because the plan is that Mozilla will use a completely different
behaviour than Communicator, in my opinion this is not a regression.

Not to task the devs too much on this; getting the above described behavior
would be excellent, but I think if its convenient while you are futzing with it,
there should be an option for warning that you are sending without encryption,
similar to the way it works for web services.  The warning can be disabled or not.  

If this is a major pain in the butt, forget about it, but I think it would make
sense to do this, because its the same behaviour/UI seen on the browser side.
I think we are making progress.  The way that I see it, (in my current role as
user champion :)

Under Configurable persistent preferences, there are two primary areas:
1.  Mail
2.  News

Under News Accounts (tbd), we have:
1.  Sign news messages by default - Boolean.  Either you do or you don't.

2.  Encryption is not an option and is therefore ommitted from news account
settings.

Under Mail, we have:
1.  Sign mail by default - Boolean.  Either you do or you don't.

2.  Encryption - Tertiary.  Never, When Possible, and Required.

2a. Never: This is the default.  Users who don't care leave it as is.

2b. When Possible:  This option attempts to encrypt to all recipients in the
list, but should it find one or more without certificates, a prompt will notify
the user that the message cannot be sent encrypted.  The user has the option of
sending it unencrypted, or cancelling out to correct the situation. 
Additionally, a 'don't show me this warning anymore' checkbox exists to turn off
the warning should the user choose to send unencrypted anyway.

the warning may be toggled from the preferences panel that contains all of the
other warnings related to SSL, etc., etc. if the user wishes to see it again.

2c.  Required: This option requires that all recipients have a certificate
available for sending to succeed.  Should a recipient cert be unavailable for
one or more recipients, an error message (a la 4.79) indicates to the user that
they should check the security info to find out which users are missing certs. 
In the info panel (a la 4.79) the sender may then mulitple select any or all
users missing certs and attempt to retrieve them from one or more directory
services.  After obtaining as many certs as possible, the sender may then omit
the other recipients and continue to encrypt the message.

====
Both options 2b and 2c turn encryption on by default.  The only difference
between 2b and 2c is the fact that the user can continue to send unencrypted
and/or turn off the warning in the process.  In both 2b and 2c the user can
cancel out and go to the security info box to retrieve as many certificates as
possible if encryption is really desired.

FYI - Current code does not yet support cert retrieval from external services or
signed news messages yet.

By and large, this is a correct view of OE's and 4.79's current behavior.  It is
this behavior that existing users will expect, and new users will appreciate.
Actually the design for when possible is not what you described.

The design is detailed in http://www.mozilla.org/mailnews/specs/security/

and calls for the Send button and the Security Icon to display whether the mail
can be encrypted when the "If possible" option is chosen. If it's not possible,
the send icon shows a broken lock, and the security Icon shows a torn
certificate. The use can send without a warning, it's just sent non-encrypted.
Because the send button gives plenty of feedback it was deemed acceptable.

The if possible then has the following semantics:
If you can send encrypted send it. I don't generally write security sensitive
stuff, but if possible encrypt anyway.
If I'm sure that I want to encrypt, I'll change the setting for that message
only using the security button.


And I agree with Kai that this is not a regression. The S/mime model is
significantly different in both clients that it's not meaningfull, in this case,
to talk about regression.

I'll add to that we can't add the if possible option until we have made a
commitment to implement the full UI spec.

I agree that we need to implement the UI as suggested before we can implement
this feature.

However, note that this makes things more complicated.

In order to show at any time the correct state in the UI, this means, we need to
know at any time whether sending encrypted will be possible or not.

That means, whenever the list of recipients changes, we automatically must
check, obtain and verify the required certificates.

I already had discussions with people from the mail/news team. It will be
somewhat tricky to implement, because the current mailnews UI is not prepared to
help us here. The list of recipients is currently only gathered on demand, so
our change will need a partial rework of the mail composer window code.

This may not be a code regression, but it is a usability/feature regression. 
The feature is in 4.79, regardless of the model being used.  The feature, while
spec'd, is not in machV.

As to the spec, all is well and good.  Where is the harm in issuing a warning
that users can turn on and off?  It appears to be the convention, particularly
when security is involved? 

It is better to err on the side of usability and conveying more information than
not.  The current implementation is not user friendly.  I'm serious - most users
are not tech weenies and will not like the behavior - they just want something
that works in a common sensical fashion.

The idea here is to deliver functionality that generates a customer
satisfaction, is it not? 
I just think we need to address this by RTM.  Removed regression keyword.  The
UI in the spec, if we could implement it by RTM, would be great - there is ample
visual feedback.

Still think we ought to have the 'one time warning' dialog though...just like
when you enter a secure site, leave a secure site, send form data, etc...
Keywords: regression
Target Milestone: --- → Future
Severity: normal → enhancement
this is a show stopper for deploying mozilla to my approx 150 users.  They use
encryption and would not stand for the current Mozilla arrangement.  They are
very satisfied with the options in Netscape 4.x.
*** Bug 176205 has been marked as a duplicate of this bug. ***
Is there any activity on this usability bug?  There appears to be paralysis (http://bugzilla.mozilla.org/show_bug.cgi?id=149876) over semantic defintions in the design spec.

I want to deploy Mozilla to replace Netscape 4.8, BUT the users need better support for dealing with recipients who do not have encryption certificates (x.509 certs)-- at least the same flexibility as in NS4.x.

And I'm willing to throw $200 at the problem, if only to get a resolution.  If it's never going to happen (for whatever reason) then I need to know so I can find another solution.  But for most of my clients that solution requires x.509 certs in Windows, and my options are extremely limited, hence the offer of money.

It's not hard to see that different security stances at different organizations would require a whole range of options, which can't be met by limiting the choice to two (require or not, or just replacing what was available in NS4.x
Is this feature dead?  I have been hoping that this feature would come back (It
was implemented at one point) .. 

The logic should be simple to implement .. if there certificate is available,
ecrypt .. if not, dont encrypt .. 
*** Bug 195940 has been marked as a duplicate of this bug. ***
*** Bug 219033 has been marked as a duplicate of this bug. ***
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
How much will it take to get this implemented?  I would contribute...
This bug needs a UI proposal and a patch to implement the UI proposal.  I can't
estimate how long it would take someone else to do the work.

I am willing to give an interim review to an API and of course will review any
proposed patch.

This is what I see needing changed:

Mail & Newsgroups Account Settings/Security
  Encryption
    Add "When possible/warn (encrypt if all recipients have certificates,    
      warn if not)" to "Default encryption" radio buttons
    Add "When possible/nowarn (encrypt if all recipients have certificates, 
      no warning if not)" to "Default encryption" radio buttons
      
Compose/Send
  Implement additional encryption modes

It sounds like implementing a dynamic Send button would be problematic, though
it would be nice to have the feedback, but I don't want to rely on only that. 
Once a user is used to where things are, they tend not to look too carefully at
the buttons.

I've never done any coding on Mozilla, and very little GUI programming, but this
doesn't sound too terribly difficult if the existing code is well organized.
well... first unaddressed concerns:

1. Suppose i have one mail account and 2 identities.
Q. How does that affect this stuff?

second... confusing questions:
1. Do I need a personal certificate to encrypt mail to other people? None of the
docs seem to give any reason that I'd need this, but the current ui sure forces
me to have one.
2. Is it really true that you can't sign nntp posts?
About Digital Signatures & Encryption
<chrome://help/locale/mail_sec_help.html#about_sigs_encrypt>
says "Signing and encryption are not available for newsgroup messages."

I thought I'd seen signed nntp messages, and I can't see any reason why I
shouldn't be able to sign an nntp message, or why I shouldn't be able to include
my public key in nntp messages.

finally... UI Proposal:
edit>mail and news account settings>[account]>security
Encryption
Default encryption setting when composing messages from this account:
( ) Do not encrypt messages
( ) Encrypt messages when all recipients have certificates
( ) Require all recipients to have certificates to send mail

Certificate to include in messages sent by you so people can send encrypted
messages to you:
[None                                            |v] [ View ]
|timeless@bemail.org - timeless authority          |

The preceding seems good enough for my purposes. (The view button would be
entirely optional, is not required imo, and the title is subject to
negotiation). I'm not very fond of the two buttons, but if people insist on
buttons, then I'd request:
[                                                  ] [ Choose...] [ None ]

If I really need info about the certificate, I could open the manager.... As for
the choice of "choose" over "select", well, the rest of account settings use it.
As for changing clear to 'none', um... I just don't see a point in a clear
button that does what this one does. Normally clear is a really destructive
thing, ala clear cache. While i'm specing, the select buttons shouldn't be
enabled if you don't have any certificates. Note that this problem goes away if
you replace the control with a listbox, since it would just have a single item
"None".

message composition (encrypted) [certificates are available for all recipients
and the mode is require or when possible]
the send/send later items should change to indicate that (some sort of
image/overlay could work).  One approach would be to change the default icon to
look more like a postcard.

message composition (require certificates)
send/send later items are disabled on the fly when a user is added to the
to/cc/bcc list and there is no certificate for that addressee in the certificate
manager. bonus points could be awarded at a later date for making the address
icons of encryptable and unencryptable addressees visually distinct.

If mail doesn't have hooks which let the security system find out about
recipients being added/removed from the address list, that can be fixed.
How can you have one mail account and two identities?  Your identity *is* your
mail account.

I can't think of a technical reason for requiring a cert to encrypt to other
people, the only reason you would want to do so would be to send anonymous
encrypted mail.  There are obvious cases where you might want to do that, so you
can turn off signing, though one would want to double check that it doesn't send
your cert along to identify you anyhow, even if it doesn't sign it.  It might
very well do that because you would expect that if you send encrypted mail to
someone, you would want an encrypted reply.

I agree that signing news posts should be an option, though it's not my main
concern.
@see bug 226580
Mass change "Future" target milestone to "--" on bugs that now are assigned to
nobody.  Those targets reflected the prioritization of past PSM management.
Many of these should be marked invalid or wontfix, I think.
Target Milestone: Future → ---
My users that used to use encryption quite regularly with the Netscape 4.x
"encrypt if possible" model have pretty much stopped using SMIME encryption with
Mozilla.  The remaining users make a point of periodically asking me when this
"great" mail client will be fixed to work as well as the old one.
*** Bug 251179 has been marked as a duplicate of this bug. ***
OK -- it's now reached the point of being an actual irritant to my users. 
here's the latest one --  Just the latest of 23 at this firm.

Mozilla has rendered PKI (x.509) encryption unusable for non-propellerheads.

PLEASE, PLEASE, PLEASE, re-implement the netscape 4.x pardign of "encrypt if
possible".

-------- Original Message --------
Subject: 	encryption
Date: 	Thu, 26 Aug 2004 11:28:50 -0700
From: 	Irene Faulkner <XXXXX>
Organization: 	Arvay Finlay, Barristers
To: 	Derek Shaw <spam at bisi.ca>

...is driving us all crazy.  please tell me how i disable my certificate so that
i don't have to manually go in and unencrypt every time i send an email.
thanks

-- 
Irene C. Faulkner
ARVAY FINLAY, Barristers
400 - 888 Fort Street Victoria, B.C.  V8W 1H8
Product: PSM → Core
Is this bug/feature request also valid for thunderbird? 
is there an timeline for implementation?
Is here someone who can give some feedback about implementation of this feature?
What's about implementing it in TB?
Do we have to donate to speed-up this? Just Say!
For Thunderbird, what are the problems that are keeping this bug from being fixed?  All I want is an "Encrypt if possible" option in the Security settings for each account.  So when the user clicks the Send button, Thunderbird would check the certificates it has and encrypt to only those email addresses.  Any remaining email addresses would not be encrypted.  The user would also not receive any warnings, etc.
I think the holdup is that no one is even looking at it.  The bug is assigned to "nobody", so my guess is that no Thunderbird developer is even involved.

Some developer is just going to have to sit down and take a look at it.  I'm a developer, but I have no familiarity with the Thunderbird code, so I can't do that work.  However, my instinct tells me that this is a medium-difficulty feature to implement.  An experienced Thunderbird developer could probably do it within a week, working full-time.

(On a side note, I don't use Thunderbird.  I want to see this feature in SeaMonkey).
Whiteboard: [kerh-eha]
Should the product be changed from CORE to THUNDERBIRD?  I would really like to see some headway on this one!
target: future
Target Milestone: --- → Future
QA Contact: carosendahl → s.mime
Does anyone not realize the importance of this functionality?  If Thunderbird is to be a viable alternative to Outlook, it needs to support an "If Possible" encryption option.  The "Required" encryption option really serves no purpose at the current time; once the majority of e-mail users have certificates, then this option will become important.
Johnathan, do you want to take a crack at this UI problem?
This is a feature that would get me to upgrade to Tbird 2...  There also needs to be some interaction with Enigmail: right now, I default to S/MIME signing my mail, bbut have enigmail rules set to encrypt/sign with pgp for a couple people who use PGP instead.  The S/MIME rule overrides Enigmail however, so if I forget to turn off the S/MIME signing, the message goes out unencrypted.  There needs to be a priority scheme:

1.  If you have one key, encrypt/sign using it
2.  If you have multiple keys, use priority order, or per-recipient rule, or ask

I'm sure that's a lot more complex, for starters the simple "encrypt if possible" is key, and it would be *really* nice to have at least a simple minded interaction between the two systems to use the appropriate system depending on what key you have.
This feature can make encryption usable in practice in the first place, but can also be very dangerous for security.
(I disagree with kaie in comment 8 - it is not for users who don't care about encryption, that's an extremely bad assumption.)

Following case: I discuss sensitive matters (either private or business) with somebody, and I know we're both using encryption and signing and I once checked that it works. I rely on it with what I say - I say sensitive I wouldn't say over plaintext mail, they may eve be dangerous.

Now, an attacker writes me a mail from a different email address which looks like from my friend (e.g. he uses David Guetta <david.guetta@yahoo.com> and the attacker uses David Guetta <david.a.guetta@yahoo.com> or David A. Guetta <david.a.guetta@yahoo.com>). *If* I have the Thunderbird feature on to hide email addresses in my address book (default, I think), the new email address would be shown which it would usually not. But it does not look strange or alarming. If that Thunderbird feature is not enabled, I'm even less likely to notice the change. So, in effect, I may or may not notice the email address change.

But for Thunderbird, it's a completely different correspondent, and if "Encrypt if possible" is selected, the mails which are usually encrypted are not longer, and secret data is leaked. Attack successful. It's a social engineering attack, but it enabled by this feature. Like all social engineering, it can be prevented by an alert user, but he has to check the email address every time, and that's not likely.

So, the UI for this needs to be very carefully designed. I agree that overzealous warning is not good, but just sending plaintext in a situation like above is not acceptable either.
Perhaps this can be done by using graphical clues throughout the experience that the conversation is encrypted/unencrypted, buttons, message background, etc.  I'm thinking the encrypted emails have an ever-so-slightly pink or some kind of stippled background, and the buttons are similarly identified to indicate encryption or not.

Just brainstorming ideas..
> Perhaps this can be done by using graphical clues throughout the experience

Good idea. I think the meaning of color is not obvious enough, so alone won't suffice. But a lock icon on the send button - would match the browser with http.
(In reply to comment #43)
> Perhaps this can be done by using graphical clues throughout the experience

Yeah, I like that idea, too.  A lock icon on the Send button might break some Themes, so if it does, then perhaps a status icon on the bottom of the window would easier.

BTW, this is labeled as a Core bug, so it should apply to Thunderbird *and* Seamonkey.  (I'm opposed to changing it to just "Thunderbird" because I use Seamonkey)  But now we're talking about UI changes.  The Thunderbird and Seamonkey UIs are different, so does this mean that this feature will have to be implemented separately on Thunderbird and Seamonkey?

One option is to get something working with basic functionality, allowing this bug to be closed, and then coming up with a plan for further enhancements in the UI.
One thing I think would be required is a warning to the user if the message is sent encrypted to some recipients and unencrypted to others.  This would probably catch a lot of problems, if the users could be educated to pay attention to it.

The lack of this feature is what is preventing us from implementing Thunderbird S/MIME encryption,  Users who care about encryption have started doing guerrilla installs of Enigmail with their own GPG keys.
(In reply to comment #47)
> One thing I think would be required is a warning to the user if the message is
> sent encrypted to some recipients and unencrypted to others. 

I think that's beyond the scope of this feature.  The simple solution is to use encryption only if it can be encrypted for ALL recipients.  Like Steve Hay suggested, as long as it's visually obvious what's going to happen before the user presses 'send', then it should be okay.

As the saying goes, don't let the perfect be the enemy of the good.
(In reply to comment #48)
> The simple solution is to use encryption only if it can be encrypted 
> for ALL recipients.   Like Steve Hay  suggested, as long as it's visually 
> obvious what's  going to happen before the user presses 'send', then it 
> should be okay.

I would be very happy with that or, indeed, any way of using encryption that did not require the user to manually check or uncheck the encryption option for each message.
(In reply to comment #40)
> Johnathan, do you want to take a crack at this UI problem?

You know I love cracking at UI problems, but just at the moment, I have too much Firefox stuff going on to add this to the queue -- which is not to say that I don't consider it important, on the contrary.  I wish bugzilla had a "remind me in 3 months" flag.

Obviously, my lack of time shouldn't slow anyone else down.  I doubt that even needs mentioning, but I wouldn't want to be interpreted as saying "this should block until security UI resources are available" since... blah.  You all know that's not what I'm saying.  :)
> I wish bugzilla had a "remind me in 3 months" flag.

Slightly manual, but...

prep-A) go to the "General Preferences" tab in Bugzilla preferences
prep-B) Turn "Enable tags for bugs" to On

1) In the footer for the remindee bug add a "named tag", something like "Nov2007" maybe.
2) in November click on the "Nov2007" saved query in the bugzilla footer and look at all the bugs you added to that tag.
3) when you're done with that tag forever you can "forget" the query, or remove individual bugs from it using the Bugzilla footer as you deal with them.
Version: psm2.3 → 1.0 Branch
johnath, dveditz you should both be in the bz_canusewhines group, which means you have use: https://bugzilla.mozilla.org/editwhines.cgi

to setup scheduled whines. currently it only allows for monthly. but i think be able to ask for quarterly whines shouldn't be an unreasonable request - bug 445126.
Product: Core → MailNews Core
Having to manually select "Do not encrypt this message" when sending to non-certificated recipients is a complete pain. Every day I have do this many times. Setting encryption "Required" is the only sensible option if you use encryption otherwise you might forget to manually set encrypt for certificated recipients.

One of the objectives of software is to make things easy for the user.

Why not just copy the Outlook system which doesn't have this restriction.

A friend of mine prefers Outlook over Thunderbird for this reason and he's got a point.
Wasting your breath John, I've been telling them that for YEARS.  The problem is that they seem to be hung up on an option ("Required") that no one cares about or has even asked for.  Outlook has no such "required" option and users like myself are happy to use it every day.  If my recipient has a certificate, then the message is encrypted "automagically"; if not, then the message is not encrypted.  If users had wanted something more, they would have complained to Microsoft about it.

Please, please, please stop being hung up on how you think this should work.  Outlook has this capability, so let's get it into Thunderbird so we can get more people using it!  The endless debate on this issue has got to stop, please.  Let's get some action going on this and get it done, finally.
It's appalling how long this has gone on: architecturally, it's just not that hard:

For starters:
  Settings:
    Option to encrypt with s/mime if possible

  Compose:
    When you enter an address, look for cert
      if found, green
      else red
      (theming this can wait if need be)
    If not all addresses can be encrypted
      encryption icon broken
      entire address pane pink
        (theming this can wait if need be)
      future option: insert X-Encrypted-To header for addresses able to be encrypted (maybe only in saved copy?  don't hold up over this)

  Send
    for each address with key
      encrypt, send
    send unencrypted to remainder
    if saving a local copy
      if all addresses can be encrypted
        encrypt to self
      save

Ideal future operation:
  Settings:
    If multiple keystores registered (e.g. enigmail says "I have a pgp keystore")
      option to set global priority
      address book has option to set priority by address
      initially: checkbox "try this first" (virtually 100% will have at most two: s/mime, pgp)
      later: numeric order to support N keystores

  Compose:
    As above, selecting from keystores per priority
      if addressbook priority use that
      else global
    Implementation detail: might attach key at this point to avoid bugs where
    compose does one thing and send another, but choice shouldn't be a show stopper

  Send:
    As above, selecting from keystores per priority
      if addressbook priority use that
      else global
Bryan ^^^^
Priority: P3 → --
Target Milestone: Future → ---
Version: 1.0 Branch → Trunk
I like the idea of changing the message appearance based on the encryption state.  Though I think the sole use of colors for this indication will be problematic.

* We already use red to indicate a bad address so we can't double up on bad address / unencrypted
* Themes, Color Blindness, and a11y make using only color as a designator an artful dance

That doesn't mean that we can't use color in conjunction with some other indicators; just that we can rely on color as our main indicator.

There are two possible behavior types that I'm seeing in this bug.

1. All or nothing, "secure if possible".  This means that if all recipients have a cert than we alter the message composer to indicate that this message is secure.  Likely security concerned users could not use this option, though people who were explicitly trying to have secure communications and regular (insecure) communications would benefit from the ability to auto-encrypt when possible and otherwise still send mail.

For this I think we want our encryption status to be related to the entire email itself and not just the recipients.  Though I like indicating which recipients don't have a cert; perhaps we can do that with an alternate icon.  We have a little person icon for each contact right now and it seems reasonable to me that we have a "cert person" icon for each person that has a cert.

I might do something like take the from area and add an encryption status widget with an icon and label.  Also coloring encrypted status background in a green to indicate the message is secure.

From: [ Bryan Clark <clarkbw@example.com> | v ] {Encrypted Status}

2. I'm calling this option 'casual security'.  This means that if we have certs for some contacts then we send secured, otherwise we sent plain.  This is casual because the security isn't requisite as much as it's a opt-in choice.  Security concerned users of Thunderbird could not use this option as there are no guarantees of security on a bad day.  All the indicators would have to be inline as we all know and agree that nagging dialogs do nothing over the long term.

I don't think we have a good way to convey to the user that the encrypted email they intended to send was sent unencrypted to a few people.  Some users would understand this, but others might not.  Different icons or colors might indicate that, however I don't think those indicators are strong enough to sleep well at night.

To make this option work I've tried changing the listcell.addressingWidgetCell widgets.  It's possible to make each address line show a background color that could indicate secure (white = normal, green = secure) as well as an icon that we use in the background aligned right.

(sm)+secure@example.com++++++++++++++++++++++++(l)
(m)  insecure@example.com

+++  == "green background-color"
(sm) == "cert contact icon"
(m)  == "contact icon"
(l)  == "secure/lock icon"

This doesn't have any real text indications of security so it's not ready for prime time but it tries to clearly convey that some people are more secure than others.

--

Given the choice of taking "secure if possible" or "casual security" into the trunk I would probably have to choose "secure if possible" as a possible trunk item and "casual security" as an add-on available from AMO.  People using Thunderbird who are really worried about security should lockout the AMO add-ons site anyway so I have less concern that an extension poses a threat to our general user base as having something built in.

So far that's all my thoughts on this.  The add-ons route is much nicer in TB3 than any other version of Thunderbird previous and we're working pretty hard to keep making it better.  I didn't go into further interactions yet because it seemed unclear what the best behavior is and I wanted to get some ideas out before moving forward on them.
People who *need* security would use the "encrypt always" option, though it ought to be on a per-address basis to match the real world security requirements.  Actually, that would be another option for satisfying this: for the people I have keys for, I could set "encrypt always to this person" and leave the default at unencrypted.  I still want to see an obvious visual indicator however (i.e. green background on the address)...
(In reply to comment #58)
> I still want to see an obvious visual
> indicator however (i.e. green background on the address)...

Why not simply use the lock-icon that people are used to from browsers?

Open Lock == Not Encrypted
Closed Lock == Encrypted
"Gray" Open Lock == Not Encrypted, no key for address
As long as it's next to the address and not buried down in the corner where you don't notice it, as it is in browsers.  The modern enhancement of coloring the url on secure sites is much more obvious and usable.  Color is also simpler to process --- a lock image essentially requires parsing the image (i.e. determine if it's open or closed, which requires some analysis).  If it's simpler, coloring the lock would be better than nothing.  But it needs to be something that stands out, as, for example, when you click on reply, you (or at least *I* ;-) ) rarely even look at the address section --- it needs to be something you pickup peripherally to give you at least the chance of tripping an alarm "hey, I'm replying to Joe, why isn't that Green?"

On the other hand, that's just confirmation and redundancy.  Security comes from the ability to say "always encrypt to this address" in the first place, but nothing can prevent me from making the mistake of sending confidential information to the wrong address; this only gives me an improved chance of noticing that I'm doing it...
I think that the "all or nothing" behavior is what I would personally expect.  If I'm sending to multiple people, I really don't expect the message to be encrypted -- not even to the one recipient that might be able to receive the message encrypted.

Would I like some visuals to let me know the message is going out encrypted?  Absolutely!  There is nothing better than having visual reassurance that the message can and will be encrypted.  Outlook has nothing like this at all.  It would also be good if the recipient received some visual indicators as well.

I would, however, like to receive an alert if a recipient that I always encrypt to suddenly has a problem due to an expired or revoked certificate, and the message could not be encrypted for that reason, or any other failure that might prevent the message from being encrypted when it would normally have been encrypted.
Hi, I'm a co-owner of the NSS module (Mozilla's crypto libraries), and have 
worked on the CMS crypto code that is used in Thunderbird S/MIME since before 
there was Thunderbird. I am now the nominal maintainer of that CMS crypto code.

I'd like to "weigh in" here on the subject of "casual encryption" by which 
term (AIUI) Brian Clark seems to mean that a single message may be sent twice, 
once encrypted to those who can receive it that way, and once unencrypted to 
those who cannot.  I *strongly oppose* that.  

Sending a message both encrypted and unencrypted defeats the purpose of 
encryption.  It defeats any secrecy. It _ensures_ that an attacker who is 
"snooping" on your traffic will be able to read those messages.  

A user may send a message, thinking that he has preserved secrecy, because 
it was sent encrypted to at least some of the recipients.  But when the text
of his message appears in the paper, or in a court document, he discovers 
that it was NOT kept secret, and he declares to the world that Thunderbird's
encrypted email is useless because it does not protect secrecy.  

I believe I am speaking for the NSS team when I say that, to preserve the 
reputation of Thunrderbird's S/MIME (and indeed, of S/MIME in general) we 
want to prevent such mistakes from being made.  We want to ensure that if 
the user is shown that the message will be sent encrypted, that it will be
sent encrypted and ONLY encrypted. In other words, a single message should be 
sent encrypted to all parties or unencrypted to all parties; all or nothing.

In comment 57, Brian wrote: 
> I don't think we have a good way to convey to the user that the encrypted 
> email they intended to send was sent unencrypted to a few people. 

Even if we could, we certainly do not want the user to FIRST learn this after
the fact, after the message is sent and the damage is done.

In comment 61, Pete Howell wrote:
> Would I like some visuals to let me know the message is going out encrypted? 
> Absolutely! 

Do you not already have those visuals?  I certainly do!  When I send a message
signed and/or encrypted, I see icons in the composition window's status bar 
telling these facts very plainly while I am composing the message.  See the attached screen shot.
Attached image encrypted and signed — 
here's one take on a greater visual cue for an encrypted and signed message with color, text, and icon hints.  The colors are a little too much, but were just matched from the Firefox SSL/EV1 colors.
Attached image compose signed only — 
here's a similar one that is signed only. again with color, text, and icon hints.  Matched color from the Firefox SSL/EV1 colors.
Those both need some work to clean up so there's no need to pick them apart just yet.  My goal was to get a stronger visual element such that it would be more obvious is the message wasn't being encrypted or signed.  Not sure the signed one is really necessary.
Seven years later, and it seems that the "bug" being fixed is NOT the bug that was identified.

All my clients who used to happily use Communicator (Netscape 4.x) have long since been lost to Outlook.  They use it because there is no "encrypt if possible" option.  These are (virtually) all lawyers, and they understand the issue of keeping it confidential.  They also are required to use x.509 certificates by the law society of the Province, so they need it to work.  

They also conduct the vast majority of their email communications without encryption because the vast majority of their correspondents don't have x.509 certs.  So encryption will always be an "extra" for them.  

The reason it will always be and "extra" is that the uptake of free x.509 certificates, which have been available for years, is nil. Even if free, the cost to the (non-certificate) user is more than the benefit they ascribe to their privacy. I see no recognition of this fundamental situation in all the discussions above.

So I suggest a dose of realism.  Mark this bug "wontfix", because as it stands now, the positions being taken, and the fixes being discussed do not "scratch the itch" that caused the bug to be opened in the first place.   

Go and make a bug that discusses what behaviour Thunderbird and Seamonkey should have. Start with taking a close look at what Microsoft offers, 'cause as far as my encryption-conscious clients are concerned, Microsoft won when the netscape 4.x paradigm wasn't implemented in Mozilla (and then again in Thunderbird).  If it's more important "...to preserve the 
reputation of Thunrderbird's S/MIME (and indeed, of S/MIME in general)..." than to deliver working code, then so be it.  At least we'll know where the future lies.
Hey Derek, thanks for the comment!  You've really clarified the use case for me.  I was finding it hard to understand who was using this system and what for but I think it makes sense now.  I can barely imagine your frustration if you've been watching this bug for 7 years.

The development of this is caught in an internal process.  As Nelson points out Thunderbird carries a reputation of being secure that is important for Thunderbird to continue to uphold.  This use case, as I understand it, isn't so much about security as it is about a poor process that's being imposed on some of our users.  However implementing this use case could damage Thunderbird's reputation of being secure assuming it went in the core product; likely we'd be compared to the security level of Outlook at that point.  Though also likely gaining a better comparison in usability...  This being the struggle of the Thunderbird product process.

If you're interested in getting this fixed I'm willing to help.  I don't think the process allows us to get this into the core of Thunderbird but I do think it allows us to ask for help extending Thunderbird to make this happen.

So to move forward I think we need an extension built that creates the user experience you described.  As we run into road blocks with the code inside Thunderbird we can file them to request changes needed to make the extension work.  Likely this bug would stick around as a meta bug tracking other individual changes needed.

I can give some of my time to this, I think I worked out a couple possible changes to the compose window in comment 57 that would work for this.  If you or other have the programming skill to develop something that should be all we need.  If you don't have programming skill then we need you to be a project manager, gather someone with programming skills and get something moving.  

Email me directly to discuss anything further I'm always available.  A very similar circumstance happened in bug 391272 and by bug 391272 Comment #42 Martin had his own extension to get the behavior desired which should be getting up on addons.mozilla.org soon.
Re comment 62, I am not opposed to all or nothing encryption, that is a valid concern, even though "casual encryptor" is a valid category (doing it more as a matter of principle than because of any actual security requirement).  It is reasonable to make sure that those with real security requirements are protected as much as practical.

The more I think about it, the more I think the right answer is to allow overriding the "always/never" encrypt option from the global settings in the address book:

1.  The current global "always encrypt" is almost completely useless due to the low uptake of encryption, although it could be useful in some very restricted environments

2.  If you're encrypting to someone, you want everything encrypted to them if for no other reason than interfering with traffic analysis

3.  If the cert expires, disappears or has other problems, you want to know (problems would likely trigger their own flags, but a disappearance would be silent under "if possible" rules)

You can flag when mixing encrypt/noencrypt addresses and allow the user to decide what to do in that case, though it would still be nice to have an option to say "this user doesn't have a high security requirement, if other addresses are unencrypted, visually flag it, but go ahead and send in the clear".

Something you *really* want to avoid is the situation with enigmail and rules, where you tell it to encrypt when sending to this address, and it shows no indication that it's actually going to do that before you send.  There really ought to be better interaction also (e.g. I "always sign" my mail, but when sending to a pgp user, have to manually turn off x509 signing).  That's probably a separate issue, but if the "always/never" encrypt were overridden in the address book, it would make sense to have signing overrides there as well for consistency...

Thus, the global settings remain "always encrypt" and "always sign", with overrides in the address book for "always"/"never" "encrypt"/"sign".  It would still be nice if it were arranged that pgp usage would be consistent, i.e. there was a global default encryption protocol setting with address book overrides.

In any case, the little status icons buried down in the corner are hardly "very plain".  Important status like that should be "in your face" (though not to the point of drowning out everything else), more like the icons on incoming mail to the right of the address/subject (though I would like to see them next to the text, where you're more likely to notice them when you've got your mind on the message content, not the message state).

Fixing usability issues like this with encryption would go a long way towards increasing its use so that it *could* be the default state.
Re comment 64, i agree there's no point "sending it twice (encr. + unencr.). However, the "when possible" should be when it's possible for to encrypt for all recipients. Good UI to indicate which it will be is essential for that.

Comment 68 has a good point that the current "always encrypt" is basically unusable (in all normal use-cases).
The "always encrypt" should never have been implemented as it exists today.  This option would only be useful in the address book, configured only for specific recipients.
a related issue is bug 280588 and Bug 276786 that addresses the case where a counterpart cert is present, but hard to handle on the long run in the outbox/inbox once it's used
Duplicate of this bug: 502063
Duplicate of this bug: 512662
Seems related to Bug 149876, if not a dup.
Duplicate of this bug: 315579
Duplicate of this bug: 278989
Duplicate of this bug: 347939
Duplicate of this bug: 566778
URL: https://getsatisfaction.com/mozilla_m...
Whiteboard: [kerh-eha] → [kerh-eha] [GS]
Duplicate of this bug: 732483
So, another three years have gone by with no movement.  What bounty would it take to get this done?  Setup a kickstarter for it and I'll contribute... First we need to define an acceptable solution.  Per the comments above, here's a starting point:


"key available" means *valid* key

Settings:
  Global option to encrypt with s/mime if keys are available for all recipients
  Option to encrypt local mail store

Address book:
  Option to always encrypt to user
    show address green if key available, icons showing type(s)
    red if no key available
    normal if option not selected and no key available
  per-user priority ("this user prefers pgp, this user prefers x509")

Encryption system
  Plugin with priority e.g. "look for x509 first, then pgp"
    overridden by address book
    initially: radio button "try this first" (virtually 100% will have at most two: x509, pgp)
    later: numeric order to support N keystores
  each plugin manages its key store
  x509 moved to plugin

Compose:
  When you select your identity, icons for which encryption systems identity has private key for
  When you enter an address, look for key  (prioritized within subset identity supports)
    if found, green
    else if global option selected, or encrypt to user selected but no key available: red
  If encryption is indicated one way or another but not all addresses can be encrypted
    encryption icon broken

Drafts:
  Drafts *never* signed (287294)

Send
  Fail if encryption expected and not available, return to message edit
FYI, there's an add-on with basic functionality available for that: https://addons.mozilla.org/thunderbird/addon/encrypt-if-possible/

If keys are available for all recipients & sender, encryption is turned on; off otherwise.
The plugin does not work for Seamonkey, so I think this is still a feature request.

Must say: that I dont care about visual feedback, multiple recipients, external cert services and listings and whatever extras.
I personally simply do not like to look a recipients cert up (if I have it or not), before I can decide how to reply.
If somebody sends me a signed message, he surely likes to receives a encrypted reply and Thunderbird/Seamonkey should do this decision automatically.
Duplicate of this bug: 1018203
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
See Also: → 1146728
I just started reading some of your comments to understand why this bug hasn't been fixed for so many years. To me encryption isn't crucial. I just got me a level 1 certificate to try it out. And even in 2016 it is harder to use than you think. It's great that S/MIME is implemented in Thunderbird, but using it is way too complicated. 
To start using encryption I import my certificate, set up my S/MIME preferences (sign e-mails: yes, encrypt e-mails: yes) and if I ever got a signed email from somebody (and they are in my certificate storage) I want to automatically send the following email encrypted and signed. 
This is exactly what happens when I use the Apple Mail app on iOS. When I create a new mail, there is an open lock button. Once I enter a recipient that has a certificate a small closed lock appears next to his name (to show me that I can encrypt the mail to them) and the button shows a closed lock now. Also the title always shows me if the mail is encrypted or not. If I add a second recipient, that doesn't have a certificate, then encryption isn't possible. There's an open lock next to their name, their name (and the small lock) get red, the button shows a red open lock now and the title tells me "encryption not possible". Once I click on the red button I can either confirm not to encrypt it or just send it anyway and it doesn't get encrypted. 
This was just to show you how Apple's work flow works. This means, they always check if a recipient is able to receive encrypted mail. If all are able to, then send the mail encrypted, if not, warn and send it unencrypted.
The UI shows this by various features which I described and this is all in all the kind of experience I would like to have in Thunderbird as well. But here I can only choose to either never send encrypted mails (which means I always have to remember to check "send encrypted" before I send a mail) or I choose "always encrypt" and get an error message (popup) in 99 % of all mails (because probably no single user out there has certificates of all their recipients). 
I get that some users want to have a really secure client, that warns them if an email couldn't be sent encrypted, but having some kind of UI feedback instead, (when choosing "encrypt if possible") like described above would be much easier for most users. 
I really hope to get this feature implemented so encryption can be easier to use.
I have been following this bug since before I graduated college.  Back then, implementing this feature was (for me) more about increasing my ability to advocate the increased adoption of encrypted messaging. Even back then, it seemed like a smart general principle to make encryption easy and widespread, and it was obvious people weren't going to do it unless it was relatively easy and didn't interrupt their workflows too much.

Since then, security purists have basically made it near impossible for users to get there (across the board--not just with this bug). A person above commented that the value of privacy for many is less than the cost of a free certificate and the time it takes to manage and configure it. So true distributed security remains unrealized because we make it too hard. Meanwhile, the task of security for users has mostly moved to the cloud, where there is a monetary reason to implement features users will actually use and rely upon. Unfortunately, this also means that in its current incantation we rely on trusted third parties to keep our information safe. Given one of the great benefits of modern crypto is that we don't need to rely on centralized trust models, I view this as a huge failure of our industry.

With the Snowden leaks and other world events, I hope that people are starting to take a more realistic view on encryption, and particularly to weight more heavily the importance of increasing the percentage of encrypted traffic. And hopefully we are also starting to see the importance of moving away from the centralized security models, although companies that have made their fortunes on mining user data don't really want to let go of the keys to the kingdom.

I've not been a Thunderbird user for over a decade. I gave up. Over the years, I've watched this bug languish variously and be mostly ignored. I'm kind of wondering if at some point this bug will break some kind of record. Or unceremoniously closed one day. Or maybe... just maybe... it will get implemented, and whatever small part of me that retains hope for this bug will finally be satisfied.

Sorry, a bit of a rant/vent. I know its not the best forum for this, but had to get if off my chest after  almost 15 years.
See Also: → 1603809
See Also: → 1532575
Duplicate of this bug: 1613583
Summary: [UE] Implement "Encryption when possible" option → Implement "Encryption when possible" option
Summary: Implement "Encryption when possible" option → Implement "Encryption when possible" option for OpenPGP abd S/MIME
Summary: Implement "Encryption when possible" option for OpenPGP abd S/MIME → Implement "Encryption when possible" option for OpenPGP and S/MIME
Duplicate of this bug: 1665611
Duplicate of this bug: 1669034
Duplicate of this bug: 1669683

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.

Priority: -- → P2

(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.

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)

Duplicate of this bug: 1684783

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.

Duplicate of this bug: 1688493

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.

You need to log in before you can comment on or make changes to this bug.