Project

General

Profile

Feature #16299

Feature #15923: Autocrypt forces unencrypted messages

Disable Autocrypt even for existing persistent Thunderbird profiles

Added by sajolida 5 months ago. Updated 3 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
01/14/2019
Due date:
% Done:

100%

QA Check:
Feature Branch:
hefee/bugfix/16186-disable-autocrypt+force-all-tests
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Email Client

Description

See #16223#note-7: people who upgraded through 3.10 will still have Autocrypt enabled and might send unencrypted emails unwillingly.

We could have a migration script that automatically applies the default configuration from Autocrypt 3.11 (Autocrypt disabled + acPreferEncrypt) when we detect the configuration we had in 3.10 (Autocrypt enabled + no acPreferEncrypt).

We could keep this migration script around during some release cycles and document that if people want to enable Autocrypt they have to enable acPreferEncrypt to avoid triggering the migration script.


Subtasks

Feature #16359: UX for users that have Autocrypt enabledRejected


Related issues

Related to Tails - Feature #16223: Document Autocrypt Confirmed 12/13/2018
Related to Tails - Bug #16186: Disable Autocrypt by default Resolved 12/03/2018
Blocks Tails - Feature #15507: Core work 2019Q1: Foundations Team Resolved 04/08/2018

Associated revisions

Revision 14eaaaf5 (diff)
Added by Sandro Knauß 4 months ago

Ask for disable Autocrypt for existing accounts (refs: #16299)

We shipped thunderbird with Autocrypt enabled by default. As Tails we do
not recommend to use Autocrypt by default at the moment. Ask the user,
what they want to do abut Autocrypt.

Revision 10cac4db (diff)
Added by Sandro Knauß 4 months ago

Ask for disable Autocrypt for existing accounts (refs: #16299)

We shipped thunderbird with Autocrypt enabled by default. As Tails we do
not recommend to use Autocrypt by default at the moment. Ask the user,
what they want to do abut Autocrypt.

Revision a2bb3bf0 (diff)
Added by Sandro Knauß 4 months ago

Ask for disable Autocrypt for existing accounts (refs: #16299)

We shipped thunderbird with Autocrypt enabled by default. As Tails we do
not recommend to use Autocrypt by default at the moment. Ask the user,
what they want to do abut Autocrypt.

Revision 02fbe5ea (diff)
Added by intrigeri 4 months ago

Revert "Ask for disable Autocrypt for existing accounts (refs: #16299)"

At this point it's unclear whether there's a problem to solve
(https://redmine.tails.boum.org/code/issues/16299#note-20)
and if there's one, whether this is the best way to solve it
(https://redmine.tails.boum.org/code/issues/16299#note-19).

This reverts commit a2bb3bf0df2917193f345ffec0e130c77ac6ca3a.

History

#1 Updated by sajolida 5 months ago

#2 Updated by sajolida 5 months ago

#3 Updated by sajolida 5 months ago

  • Related to Bug #16186: Disable Autocrypt by default added

#4 Updated by sajolida 5 months ago

#5 Updated by hefee 5 months ago

  • Status changed from New to Confirmed
  • Target version set to Tails_3.12

Properly won't make it for within the Tails 3.12 cycle. AS it must be written with ~10 days, and the plate is already quite full.

#6 Updated by intrigeri 4 months ago

  • Parent task set to #15923

#7 Updated by intrigeri 4 months ago

#8 Updated by intrigeri 4 months ago

  • Subject changed from Disable Autocrypt if configuration from 3.10 is detected to Disable Autocrypt even for existing persistent Thunderbird profiles
  • Assignee set to hefee
  • Priority changed from Normal to Elevated
  • Start date changed from 01/05/2019 to 07/05/2019

So, my understanding is that the fix for #16186 was incomplete: our intent there was to disable Autocrypt even for existing, persistent Thunderbird profiles. So I'm setting priority to the same as #16186, i.e. >> normal, because this is a pretty serious bug that we've been carrying for 4 months. It would be really nice to fix this in 3.12. hefee, if you have time for FT work until the freeze, I suggest this may be higher priority than other tasks; happy to help you prioritize if you need to postpone something.

Now, I don't understand why that fix is not sufficient: doesn't 929c9cb6c88e1ca424dd80e1f7c998a06bebc538 set the correct pref every time Thunderbird starts, regardless of what value might have been persisted in the past?

#9 Updated by hefee 4 months ago

intrigeri wrote:

Now, I don't understand why that fix is not sufficient: doesn't 929c9cb6c88e1ca424dd80e1f7c998a06bebc538 set the correct pref every time Thunderbird starts, regardless of what value might have been persisted in the past?

The issue here is, that we can only set the pref for:
mail.server.default.enableAutocrypt

But Thunderbird will create for every server an copy of this:
mail.server.server1.enableAutocrypt, mail.server.server2.enableAutocrypt etc.

and those get written even, if they do not differ from the default. To catch them, we need to search for those entries and modify them.

#10 Updated by intrigeri 4 months ago

The issue here is, that we can only set the pref for:
mail.server.default.enableAutocrypt

But Thunderbird will create for every server an copy of this:
mail.server.server1.enableAutocrypt, mail.server.server2.enableAutocrypt etc.

and those get written even, if they do not differ from the default. To catch them, we need to search for those entries and modify them.

Got it, thanks!

#11 Updated by Anonymous 4 months ago

  • Status changed from Confirmed to In Progress

#12 Updated by hefee 4 months ago

  • Feature Branch set to hefee/bugfix/16186-disable-autocrypt+force-all-tests

#13 Updated by hefee 4 months ago

  • QA Check set to Ready for QA
Tests done on vm by hand:
  • register a new account, make sure that Autocrypt is disabled by default.
  • enable Autocrypt
  • restart Thunderbird - a dialog is presented to disable Autocrypt
  • added a second account with Autocrypt enabled, too
  • restart Thunderbird
  • made sure that the dialog is ask for both accounts
  • if "Disable Autocrypt" is used, checked the Autocrypt status was disabled afterwards.

I bundled #15661, #16299, #15657 and #16222, as a new enigmail version and a new torbirdy version made sense to test together.

#14 Updated by intrigeri 4 months ago

  • Assignee changed from hefee to intrigeri

#15 Updated by intrigeri 4 months ago

  • Assignee changed from intrigeri to hefee
  • QA Check changed from Ready for QA to Dev Needed

Wrt. 14eaaaf5bf18df93c800c5eb627430a275d88ebe:

  • The new user-facing strings need to go through sajolida (and a spell/grammar checker) ⇒ please coordinate with him. If this can't happen in time for the freeze: I think we can fix the strings between RC1 and 3.12 final.
  • I'm not sure that asking for every account separately is worth it. I would ask sajolida for UX input. OTOH it's probably a corner case so maybe not worth spending more time on it.
  • I think the default should be "Disable", i.e. go back to what we recommend. Most users have it enabled because of Tails' past default settings, not because they wanted it. If you agree, please go ahead. If you disagree, it will indicate we need sajolida's UX input.
  • We try hard to consistently use extended regexps (that are close to the most common PCRE), to avoid having to context switch all the time between different regexp languages, which is error prone ⇒ can you convert the sed command to --regexp-extended? And yeah, sorry for Tails not having a style guide that would make such expectations clear before you've spent time testing the current code :/
  • I'm not sure I understand what will happen if 1. a user chooses to keep Autocrypt enabled after upgrading to 3.12; 2. they upgrade to 3.13 and start Thunderbird. Will they get this prompt again? I guess we don't want that.

#16 Updated by hefee 4 months ago

intrigeri wrote:

Wrt. 14eaaaf5bf18df93c800c5eb627430a275d88ebe:

  • The new user-facing strings need to go through sajolida (and a spell/grammar checker) ⇒ please coordinate with him. If this can't happen in time for the freeze: I think we can fix the strings between RC1 and 3.12 final.
  • I'm not sure that asking for every account separately is worth it. I would ask sajolida for UX input. OTOH it's probably a corner case so maybe not worth spending more time on it.
  • I think the default should be "Disable", i.e. go back to what we recommend. Most users have it enabled because of Tails' past default settings, not because they wanted it. If you agree, please go ahead. If you disagree, it will indicate we need sajolida's UX input.

will do in a subtask.

  • We try hard to consistently use extended regexps (that are close to the most common PCRE), to avoid having to context switch all the time between different regexp languages, which is error prone ⇒ can you convert the sed command to --regexp-extended? And yeah, sorry for Tails not having a style guide that would make such expectations clear before you've spent time testing the current code :/

done

  • I'm not sure I understand what will happen if 1. a user chooses to keep Autocrypt enabled after upgrading to 3.12; 2. they upgrade to 3.13 and start Thunderbird. Will they get this prompt again? I guess we don't want that.

The user will be ask everytime they restart Thunderbird. It is not a great UX for users that want to use Autocrypt, as they have to answers the questions everytime.

#17 Updated by hefee 4 months ago

  • Assignee changed from hefee to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

#18 Updated by intrigeri 4 months ago

will do in a subtask.

Not sure if it's worth the additional paperwork.

The user will be ask everytime they restart Thunderbird. It is not a great UX for users that want to use Autocrypt, as they have to answers the questions everytime.

Ouch. I think I'd rather just drop the prompt and forcibly disable Autocrypt, instead of pretending we kinda support it with this poor UX.

#19 Updated by intrigeri 4 months ago

  • Assignee changed from intrigeri to sajolida
  • QA Check changed from Ready for QA to Info Needed
  • Type of work changed from Code to User interface design

First, thanks hefee for the work you've put into this branch: it will be used somehow, regardless of what we decide. It also raises important questions that we need to discuss.

hefee and I disagree wrt. what we should do here. In short:

  • hefee thinks it's not OK to change user settings without asking them first (hence his decision to implement something else than what sajolida requested).
  • I think these are default settings that most OpenPGP users don't know about, so they haven't consciously chosen to leave them as-is; and it's hard to ask the question in a way that's meaningful to users; I also think that given the current state of Autocrypt (when it fails, it fails in a too dangerous manner), asking every user to decide whether they want it does not make much sense.

It seems that our options are:

  • A) as sajolida proposed on this ticket initially, automatically switch existing profiles to the new default settings if we detect the user has left the old settings alone
    • pros: no need to design a dialog; sajolida proposed this so we can implement it without asking him to do more UX work
    • cons: needs some more code we don't have yet to detect previous default settings; optionally, needs some doc to explain how to opt-in for Autocrypt
  • B) forcibly disable Autocrypt
    • pros: no new code to write, no need to design a dialog
    • cons: user confusion if they enable Autocrypt in the GUI and it's disabled next time they start Thunderbird; can be slightly mitigated with documentation (or hiding the GUI option, it might be doable with CSS)
  • C) ask once users with an existing profile that has Autocrypt enabled whether they want to keep it enabled or switch to the new Tails default settings (i.e. disabled)
    • pros: we don't fiddle with settings users might have consciously decided they wanted even if they were the default settings
    • cons: needs UX design for the dialog; needs code to avoid asking the user every time they start Thunderbird; more code => more review work; more complex decision tree => more cases to test and more chances for bugs
  • D) status quo = leave existing profiles untouched
    • pros: no work to do
    • cons: users with an existing persistent profile are at risk due to Autocrypt support bugs

Personally, I'd rather see us spend our dev + UX resources on things that benefit more current and target users: OpenPGP is already somewhat of a corner case, so we're talking about a corner case of a corner case here (i.e. OpenPGP users who know they do want Autocrypt). My current preference is A > B > C > D… depending on our availability: if A is too much coding work, fall back to B.

The current state of the branch does not try to implement what sajolida asked on this ticket; instead, it is a partial implementation of C: it asks the user every time they start Thunderbird, as long as they've not disabled Autocrypt; the dialog has a few UX and language issues. I'm not convinced it is significantly better than the status quo; and if we think it's worth spending more time on this ticket, I'd rather see us spend it on A; and if we lack time, I'd rather see us do B than completing C.

So, questions for sajolida:

  • Do you think the current state of the branch better than the status quo? I've described its problems above. See 14eaaaf5bf18df93c800c5eb627430a275d88ebe for the new user-facing strings.
  • Do you feel we should spend more code + UX time on this? If yes, on which option?

I suggest we focus on what we want in 3.12 for now.

#20 Updated by intrigeri 4 months ago

  • Assignee changed from sajolida to hefee

Actually, I wonder if there's some confusion. I've installed 3.10.1, set up persistence, configured a Thunderbird email account, went through the Enigmail config wizard. I've then sent an email and I see it has an Autocrypt header, as expected. But contrary to what #16223#note-7 says, I see no pref saved in the user profile that would store the "Autocrypt is enabled" fact:

$ grep -i -E 'autocrypt|acprefer' .thunderbird/profile.default/*.js
user_pref("mailnews.headers.extraAddonHeaders", "autocrypt openpgp");

Then I've upgraded that system to 3.11, restarted Tails, started Thunderbird, wrote another email, quit Thunderbird, and:

$ grep -i -E 'acprefer|autocrypt' .thunderbird/profile.default/*.js
user_pref("mail.server.default.enableAutocrypt", false);
user_pref("mailnews.headers.extraAddonHeaders", "autocrypt openpgp");

Finally, I see the exact same result with a Tails of mine, where the Thunderbird profile was created years ago, manually upgraded to 3.6.1, incrementally upgraded since then to every version up to 3.11, and where I've used Thunderbird at least once per Tails release.

This seems to show that at least users migrating from default settings on a Thunderbird email account set up with 3.10.1 or older automatically get Autocrypt disabled by default after upgrading to 3.11, which is exactly what we want (and what I thought #16186 was about).

Did anyone have a different experience in practice?
hefee, do you remember what lead you to the opposite conclusion in #16223#note-7?
In other words, what exact problem are we trying to solve here?

If all releases up to 3.10.1 (inclusive) behaved like what I've seen, but still some users have prefs that enable Autocrypt in their persistent profile, then the question becomes: how did these prefs get added to the user prefs? Is there any other way this happened apart of explicit user choice? If our conclusion is "if these user prefs exist at all, it must be because the user opted-in for Autocrypt", then I don't think we need to write, review and maintain any migration code at all:

  • The code added in 3.11 is sufficient = option D = status quo.
  • We can document the drawbacks of Autocrypt if we want (#16223, low priority).

#21 Updated by hefee 4 months ago

intrigeri wrote:

Did anyone have a different experience in practice?

How we can get more data for this issue?

hefee, do you remember what lead you to the opposite conclusion in #16223#note-7?

Well I tested 3.10 a lot and tried out different things and there I got the impression, that this setting is written in anycase to the config per account. But maybe I played too much and look too less in settings file in between. I made a clean test and could not reproduce the behavior.

With this clean test IMO think option D=status quo is maybe okay.

#22 Updated by intrigeri 4 months ago

hefee wrote:

intrigeri wrote:

Did anyone have a different experience in practice?

How we can get more data for this issue?

We can ask help desk and Tails contributors (e.g. on tails-dev@ + XMPP).

hefee, do you remember what lead you to the opposite conclusion in #16223#note-7?

Well I tested 3.10 a lot and tried out different things and there I got the impression, that this setting is written in anycase to the config per account. But maybe I played too much and look too less in settings file in between. I made a clean test and could not reproduce the behavior.

OK, thanks for confirming!

With this clean test IMO think option D=status quo is maybe okay.

ACK. So I'll revert a2bb3bf0df2917193f345ffec0e130c77ac6ca3a when reviewing, testing and hopefully merging the topic branch for 3.12. No hurry IMO to debate about the "maybe okay" part, so feel free to postpone (if you want to discuss this further) or reject.

#23 Updated by anonym 4 months ago

  • Target version changed from Tails_3.12 to Tails_3.13

#24 Updated by hefee 3 months ago

  • Assignee changed from hefee to intrigeri
  • QA Check deleted (Info Needed)
  • Type of work changed from User interface design to Code

Okay as 3.12 is out now and we don't get any negative feedback about Autocrypt. And I have no used old Thunderbird profile to test an update. Those two points bring me to:

I'll would recommend to close this as solved and reopen it if we get other input.

I'll assign it at intri, as they are in chard to triage bugs/close not needed bugs etc.

#25 Updated by intrigeri 3 months ago

  • Status changed from In Progress to Rejected
  • Assignee deleted (intrigeri)

Agreed. Closing as rejected ("not a bug") rather than solved, because there's no indication that we had actually anything to solve here.

Also available in: Atom PDF