Feature #16477

Re-enable Autocrypt

Added by hefee 2019-02-21 17:58:48 . Updated 2020-05-12 13:08:51 .

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

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

As we had weird issues with Autocrypt:https://en.wikipedia.org/wiki/Autocrypt we decided within Tails 3.11 to disable Autocrypt for our users (Feature #15923). It lead 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.

Subtasks

Related issues

Related to Tails - Feature #15923: Autocrypt forces unencrypted messages Resolved 2018-12-03
Related to Tails - Feature #16531: Define our core code base In Progress 2019-03-05
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 2019-02-21 17:59:18

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

#2 Updated by intrigeri 2019-03-10 16:37:20

  • Status changed from New to Confirmed

#3 Updated by intrigeri 2019-08-30 16:20:14

  • 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 2019-10-16 15:19:30

#5 Updated by hefee 2019-10-16 15:21:10

  • 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 2019-10-17 10:58:27

#7 Updated by intrigeri 2019-10-17 11:00:00

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

#8 Updated by intrigeri 2019-11-10 18:08:34

Hi hefee!

> Blocks Feature 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 (Feature #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 2019-11-11 16:23:04

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 (Feature #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 2019-11-11 16:23:20

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

#11 Updated by hefee 2019-11-11 16:23:35

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

#12 Updated by hefee 2019-11-11 16:25:05

  • 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 2019-11-11 17:02:47

  • 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 Feature #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 Feature #17147 obsoletes any cost/benefit analysis that we would do now, so I’m inclined to wait for Feature #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 Feature #16531 without waiting, I’m totally fine with that too!

#14 Updated by intrigeri 2020-05-12 13:08:20

  • Subject changed from Re-enable autocrypt to Re-enable Autocrypt
  • Description updated

#15 Updated by intrigeri 2020-05-12 13:08:51

  • Description updated