Closed Bug 1628095 Opened 5 years ago Closed 3 years ago

Should email "sign" and "encrypt" automatically go together?

Categories

(MailNews Core :: Security: OpenPGP, enhancement, P2)

Product:
MailNews Core
Component:
Security: OpenPGP
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: KaiE, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

enig-account.png
38.35 KB, image/png
Details

When reviewing the current experimental OpenPGP behavior, Magnus noticed that "sign" and "encrypt" need to be enabled separately. He suggests that possibly, when enabling "encrypt", we should automatically enable "sign", too.

For S/MIME we haven't done that.

Enigmail has it configurable. There were separate prefs for "if encrypt, also enable sign" (what Magnus suggested) and "if sign, also enable encrypt" (might be less interesting).

There are potential scenarios why you might want to encrypt, but not sign. For example, if you want to send a rumor, you might want to use confidential sending. However, you might not want to provide a proof that you said it.

Seems to me such cases are really more academic than from the real world: for your example in case you'd be charged with libel in the end a court would decide if you were guilty or not - I think signing status is just one small unimportant part of deciding that (maybe just someone in your house sent the mail while you left the computer open, etc.). I just don't see the real usecase for not signing.

We need a way that allows the user to say "encrypt yes, sign no".

If "enable encrypt" automatically enables signing, too, then we should allow the user to disable signing by unchecking the checkbox in an additional manual step.

Magnus, you have one special scenario in mind that might seem most reasonable to you. But other people have different requirements, and might disagree with your position. At the very least, we need to offer flexibility.

I'm OK to offer the automatic change you suggest, and we wait for reactions. But I think that for every bit of automatic behavior, we'll get requests to have it configurable to behave in a different way.

Also, if we add an automatic dependency between encryption and signing settings in composer window, the question is, what does this mean for the configured default preferences for encryption and signing (which currently are strictly separate).

It's ok to have it configurable, but OTOH I think it's our job to provide the user with reasonable defaults, and it shouldn't be easy to set up an almost faulty default configuration.

Perhaps the signing section needs to be slightly reworded. It could be

[ ] For unencrypted messages, add my digital signature by default
[X] For encrypted messages, add my digital signature (recommended)

Could we offer a radio button choice that better covers all the scenarios and simplifies the wording like:

Add my digital signature

  • On every message
  • Only on encrypted messages (recommended)
  • Ask me every time

Is there a scenario where adding a signature to a NON encrypted message is needed?
What do you think?

(In reply to Alessandro Castellani (:aleca) from comment #5)

Is there a scenario where adding a signature to a NON encrypted message is needed?

First use case would be verifying that it's you who sent the message and it had this content when you did.
For S/MIME you also sign it so that the recipient in the process gets your public key so that they can send encrypted messages to you.

Mh, that makes sense.
I guess the following question is, is there a scenario where the user wants to add the signature only on NON encrypted messages, but NOT adding it on encrypted messages?
I wonder if we need that distinction or we can simplify with the 2 options "Always add it" or "Add it only to encrypted messages".

I was still writing the response to your other question, but let me respond to the simple question first, as Magnus did:

(In reply to Alessandro Castellani (:aleca) from comment #5)

Is there a scenario where adding a signature to a NON encrypted message is needed?

Yes, that's a common scenario.

Sending an encrypted message is more complicated, because you first need to obtain valid public keys for all message recipients. Often, that's not possible, for various reasons. You might not be able to wait until they get back to you. Or you're sending to a mailing list, to which sending encrypted is impossible.

However, sending with a digital signature is easy, regardless to whom you are sending. All you need is your personal key.

Sending signed, but not encrypted, can be used if you want to demonstrate to the recipients that the message is really sent by you.
This is commonly used by maintainers of security software, when they announce new releases of the software, together with checksums for the release archives.
I regularly receive messages that are signed, not encrypted, from banks or post offices.

(In reply to Alessandro Castellani (:aleca) from comment #7)

I guess the following question is, is there a scenario where the user wants to add the signature only on NON encrypted messages, but NOT adding it on encrypted messages?

No, I don't think we need to distinguish that.

I wonder if we need that distinction or we can simplify with the 2 options "Always add it" or "Add it only to encrypted messages".

You need the third option "don't sign by default".

Could we offer a radio button choice that better covers all the scenarios and simplifies the wording like:

Add my digital signature

  • On every message
  • Only on encrypted messages (recommended)
  • Ask me every time

We don't ask, so I wouldn't use that word.
Rather, inside composer, the user is able to make a decision to find the setting in the dropdown menu, and change a setting for the current message. Regardless of the setting configured in prefs, the user has always the choice to change the setting inside an individual message.

The tricky thing is really, it only influences what options is checked when opening the composer window.

If you say something like "add it only to encrypted messages", someone might conclude, this is always done when encryption is enabled - whether it was set by default on composer open - or if the user manually enabled encryption in an email. If the user does the latter, allowing the user to individually control "sign or not sign", it would be a contradiction to the promise made by the pref.

So the 3 options could be:
Add my digital signature

  • On every message
  • Only on encrypted messages (recommended)
  • Don't sign messages by default

And underneath we can have a description stating: "You can modify these options independently when composing a new message" or something like that to let the user know that these are just the default settings, but can be manipulated on a per-message base.

We could consider also adding some text feedback when the user changes these settings in the composer window, something like:
"Your digital signature was removed for this message, this won't affect your default settings for future messages."

(In reply to Alessandro Castellani (:aleca) from comment #11)

  • Only on encrypted messages (recommended)

This option can be set indepenently of the encrypt by default setting. So we need to define what will happen while working inside composer.

If this selection is combined with "do not enable encryption by default", then on composer open time, signing is disabled.

What happens if the user manually enables encryption for the individual message? We'd have to automatically enable signing.

What happens if the user then decides to disable encryption again, in the same message? We'd also disable signing automatically, right?

The above is what happens if the "first" action inside the composer window is to enable encryption.

But, if the first action made by the user is to "enable signing"? If the user enables encryption as a second step, we can keep signing enabled, that's aligned with the default pref. But, if the user then disables encryption again? In that scenario, I'd keep the signing enabled, and don't disable it, because the user had manually enabled signing.

Does that make sense, or does it seem confusing?

And underneath we can have a description stating: "You can modify these options independently when composing a new message" or something like that to let the user know that these are just the default settings, but can be manipulated on a per-message base.

We could consider also adding some text feedback when the user changes these settings in the composer window, something like:
"Your digital signature was removed for this message, this won't affect your default settings for future messages."

It may be complex to decide in which situations a warning message is appropriate.

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

And underneath we can have a description stating: "You can modify these options independently when composing a new message" or something like that to let the user know that these are just the default settings, but can be manipulated on a per-message base.

This statement below the choices seems like a good idea, it can avoid having to use the expression "by default" in the radio labels.

Alessandro, can you please state your opinion on comment 12? Thanks

Flags: needinfo?(alessandro)

That makes sense, thanks for the detailed explanation.
I agree with this direction.

Flags: needinfo?(alessandro)

[deleted]

I've deleted comment 16 because it actually belongs to bug 1628097

The need to migrate prefs makes this more complicated.

mail.identity.default.sign_mail has been used in the past for the "sign by default" configuration.
It seems like we want to transform that into a three state integer pref.

If the user has previously enabled "sign by default", then obviously, it's already enabled for all messages.

If the existing prefs says "don't sign by default", would it be safe to migrate that into the middle state "sign if encrypted"?
For users who used S/MIME ecnryption in the past, and who didn't usually sign - they would now suddenly get signatures enabled automatically.

So from a paranoid point of view - we could cause unexpected trouble for users who want to encrypt, but who don't want to sign.

However, if we treat the old value "don't sign" as the new value "never sign", then NO users will get the "sign if encrypted" automatically - only for those users who opt in.

It's a difficult situation. Maybe we need to take the middle approach nevertheless - migrate "don't sign" to "sign if encrypted", and explain that in release notes.

Maybe like this:

  • remove the old pref from the default prefs file
  • add a new integer pref with value -1

Code that checks for the pref uses the following logic:

  • if the new pref is still -1, fall back to check the old pref
  • if the new pref is other than -1, then use the new pref
  • the first time the account prefs are opened, we detect the -1, and migrate to the new pref values (middle choice, or always)

[deleted - needs more thinking]

Attached image enig-account.png —

The previous screenshot shows the relevant controls from Enigmail.

I have deleted my most recent previous comment, because those thoughts weren't yet in a presentable state.

I'd like to keep this open for another while. I have the feeling that it might be more complicated than we have discussed yet. I don't have a final opinion yet.

I suggest that we land the automatic behavior as implemented in bug 1628097 (which does enable signing automatically for encrypted messages), and gain some more experience, before we come back here and make final decisions for the behavior/prefs and UI.

I have seen multiple requests asking for a mechanism to control this.
Let's ensure we do this in time for the 2021 release.

Severity: normal → --
Priority: -- → P2

I think this is working as it should. ->WFM

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: