Bugzilla

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

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

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

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

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

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

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

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

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

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

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

Let's look at another example.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let's look at another example.

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

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

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

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

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

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

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

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

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

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