Tails

#1 Updated by intrigeri 2018-06-16 08:45:22

• Assignee set to sajolida
• Type of work changed from Discuss to User interface design
• Affected tool set to Email Client

segfault wrote:
> It was reported that a user accidentally sent sensitive content via email in cleartext because they somehow lost their persistent Thunderbird settings, and when they added their email account to Thunderbird again, they forgot to enable Enigmail in the preferences, and sent a sensitive email in cleartext.

Ouch!

> I think issues like this could be easily prevented by enabling Enigmail in Thunderbird by default (that is Account Settings -> OpenPGP Security -> Enable OpenPGP support (Enigmail) for this identity). In effect, when writing an email for which no secret gpg key was found, it will display the red warning “This message will be unsigned and unencrypted”.
>
> This could be achieved by simply creating /etc/skel/.thunderbird/profile.default/prefs.js with this content: user_pref("mail.identity.id1.enablePgp", true);.

… or even better (?) in config/chroot_local-includes/etc/thunderbird/pref/thunderbird.js (without the user_ prefix) so this applies to already existing persistent config. If we do that we should IMO do it for N>1 accounts, not just the first one, otherwise we’re introducing too much UX inconsistency IMO.

I’ve tried that and there’s a catch: the email composition window gets an icon in the toolbar to sign email, and then of course sending email fails because there’s no secret key with which the message can be signed. Without this pref that toolbar button is greyed out i.e. we don’t display UI that cannot be sensibly used.

I’m not sure what is best and I think we need input from our dear in-house UX expert :)

#2 Updated by intrigeri 2018-06-16 08:47:29

• blocks Feature #15392: Core work 2018Q2 → 2018Q3: User experience added

#3 Updated by segfault 2018-06-16 13:50:39

• File Enigmail Alert No usable OpenPGP key.png added

intrigeri wrote:
> segfault wrote:
> > It was reported that a user accidentally sent sensitive content via email in cleartext because they somehow lost their persistent Thunderbird settings, and when they added their email account to Thunderbird again, they forgot to enable Enigmail in the preferences, and sent a sensitive email in cleartext.
>
> Ouch!
>
> > I think issues like this could be easily prevented by enabling Enigmail in Thunderbird by default (that is Account Settings -> OpenPGP Security -> Enable OpenPGP support (Enigmail) for this identity). In effect, when writing an email for which no secret gpg key was found, it will display the red warning “This message will be unsigned and unencrypted”.
> >
> > This could be achieved by simply creating /etc/skel/.thunderbird/profile.default/prefs.js with this content: user_pref("mail.identity.id1.enablePgp", true);.
>
> … or even better (?) in config/chroot_local-includes/etc/thunderbird/pref/thunderbird.js (without the user_ prefix) so this applies to already existing persistent config.

Yes, that might be better because we already use this file to change Thunderbird defaults. But I’m not sure if it’s actually a benefit that this would apply to already existing persistent config.

> If we do that we should IMO do it for N>1 accounts, not just the first one, otherwise we’re introducing too much UX inconsistency IMO.

Agreed. So if we decide to implement this we have to choose an N.

> I’ve tried that and there’s a catch: the email composition window gets an icon in the toolbar to sign email, and then of course sending email fails because there’s no secret key with which the message can be signed. Without this pref that toolbar button is greyed out i.e. we don’t display UI that cannot be sensibly used.

Good catch! That is indeed annoying, especially because the error message is not very helpful, it just says “Sending of the message failed”. I also tested this with Enigmail 2.0.7 from Sid, and there the error message is much better (see attached screenshot).

So IMO reasonable choices are:

1. Enable Enigmail by default now and have our users deal with the unhelpful error message (until we are based on Buster) in case they try to sign without creating a key first.

2. Only enable Enigmail by default in our Buster release and take the risk that similar accidents happen until then.

> I’m not sure what is best and I think we need input from our dear in-house UX expert :)

Agreed.

#6 Updated by sajolida 2018-07-05 17:22:27

• Assignee changed from sajolida to segfault
• Type of work changed from User interface design to Research

I also did some tests :)

First, let’s try to go back to the root causes of your friend’s problem:

• How come they lost their persistent Thunderbird settings? Do you think it was Bug #10976 or something else? I would be curious in analyzing this further. Sending unencrypted emails by mistake shouldn’t happen and might also happen to people who didn’t loose their persistence settings. But persistence settings should also not disappear for no reason and if they hadn’t, your friend would have been safe.

• Your friend sent an unencrypted email without noticing. Enigmail did some work in 2.0.7 to make the status of the outgoing email more visible. Maybe that would have helped your friend. I personally enable “Always confirm” on all my machines. Maybe we should consider doing this in Tails by default, or set it to “If unencrypted” (and let people who are annoyed by it disable it). We could search for upstream discussions regarding the default setting which is “Never”. Note that this setting doesn’t apply until Enigmail is enabled so your point still applies. But if your friend had been used to clicking through the confirmation dialog, he might have noticed that his email was unencrypted (and maybe only have sent one unencrypted email instead of several).

Regarding what you proposed, I’m of course worried about single drop of added complexity and possible confusion that we are pushing to non-Enigmail user. I don’t have any stats on how much of our user base uses Enigmail in Tails, but I’d rather consider OpenPGP a tool that only a minority of our user base can use (at least the user base I’m interested in seeing adopting Tails).

During my tests in Tails 3.8 I didn’t see the error message that you put in attachment displayed to me by default. But the Enigmail icons in the email composition window were different: they had a red cross instead of being deactivated. Clicking on the red cross would show me the error message that you are referring to. Sorry, I lost the screenshots I prepared while shutting down my test machine :(

Putting myself in the shoes of somebody who doesn’t even know that OpenPGP is and innocently clicks on the scary red cross in their composition windows, I wouldn’t understand that message: “What is this OpenPGP thingie? Am I shooting myself in the foot if I send my email with that red cross on? How do I get it off?”

So could it be possible to:

• Only enable Enigmail automatically if we detect an OpenPGP secret key in “~/.gnupg”?
• Or make sure that people go through the Enigmail Setup Wizard if they have some OpenPGP secret key?

If not, then I’m probably against this proposal.

#7 Updated by segfault 2018-07-05 23:23:13

• Assignee changed from segfault to intrigeri

sajolida wrote:
> I also did some tests :)
>
> First, let’s try to go back to the root causes of your friend’s problem:
>
> * How come they lost their persistent Thunderbird settings? Do you think it was Bug #10976 or something else? I would be curious in analyzing this further. Sending unencrypted emails by mistake shouldn’t happen and might also happen to people who didn’t loose their persistence settings. But persistence settings should also not disappear for no reason and if they hadn’t, your friend would have been safe.

It was not Bug #10976, because this only affected Thunderbird (and definitely not GnuPG, which would also have been affected by Bug #10976). It happened twice within a few months. And I would also like to analyze this further, but I don’t know how. I could ask for a look at the Tails device, but I don’t really expect to find anything.

> * Your friend sent an unencrypted email without noticing. Enigmail did some work in 2.0.7 to make the status of the outgoing email more visible. Maybe that would have helped your friend. I personally enable “Always confirm” on all my machines.

Same here, and I always recommend that to everyone.

> Maybe we should consider doing this in Tails by default, or set it to “If unencrypted” (and let people who are annoyed by it disable it).

That would be great, and was actually my first idea for how to prevent this from happening again, but unfortunately the setting is not honored if the enigmail is not enabled :/

> We could search for upstream discussions regarding the default setting which is “Never”. Note that this setting doesn’t apply until Enigmail is enabled so your point still applies. But if your friend had been used to clicking through the confirmation dialog, he might have noticed that his email was unencrypted (and maybe only have sent one unencrypted email instead of several).

They do usually have this setting activated, and they did notice immediately that the email was sent unencrypted, because the dialog was missing. But that was too late, the whole quoted email thread was leaked. I think that in fact, if they were not used to this dialog popping up every time they send an email, maybe they would have been more careful before hitting send.

>
> Regarding what you proposed, I’m of course worried about single drop of added complexity and possible confusion that we are pushing to non-Enigmail user. I don’t have any stats on how much of our user base uses Enigmail in Tails, but I’d rather consider OpenPGP a tool that only a minority of our user base can use (at least the user base I’m interested in seeing adopting Tails).
>
> During my tests in Tails 3.8 I didn’t see the error message that you put in attachment displayed to me by default. But the Enigmail icons in the email composition window were different: they had a red cross instead of being deactivated. Clicking on the red cross would show me the error message that you are referring to. Sorry, I lost the screenshots I prepared while shutting down my test machine :(

That is exactly what I experienced and what intrigeri meant too, I think. To clarify the confusion, I think this is what intrigeri meant:

“the email composition window gets an icon in the toolbar to sign email, and then [when activating signing via the toolbar] of course sending email fails because there’s no secret key with which the message can be signed.”

> Putting myself in the shoes of somebody who doesn’t even know that OpenPGP is and innocently clicks on the scary red cross in their composition windows, I wouldn’t understand that message: “What is this OpenPGP thingie? Am I shooting myself in the foot if I send my email with that red cross on? How do I get it off?”

I understand that.

> So could it be possible to:
>
> * Only enable Enigmail automatically if we detect an OpenPGP secret key in “~/.gnupg”?
> * Or make sure that people go through the Enigmail Setup Wizard if they have some OpenPGP secret key?
>
> If not, then I’m probably against this proposal.

Before spending more time investigating, I would like to know whether from now on this Enigmail setup wizard will always open when Thunderbird is started for the first time (i.e. started if there is no Thunderbird config, which I assume would have been the case in the reported situation). Because this was not the case before Tails 3.8, and I guess this would already be good enough, because it’s a reminder to set up enigmail.

intrigeri: since you implemented and tested the move to Enigmail 2.X, I guess you can easily answer whether the setup wizard will from now on always open automatically when Thunderbird is started for the first time.

#8 Updated by intrigeri 2018-07-06 08:32:02

• Assignee changed from intrigeri to segfault

> Before spending more time investigating, I would like to know whether from now on this Enigmail setup wizard will always open when Thunderbird is started for the first time (i.e. started if there is no Thunderbird config, which I assume would have been the case in the reported situation).

IIRC yes, now it’ll open at the end of the initial account creation process. To double-check, test with an ISO built from current stable or devel branch :)

#9 Updated by sajolida 2018-07-19 18:06:01

• related to Bug #15602: Fix EFAIL added

#10 Updated by sajolida 2018-07-19 18:06:07

• related to Feature #10436: Consider disabling the Enigmail wizard on first start added

#12 Updated by sajolida 2018-07-19 18:08:29

• Assignee changed from segfault to intrigeri
• QA Check set to Info Needed

#14 Updated by intrigeri 2018-07-22 02:08:27

• related to Bug #15746: Don't display the Enigmail setup wizard by default when starting Thunderbird added

#15 Updated by intrigeri 2018-07-22 02:11:35

• Assignee changed from intrigeri to sajolida
• QA Check deleted (Info Needed)

sajolida wrote:
> intrigeri, as the assignee of Bug #15602, can make sure this won’t be in 3.9?

I’ll try. I’ve filed Bug #15746 to track this. Now:

• I think the wizard will still show up on first Thunderbird launch after upgrading to a Tails version that upgrades Enigmail. I don’t think we can easily make this conditional to “already having configured Enigmail in the past”. I’ll investigate, see you on Bug #15746.
• The FT is awfully busy with MUST DO tasks until the 3.9 freeze so I can’t guarantee this will make it. Perhaps as a bugfix after the freeze.

#16 Updated by sajolida 2018-08-06 18:44:06

• Target version set to Tails_3.9

#17 Updated by intrigeri 2018-09-05 16:27:02

• Target version changed from Tails_3.9 to Tails_3.10.1

#18 Updated by sajolida 2018-09-18 03:12:24

• Subject changed from Consider enabling Enigmail by default to Consider enabling Enigmail by default if a GnuPG secret key is detected
• Assignee deleted (sajolida)
• Target version deleted (Tails_3.10.1)
• Type of work changed from Research to Code

In Tails 3.9, Enigmail is not enabled by default when configuring a first account and the Enigmail wizard is not shown. I think that’s good.

We’re left with the new idea that came from this discussion: enabling Enigmail automatically if a GnuPG secret key is detected. Renaming this ticket accordingly and marking it as Code.

If someone wants to work on this, please get a good understanding of the discussion and maybe propose a technical solution that seems feasible before implementing it. I’ll be happy to review a more detailed proposal before it gets implemented.

Note that I think it’s fine to enable Enigmail by default if we detect any GnuPG secret key, whether or not it corresponds to the email account in Thunderbird. People who have a GnuPG secret key should be fine ignoring the Enigmail wizard if it doesn’t make sense for them.

#19 Updated by sajolida 2018-09-18 03:12:34

• blocked by deleted (Feature #15392: Core work 2018Q2 → 2018Q3: User experience)

#20 Updated by intrigeri 2018-09-18 07:52:51

• Subject changed from Consider enabling Enigmail by default if a GnuPG secret key is detected to Enable Enigmail by default if a GnuPG secret key is detected
• Priority changed from Normal to Low