Tails

#1 Updated by sajolida 2019-01-05 18:17:04

• related to Feature #16223: Document Autocrypt added

#2 Updated by sajolida 2019-01-05 18:17:21

• related to Feature #16223: Document Autocrypt added

#3 Updated by sajolida 2019-01-05 18:17:38

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

#4 Updated by sajolida 2019-01-05 18:17:51

• related to deleted (Feature #16223: Document Autocrypt)

#5 Updated by hefee 2019-01-05 21:12:43

• 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 2019-01-12 08:56:24

• Parent task set to Feature #15923

#7 Updated by intrigeri 2019-01-12 08:56:38

• blocks Feature #15507: Core work 2019Q1: Foundations Team added

#8 Updated by intrigeri 2019-01-12 09:02:13

• 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 2019-01-05 to 2019-07-05

So, my understanding is that the fix for Bug #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 Bug #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 commit:929c9cb6c88e1ca424dd80e1f7c998a06bebc538 set the correct pref every time Thunderbird starts, regardless of what value might have been persisted in the past?

#11 Updated by Anonymous 2019-01-14 09:39:46

• Status changed from Confirmed to In Progress

Applied in changeset commit:tails|14eaaaf5bf18df93c800c5eb627430a275d88ebe.

#12 Updated by hefee 2019-01-14 09:44:20

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

#13 Updated by hefee 2019-01-14 10:43:02

• 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 Feature #15661, Feature #16299, Feature #15657 and Feature #16222, as a new enigmail version and a new torbirdy version made sense to test together.

#14 Updated by intrigeri 2019-01-14 10:54:51

• Assignee changed from hefee to intrigeri

#15 Updated by intrigeri 2019-01-14 11:49:14

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

Wrt. commit: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.

#17 Updated by hefee 2019-01-14 12:38:31

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

#19 Updated by intrigeri 2019-01-14 13:22:54

• 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 commit: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 2019-01-14 14:20:27

• 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 Feature #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 Bug #16186 was about).

Did anyone have a different experience in practice?
hefee, do you remember what lead you to the opposite conclusion in Feature #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 (Feature #16223, low priority).

#23 Updated by anonym 2019-01-30 11:59:34

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

#24 Updated by hefee 2019-02-08 15:37:22

• 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 2019-02-09 15:48:44

• 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.