When setting "require encryption' in the security settings of a mail account, mozilla mail can become very annoying to use. When you don't have all the recipients certificates, an error dialog comes up, as should be. However, the problem is that there is only an explanation and an OK button, but no immediate way of correcting the problem. I think this is a user-hostile interface. In Communicator, you are offered the option of not encrypting the message. It may be that this option does not belong when you set the "always require encryption" setting, but there should definitely be a way to get mozilla to do that, perhaps with a new "try encryption" setting. In that case, the dialog would come up with two buttons, one to abort, and one to disable encryption, just like in Communicator. There should probably be a third option to find ways to fetch the certificate, perhaps links to some directories to go try to look for the missing recipients certificates.

Discussed this with Stephane yesterday. Today, we have two possible settings for encryption : 1) Never (do not use encryption) 2) Required (can't send messages unless all recipients have certificates) Stephane said we should have a third option such as : 3) If possible (send encrypted messages if we have a cert, otherwise unencrypted) I think having such an option is very dangerous, since the client wouldn't even warn you in this case that you are missing the recipient's encryption cert. And what do we do for a message sent to multiple recipients ? Send encrypted to recipients for whom we have the certs, and in the clear to the others ? I don't think it's ever a good idea to have security be optional in a fashion that's transparent to the point that you don't know if your message is going encrypted or not. So I'm against having such a setting. My proposal is to change the second option (required) to completely disallow unsetting the encryption bit in any outgoing messages. This is adequate for truly paranoid or strict policies where no messages are allowed to go out in the clear. The third option would be : 3) always try (prompt to send in the clear if we are missing recipients' encryption certificates) The third option is similar to what communicator does, by prompting you to send in the clear. For both 2 and 3, if we are missing the recipients' encryption certs, there should be an automatic lookup of the recipients' certs in known locations, ie. LDAP , before any error would come up.

See also bug 135636

So we now have two bugs that are in conflict with each other. This bug 149876 and bug 135636 ask for completely different behaviours. While we currently already have two different settings 1.) never encrypt and 2.) always encrypt we have now requests for two new behaviours in addition 3.) make it easier for users to overwrite the default encryption setting, by just having to use one click, instead of multiple clicks (this bug 149876) and 4.) do as secure as it is possible, but do not bother user (bug 135636) It seems to me that the modes are a matter of taste, and all could be chosen as the default in deployments. If we want to, we could support both behaviours as described in 3.) and 4.). Julien, I want to comment your suggestion. I think it is not required to change the current behaviour of 2.) It already requires the user to take action to turn off the encryption setting. It can't be turned off by accidentially hitting enter in a prompter - as it would be the case in your suggested configuration 3.) So I don't see why we should make that mode even more restrictive. To my understanding, it is possible to "lock" preferences if that is wanted in a deployment, and we could make sure that our code actually allows one to lock that pref. I think more 3.) has it's right for existence, too. But if we ever implement this bug and support 3.), we should not make it behave exactly like Communicator. I vote that in the shown dialog prompt, "send" is NOT the default. It should not be possible to send the message by simply pressing enter or clicking OK. The user should be forced to read and make the decision. The standard action and the cancel action should be the same, and both should return the user to the compose window, canceling the send operation. If the user actually wants to send without encryption, the user should be required to select a non-default button, IMHO. (Automatic LDAP directoy lookup is work in progress, and the first step has been landed with bug 119394.)

The conflicts in requirements occur because of the multiple environments that encryption is used in: Environment 1: the casual user who think encryption is cool, would like to see all network traffic encrypted, does not want to be bothered on every email. Environment 2: The user is using encryption because the data being sent is sensitive and compromise of this data could lead to 1) financial loss, 2) business failure, 3) breach of national security, 4) death or injury of one or more people. In practice most people fall under the catagory of environment 1 or a mix of environment 1 and environment 2. Most of us developers work in environment 1, which is why Communicator allows you to easily select "just encrypt whenever you can". This feature is nice, and satisfies a vast majority of customers, but it doesn't satisfy any customers that really *need* encryption (those in environment 2). Any secure email product, if it is to serve environment 2, must be very agressive about *NOT* sending out email with weak or no encryption (Note: in these environments sending email out with weak encryption is often more dangerous than sending email out with no encryption because weak encryption tags the message 'look at this, it's important data' without making the encryption strong enough to prevent cracking). If the data really is important enough to secure, it's important enough to prevent accidental sending by the user. The final complication is the most common environment would be mixed. You want to always encrypt email that deals with confidential or sensitive data, but the vast majority of email you send is not exactly confidential, and includes recipients that can't do encryption. This environment certainly isn't filled with any of your current products, and determining how you classify email data on the fly is difficult. For now we at least need to make sure that it's difficult for an Environment 2 user to accidentally drop into Environment 1 configuration because even though there are less environment 2 users, failure in that environment is much more disasterous than failure in environment 1. bob

I agree with Bob's assessment of different encryption needs for different environments. I don't think there are enough knobs currently in the browser to tweak all the settings to meet the requirements of the different classes of customers. I'd recommend that we address this problem through a combination of (1) a different bug request and (2) the following options in our email: - never encrypt - try to encrypt (allow user to send without encryption) - always encrypt (not possible to send messages without encryption) If a customer wants to enforce their "always encrypt" security policy on their employees then they should use a "mission control desktop" type utility to: - remove options #1 and #2 - insert their corporate LDAP URL to auto-retrieve certs as needed This fulfills that company's requirements to "always encrypt" or else not send the message*. The key is that the users can't make that change easily in order for this to work anyhow. So the "require email encryption" setting isn't really enforcable with a browser that is trivially changed. If a customer doesn't have the Mission Control Desktop modified browser then they can set the preference however they choose and endure whatever level of pain they'd like. * - Pertinent to that new feature request would also be a setting that says "if all of the recipient's email address aren't in LDAP and they don't already have their cert, allow the user to dismiss the warning and send the message anyhow." This setting, would be optional for the corporate admins to set too, if necessary. It would address the problem where the company says "all corporate mail is encrypted but outside isn't required to be encrypted".

I read bug 138818. My request is the same as what Charles detailed very nicely in comment #10 of that bug for the "if possible" behavior. In comment #11 of that bug, Stephane points out that the design calls for no warning dialog for "if possible", just a broken lock icon. I personally don't think that's sufficient feedback, and I'm in environment 1 "a developer who think encryption is cool", as Bob put it. The "require encryption" setting is not an adequate solution either, as it is very cumbersome to close the error dialog and then go back into the message to toggle off the encryption bit for each non-encrypted message. I think the decision of not having a warning dialog for "if possible" needs to be revisited, and there needs to be a way to show the warning, as pointed out by Charles. Kai, as far as comment #3 in this bug : I won't insist on changing the behavior of 2. You are right that it's probably not required, I just thought it might be useful for some very high security environments. Perhaps we could display the various encryption settings by level of security : 1) no encryption (always in the clear) 2) encrypt if possible, send in the clear if missing recipient cert 3) encrypt if possible, prompt if missing recipient cert 4) require encryption, disallow unencrypted messages, allow untoggling the encryption bit manually 5) require encryption, disallow unencrypted messages, disallow untoggling the encryption bit manually Perhaps 5) is pushing security to a very tight level, but I think it can't harm to have it . I can see how a government customer would want to enforce such a policy. In fact I have seen TV news reports about soldiers using insecure emails to communicate with their family and creating security breaches. This browser setting would completely prevent it from happening even accidentally.

FYI, there is another major usability issue when selecting "require encryption, related to focus. I opened http://bugzilla.mozilla.org/show_bug.cgi?id=154015 to track it.

I suggest the additional option "require encryption when replying to an encrypted mail".

*** Bug 165337 has been marked as a duplicate of this bug. ***

after re-reading bug (135636) to decide which to vote for, it is unclear to me that they ARE in conflict. I think that comments #6 & #8 of this bug would cover most of the requests in the other bug. My own position is that the mozilla e-mail encryption choices are less useful than the netscape 4.x choices, and I'd like at least the same options. TIA! d.

Is there any activity on this usability bug? There appears to be paralysis, or is it just complete lack of interest? I have firms > $100 per class 4 cert to use with e-mail. The Law Societies in Canada are moving towards requiring these certs for accessing certain web services (land titles and other registries) on line. 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 (like surrender and spend my days patching IE and Outlook). 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

Mass reassign ssaux bugs to nobody

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.

Is there any way I can get someone to pick this up? I still have $200 to pay to get the NS 4.x paradigm re-implemented. My users didn't complain about the "encrypt if possible" setting. Mozilla is a PITA if one is using x.509 certs. Below is today's impetus for finding this bug and posting to it yet again... Just one of 23 dis-satisfied users. Please, everybody on the list post another request and maybe we can get this changed from "unassigned" and the priority changed from ---. Or would it be better to ask for an enhancement in TBird? Things seem to get fixed there (anyone pasted a screen shot in mozilla in recent years?). Someone please clue me in about how things work. -------- Original Message -------- Subject: encryption Date: Thu, 26 Aug 2004 11:28:50 -0700 From: Irene Faulkner <XXXXXX> Organization: Arvay Finlay, Barristers To: Derek Shaw <spam @ 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

Outlook has always had a 3rd option available the entire time and makes it much easier to handle encryption for those people that wish to always have messages encrypted whenever possible. At this time, I have to leave the option turned off and often forget to encrypt messages that could have been encrypted; this is because the "Required" option is a real pain; you have to turn it off for most messages (since most people don't have certificates). I think that this option is extremely important. If the concern is that a message may not be encrypted and a warning should be generated, I think this should only be the case where a certificate is no longer valid; otherwise, if a certificate never existed, then encryption is not to be expected. It is very sad to see that no progress has been made on this functionality.

The encryption usability in Thunderbird is a HUGE issue for people who want to use this in a mixed-mode environment. I currently cannot use or deploy Thunderbird because of this. I can't understand why this has been an open issue 4+ years now. Can anyone comment on what (if anything) is going on with this?

Why is this only listed as severity "enhancement"? Any large corporate user would consider this deficiency a major problem. The fact that Outlook as this capability and Thunderbird does not means that many big customers will never switch to Thunderbird. Please consider adding the option "If possible", with a sub-option of "Warn if unable to encrypt". I can't imagine this would be hard to implement if someone would only realize that this is a serious deficiency that prevents a lot of large customers from migrating to Thunderbird.

Bugzilla has poor support for tracking new feature work. Ideally there would be one field tracking the "defect vs. new work" distinction and a separate field tracking severity/importance. But Bugzilla is far from ideal; if the product is working as intended, no matter how boneheaded, then changing it is an "enhancement" and there's no good way to indicate the importance of the new feature. Firefox tracks those things on wiki.mozilla.org product design pages, but I don't know if the Thunderbird project is quite that organized since there aren't that many people contributing to the project.

I think that this can't be looked at as a new "feature" request, but it is truly a deficiency. Outlook has provided this support for 5 years now because it is a necessary option; no one would use it otherwise. This really needs to be changed from "enhancement" to a higher severity. The fact that this option doesn't exist is hurting the product because many companies, ourselves included, will not migrate to it for this reason.

It's been another year and a half with no change on this issue. I assume that no one is going to work on this?

well, no one really settled on what they wanted. the api as is isn't very kind to anyone who might want to fix it. while i could hop through all the fields to see what might be changed (i've reached 10+ functions), it makes more sense to decide on how the ui should look, feel and act before trying to implement something. Assuming gecko could automatically determine as recipients are added to the list whether it would be able to send the message encrypted, would people be ok with: This message can't be encrypted, if you don't care, check here: [ ]. As some form of info banner. Note that there are clearly 3 major cases: 0. users never use encryption 2. users must always use encryption 1. users are hobbyists and would like to use encryption There's actually another option: 10. users rarely use encryption but wouldn't cry if they were told that all recipients of this message could receive an encrypted version: This message could be encrypted, if you would like to check here: [ ]. Ideally, if done right, it should be possible to disable the send button in advance to prevent people from getting the dialog in the first place. Could someone possibly check the last version of Eudora from before they started using Gecko and indicate which features they offer wrt this? It might prove to be a way forward. As to getting this fixed sooner, there are some contracting groups (not me) who might be willing to work on a bug like this, you could try contacting them.

Is this related to, or a dup of Bug 135636?

(In reply to comment #22) > Is this related to, or a dup of Bug 135636? To answer Bob, yes and no. Both bugs should be marked as "Won't Fix" so we can all move on. See this comment on the bug you are enquiring about -- FROM SEVEN YEAR AGO! https://bugzilla.mozilla.org/show_bug.cgi?id=135636#c18 The two bugs give a great example of how the open-source model fails the general public. Because the "customers" here are the developers, the huge numbers of people who would dearly love this to be a viable option to proprietary software (and are willing to pay for it) are S.O.O.L. Give up now. Find another solution. The "Thunderbird is secure" purists (as exemplified by this comment https://bugzilla.mozilla.org/show_bug.cgi?id=135636#c62) have so thoroughly mis-understood and mis-defined the problem that the "people want a usable product" pragmatists (https://bugzilla.mozilla.org/show_bug.cgi?id=135636#c67) are reduced to pointing out (a year ago) that "...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." This is a user-interface problem that won't be fixed. Security always impacts usability, and this software is and will remain secure, in the same way that a computer powered off in a locked room is secure.

If you don't plan to fix this, then please remove the default encryption settings entirely as it is not something anyone can use as it was originally designed for the reasons outlined in this bug. By removing the default encryption setting, you will make the product simpler, less confusing and this issue can go away entirely.

And again - years have gone by without any change, this one is open for more than 12 years now .... We now live in a time where security is priority number one. The options we have now are: 1. Don't use encryption (insecure) 2. Always use encryption (won't work most of the times because s/mime is still not used by many users) So what is the harm in adding: 3. Use encryption when this is possible (warn if encryption is not possible) 4. Use encryption when this is possible (do not warn)

I want to react on the first reaction in this thread - from Julien Pierre He wrote: "I don't think it's ever a good idea to have security be optional in a fashion that's transparent to the point that you don't know if your message is going encrypted or not. So I'm against having such a setting." The same thing is true when you are using TLS connections; you upload the mail to your mail server using TLS, thinking that this makes the communication secure. But when the recipients mail server does not support TLS or when the recipient does not use TLS when he downloads the message, the communication is not secure at all. But that does not mean that we do not have to use TLS. For encryption, the same is true; we cannot influence if the recipient supports encryption (gmail web users can not for instance) - but that does not mean that we should not secure every single communication that can be secured. So even the selection of option 4 makes the internet a more secure place than it is today.

tverweij, SSL/TLS is about transport-level encryption. Even if you use TLS for the connection between your client and server, you obviously have no control about what happens to the message after the server receives it. The message could be broadcast on TV afterwards for all we know. The TLS setting obviously applies to that particular connection only. With S/MIME is about end-to-end encryption. When you use S/MIME, you want to ensure that your recipient has to use his S/MIME private key to read the message, egardless of how many hops may be compromised during the delivery of the message. If you make the S/MIME work optionally, something as stupid as a typo in the recipient's e-mail address could cause your e-mail client not to find the recipient's certificate, and not encrypt the message. The result is that your sensitive message, which you assumed would go out encrypted with the recipient's public key, will instead go out unencrypted. Not only that, but it will come back to you as a bounce in the clear, too, because of the typo in the e-mail address. IMO, the optionality is very dangerous. Some warning is warranted. It shouldn't be done silently.

We disagree - you only want s/mime security for specific threads, I want the highest security possible for each thread. And I think when if something is very sensible, you have to double check the recipients before sending the email, with or without encryption. But I now found the extension "Encrypt if possible 1.0" that does what I need (it implements both options, with or without warning), although I still think it should be possible in Thunderbird itself (option3 for you: with warning, option 4 for me: without warning).