Project

General

Profile

Feature #16477

Re-enable autocrypt

Added by hefee 9 months ago. Updated 11 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
02/21/2019
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Email Client

Description

As we had wired issues with Autocrypt we decided within Tails 3.11 to disable Autocrypt for our users (#15923). It leads our users to communicate unencrypted.

Let's wait for some time and than recheck again, if Autocrypt is good enough for our needs.

So far, what we are missing:
  • If the user already encrypt communication with an other one, this should never fallback to unencrypted communication, when enabling Autocrypt.
  • "encrypt messages by default" should not been overwritten by Autocrypt.
  • Tails enable "Prefer encrypted emails from the people you exchange email with." to hint Autocrypt to use Encryption.

Related issues

Related to Tails - Feature #15923: Autocrypt forces unencrypted messages Resolved 12/03/2018
Related to Tails - Feature #16531: Define our core code base In Progress 03/05/2019
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed
Blocked by Tails - Feature #17147: Migrate from Enigmail to Thunderbird 78's built-in OpenPGP support Confirmed

History

#1 Updated by hefee 9 months ago

  • Related to Feature #15923: Autocrypt forces unencrypted messages added

#2 Updated by intrigeri 9 months ago

  • Status changed from New to Confirmed

#3 Updated by intrigeri 3 months ago

  • Target version deleted (Tails_3.16)

I'll let whoever commits to work on this set the target version they think is realistic.

#4 Updated by hefee about 1 month ago

#5 Updated by hefee about 1 month ago

  • Assignee set to hefee
  • Target version set to Tails_4.1

That weekend there was the OpenPGP email summit and I had a short chat with dkg, holger and Patrick and all told me that Autocrypt should now work for our usecase. So it is time to reevaluate.

#6 Updated by intrigeri about 1 month ago

#7 Updated by intrigeri about 1 month ago

  • Related to Feature #17147: Migrate from Enigmail to Thunderbird 78's built-in OpenPGP support added

#8 Updated by intrigeri 12 days ago

Hi hefee!

Blocks Feature #16209: Core work: Foundations Team added

(Speaking with my "the person who manages the FT budget hat on.)

The only line of https://tails.boum.org/contribute/working_together/roles/foundations_team/ where I see why one may argue this ticket fits is "if time allows, do whatever code task the project sees as top-priority, such as fixing Holes in the Roof, important bugs, or implementing a feature that is needed to keep Tails relevant". I find it quite debatable.

Personally, given the future of Enigmail is unclear at best (#17147), I find it hard to justify investing Tails resources (core work) now into enabling this Enigmail feature.

So, let me ask: why do you think this is FT work?

#9 Updated by hefee 11 days ago

intrigeri wrote:

(Speaking with my "the person who manages the FT budget hat on.)

The only line of https://tails.boum.org/contribute/working_together/roles/foundations_team/ where I see why one may argue this ticket fits is "if time allows, do whatever code task the project sees as top-priority, such as fixing Holes in the Roof, important bugs, or implementing a feature that is needed to keep Tails relevant". I find it quite debatable.

So, let me ask: why do you think this is FT work?

I think it is FT work, because we Autocrypt makes using encrypted mails a lot easier if it works like expected. At least for Chris (https://tails.boum.org/contribute/personas/cris/) this is reason "struggles with technology".

Personally, given the future of Enigmail is unclear at best (#17147), I find it hard to justify investing Tails resources (core work) now into enabling this Enigmail feature.

That is a reason, to not invest time, and hard to argue against. Maybe you are right and we should postpone it, after we solved the Tunderbird 78.

#10 Updated by hefee 11 days ago

  • Related to deleted (Feature #17147: Migrate from Enigmail to Thunderbird 78's built-in OpenPGP support)

#11 Updated by hefee 11 days ago

  • Blocked by Feature #17147: Migrate from Enigmail to Thunderbird 78's built-in OpenPGP support added

#12 Updated by hefee 11 days ago

  • Assignee changed from hefee to intrigeri
  • Target version deleted (Tails_4.1)

Assign to intrigeri to deside, if it is FT work.

#13 Updated by intrigeri 11 days ago

  • Assignee deleted (intrigeri)

Hi hefee!

First, it's not often that we need to discuss whether X or Y is FT work: most problems the FT deals with are much more clear-cut in this respect than this one. So we currently lack a known-working process and culture to make such decisions. I see this ticket as an experiment. As such, I'm sure I'll make mistakes and write awkward stuff. Please bear with me during this learning process.

Indeed, it may be that Cris uses OpenPGP for email: the description reads "Uses phone messaging to contact sources and partners" but one could argue that if OpenPGP was more usable, Cris would perhaps use it. Thanks for looking at the personas, I myself forgot, again!

I don't feel comfortable deciding alone whether this is FT work:

  • Even for maintenance (keeping existing OpenPGP stuff working), I sometimes find it hard to justify spending so much time into it myself: I always wonder whether I could make a bigger difference if I instead worked on something that will improve Tails for more users.
  • The only line of our mission where this new feature could possibly fit is about tasks that "the project sees as top-priority"; I'm not the project and I don't think that representing the project would fit well into my FT lead non-existing job description.

So personally, I'd like us (via #16531) to clarify collectively how much OpenPGP is a priority for Tails. We could certainly do this now, but I see a big risk that #17147 obsoletes any cost/benefit analysis that we would do now, so I'm inclined to wait for #17147 and then we'll be able to discuss this with a better idea of what we can support and how much work it takes. But if you prefer to initiate this part of #16531 without waiting, I'm totally fine with that too!

Also available in: Atom PDF