1796631 - Add user visible prefs to control the automatic behavior for enabling or disabling encryption (automatic enabling is limited to scenarios in which no further user configuration is necessary)

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Kai Engert (:KaiE:)]

Please read bug 135636 comment 232.
This bug here is about "step 2".

Comment 1

[jschoett]

from bug #1795981 comment #15:

• Regarding the behavior on "from" switch in the compose window: I think it would be logical for users if on any switch the account default is applied – except when the user already manually changed the encryption state and made it sticky.

Consider the following scenario:

[..]

In this scenario, the user did NOT click the encrypt button at all.
However, despite account's A setting "enable encryption by default",
the message will be sent from account A without encryption.

What I meant is that everytime the user switches the "from" the from-account settings can be applied. This would of course require to hook into this switch. If account A has encryption enabled and it is switched back to account A, encryption will be enabled again.

I still think that encryption settings are account setting – because the keys are linked to accounts – and having those settings together would be nice and easier to understand for users.

But anyway, I'm looking forward to have this in a future release :)

Comment 2

[Kai Engert (:KaiE:)]

Attachment: Bug 1796631 - Add strings for encrypt-if-possible prefs. r=aleca

Comment 3

[Kai Engert (:KaiE:)]

Attachment: For enabling end-to-

Comment 4

[Kai Engert (:KaiE:)]

This comment is my full explanation why I think it should be a global pref, including some background, to allow me to refer others to it.

For enabling end-to-end encryption, until Thunderbird stable 102.x and Beta 112,
it was always necessary to manually enable and disable encryption.

There was only one small automatism, when replying to an encrypted email,
encryption was automatically enabled.

Starting with Thunderbird Beta 113, a mode to automatically enable
encryption is offered. Optionally, if configured, Thunderbird may
also automatically disable encryption, if encryption is no longer
possible after changing the list of recipients of an email.

This means users are offered a choice, whether they want to have full
manual control over encryption being enabled, or whether they want
Thunderbird to assist them automatically.

There is an open question related to this mode. The question is,
should this automatic mode be a global application mode, or should it
be a mode that's specific to individual email accounts and identities?

In other words, should users be able to request that for some email
accounts they want the full manual control mode, and for other email
accounts they want the automatic mode?

In my opinion it should be a global mode. The user should either have
automatism for all their identities and accounts, or have the full
manual mode for all their identities and accounts.

In this text I want to justify why I think the global pref is better.

My first argument is about the global pref being more convenient.

Currently we require that users opt in to use the new automatic mode,
because we're still gathering feedback and experience.

If "enable automatically if possible" was an identity specific pref,
and a user wanted to make use of the new automatic mode,
then the user would have to go to every identity and
manually change the pref for each of them.

With an per identity pref, a user might discover the pref,
and change the pref for one identity, only, without realizing that
it would be best to change the pref for all identities.

Then, if the user doesn't get automatic switching with one of their
identities, (because the pref is still disabled for that identity),
the user might be very confused about the inconsistent application behavior.
(Automatism with some identities, no automatism with others.)

My second argument is about potentially surprising and confusing
behavior when switching the sender identity in a composer window.

When in manual mode, when encryption is turned on, then Thunderbird
uses language like "you must resolve these problems to use encryption",
or requiring the user to manually disable encryption.

I think for a user who doesn't fully understand that the automatic
mode is an identity specific pref, it would be very difficult to
understand why selecting a different sender identity would cause
these warnings to disappear.

Because of that potential confusion, I think that switching the
sender identity should never automatically hide these encryption problem
notifications.

If the automatic mode is a global pref (and the user allows both
auto_enable and auto_disable), then these warnings usually wouldn't be shown,
despite switching sender identity. They'd be shown only after the user
clicks the encryption button to override the desired behavior for this
message, and after that, the warnings remain, even after switching
the sender identity.

I think that would be good consistency.

With a per identity pref,
if users have some auto-mode and some manual-mode identities,
the automatic mode might get disabled and switched to manual mode
when switching a sender-identity, and users might not understand
why the previous automatism no longer works (even after switching back
to an automatic-mode identity).

If the automatic mode is a global pref, then users will see a
predictable behavior across all their identities, the automatic mode
will continue to work across all identity switches.

Comment 5

[Magnus Melin [:mkmelin]]

It sounds a bit like your justifying it being a global pref by "users don't understand identities". Maybe they don't, maybe they do. But we have identities. For flexibility.

I'd assume the goal is to get as many people as possible using it? I think having it global can actually make that more difficult.
In my own usage, I can imagine turning it on for some identities, but not others.
It's easily thinkable different accounts have different possibilities to enable encryption: different backup types, different access through mobile etc. affecting your willingness to take on the downsides of encryption for that account.

Comment 6

[Kai Engert (:KaiE:)]

My goal is simplicity and sanity here. This is a mode that is intended to simplify life for users who want it. I believe having this mode global is sufficient, and having this mode per-identity is also complicated from the implementation side, and for the other reasons I have given.

I think if someone really doesn't want encryption for some accounts, I believe they understand what they are doing, and should just rely on the reminders and control encryption manually.

Comment 7

[Kai Engert (:KaiE:)]

Attachment: Bug 1796631 - Add UI for mail.e2ee.auto_enable and related prefs. r=elizabeth

Comment 8

[Kai Engert (:KaiE:)]

Attachment: mail-e2ee-global-prefs.png

Comment 9

[jschoett]

Thank you for your work Kai! I support your arguments for having it as global mode. I personally find many other account-specific options annoying.

In my current work/personal live, I can't imagine these different scenarios that Magnus described. But if it comes so, I'd be OK with relying on existing reminders and keyboard shortcuts for enable/disable encryption. Or future development / add-on APIs.

Comment 10

[Kai Engert (:KaiE:)]

Attachment: e2e-global-v2.png

Changes have been suggested in phabricator.
This is an updated screenshot, based on phab diff 3
https://phabricator.services.mozilla.com/D175371?id=706744

Comment 11

[Kai Engert (:KaiE:)]

Attachment: prefs-v3.png

Updated again. Based on phabricator "diff 4"

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b6859a9a4738
Add UI for mail.e2ee.auto_enable and related prefs. r=elizabeth,mkmelin