Bugzilla

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

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

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

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

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

The last point is my primary concern of any solution that we consider.
I'm worried about the following scenario:
- The user composes an email, and enters one initial email address.
- We can encrypt, we automatically enable encryption. We show status in the UI that encryption is enabled.
- The user notices that encryption is enable, makes a mental note that it is enabled, and feels safe about typing sensitive information.
- The user prepares the email, writes all the text, and the user is almost ready to send it.
- In the last minute, the user decides to add another recipient. But we cannot encrypt to that recipient.
- Because the user is in automatic mode, we automatically disable encryption.
- However, the user might not notice that we automatically disabled encryption

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

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

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

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

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

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

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

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

The last point is my primary concern of any solution that we consider.
I'm worried about the following scenario:
- The user composes an email, and enters one initial email address.
- We can encrypt, we automatically enable encryption. We show status in the UI that encryption is enabled.
- The user notices that encryption is enable, makes a mental note that it is enabled, and feels safe about typing sensitive information.
- The user prepares the email, writes all the text, and the user is almost ready to send it.
- In the last minute, the user decides to add another recipient. But we cannot encrypt to that recipient.
- Because the user is in automatic mode, we automatically disable encryption.
- However, the user might not notice that we automatically disabled encryption

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

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

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

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

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

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

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

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

The last point is my primary concern of any solution that we consider.
I'm worried about the following scenario:
- The user composes an email, and enters one initial email address.
- We can encrypt, we automatically enable encryption. We show status in the UI that encryption is enabled.
- The user notices that encryption is enable, makes a mental note that it is enabled, and feels safe about typing sensitive information.
- The user prepares the email, writes all the text, and the user is almost ready to send it.
- In the last minute, the user decides to add another recipient. But we cannot encrypt to that recipient.
- Because the user is in automatic mode, we automatically disable encryption.
- However, the user might not notice that we automatically disabled encryption

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

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

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

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

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

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

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

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

The last point is my primary concern of any solution that we consider.
I'm worried about the following scenario:
- The user composes an email, and enters one initial email address.
- We can encrypt, we automatically enable encryption. We show status in the UI that encryption is enabled.
- The user notices that encryption is enabled, makes a mental note that it is enabled, and feels safe about typing sensitive information.
- The user prepares the email, writes all the text, and the user is almost ready to send it.
- In the last minute, the user decides to add another recipient. But we cannot encrypt to that recipient.
- Because the user is in automatic mode, we automatically disable encryption.
- However, the user might not notice that we automatically disabled encryption

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

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

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