Project

General

Profile

Feature #13649

Decide what to do with Memory Hole in Thunderbird

Added by anonym 2 months ago. Updated 16 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
08/18/2017
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Discuss
Blueprint:
Easy:
Affected tool:
Email Client

Description

By installing Enigmail we get the Memory Hole feature, which is disabled by default (presumably since it's still experimental and not widely supported). However, TorBirdy 2.3 (not in Debian as of writing this) enables this feature in Enigmail, so before we upgrade TorBirdy we have to decide whether we want to enable this.

Memory Hole degrades UX significantly if you are a recipient without support for it: all such emails will have the subject "Encrypted Message" and will lack threading (due to dropped "In-Reply-To"). So, in practice (given that very few clients support Memory Hole) this means that Tails users will be a PITA for the vast majority of non-Tails users.

I think we should proactively disable it by setting

user_pref("extensions.torbirdy.custom.extensions.enigmail.protectHeaders", false);

History

#1 Updated by bertagaz 2 months ago

anonym wrote:

I think we should proactively disable it by setting
[...]

I agree! But we may also want to document how to set it back.

#2 Updated by spriver 2 months ago

I'd like to have this implemented (as I also fell over this bug in plain Debian and got annoyed by it). I also like bertagaz' idea of documenting how to switch back to the default, we already have a section "OpenPGP encryption with Enigmail" in the documentation of Thunderbird, this could fit in there IMHO.

#3 Updated by intrigeri 2 months ago

bertagaz wrote:

anonym wrote:

I think we should proactively disable it by setting
[...]

I agree!

+1

Now, I love the Memory Hole idea and I appreciate TorBirdy is proactively trying to push it forward. I would love to see us be part of those who help make it happen on the long-term, rather than on the side of those who de facto block it. This part of the discussion is not a blocker for applying the proposed change, and it might require another ticket. For now I'll start here. One way we could do it is to announce that we'll enable Memory Hole by default in Tails at $DATE, as a way to encourage MUA authors to add support for it. This should probably be coordinated with the Memory Hole community/authors' strategy and timeline. E.g. there's little chance that MUAs shipped in GNU/Linux LTS/stable releases will get Memory Hole support before the next release of said LTS, so I guess our deadline can't realistically be before the Buster release + a couple months, i.e. in two years. Thoughts, opinions? dkg, what do you think?

But we may also want to document how to set it back.

I see no particular reason why we should document this specific opt-in (currently obscure) feature more than thousands of other opt-in features in software we ship, so I strongly believe this should not be a blocker.

#4 Updated by sajolida 2 months ago

  • Subject changed from Decide what to do with Mail Hole in Thunderbird to Decide what to do with Memory Hole in Thunderbird

#5 Updated by u 2 months ago

As I will prepare the Torbirdy package for Debian, don't you think we should simply add the pref to the Debian package directly?

#6 Updated by anonym about 2 months ago

u wrote:

As I will prepare the Torbirdy package for Debian, don't you think we should simply add the pref to the Debian package directly?

I would argue so, but it's worth noting that dkg disagrees: https://github.com/ioerror/torbirdy/issues/33

#7 Updated by anonym about 2 months ago

I created a ticket on the dead upstream tracker which I'll summarize here:

anonym wrote:

dkg wrote:

anonym wrote:

TorBirdy 2.3 sets `extensions.enigmail.protectHeaders = true`, enabling Mail Hole for all sent emails. However, Mail Hole significantly degrades UX for non-Mail Hole recipients, for example by setting a static subject ("Encrypted Message") and breaking threading by dropping In-Reply-To.

I am surprised to hear that the initial implementation of memory-hole drops either In-Reply-To: or References: header. Has anyone reported that as a problem upstream?

When Memory Hole is enabled I think protecting In-Reply-To and References makes sense since those otherwise would leak thread activity. So not a bug/problem IMHO.

setting the static subject (and having the actual subject inside the
e-mail, viewable by non-memory-hole clients) is a clear improvement,
not a degradation. Please don't drop that advancement in torbirdy.

I agree that Memory Hole is a huge improvement, but only when all participants use it. Those that lack support will unquestionably have a worse UX given the loss of Subject and threading. Or am I missing something? If not, then I argue that we should wait until Memory Hole support is more wide-spread; I fear enabling it now will be counter productive given that it makes OpenPGP even more inconvenient to use and adopt than it already is. (Case in point: we've already had some inconvenience within the Tails project, and if us cryptonerds have problems, I think it's safe to assume average users will as well.)

#8 Updated by u about 1 month ago

I have pretty good news! I just prepared the new Torbirdy Debian package 0.2.3-1.
This is the release that enables Memory Hole by default. With enigmail from Debian Stretch, currently 2:1.9.8.1-1~deb9u, my email subjects get correctly decrypted. I briefly see "Encrypted message", then I see the subject. So, my understanding right now is, that it is safe to enable this, at least in Debian. As for threading: this is unfortunately broken and I will report this upstream (dkg/enigmail/Thunderbird).
And with Schleuder it's totally broken, so I'll check if there is already a bug report upstream or not for this.

An option would be to disable Memory Hole in a Stretch backport or in Tails directly by disabling this preference.

This would allow to the aforementioned software developers (Schleuder, enigmail, Thunderbird) to have a bit more time to try to fix this before we ship it to users.

What do you think?

#9 Updated by u about 1 month ago

Update on Memory Hole in Schleuder: https://0xacab.org/schleuder/schleuder/issues/74 there are plans to implement it and I've asked for a timeline on their tracker.

#10 Updated by u about 1 month ago

Now, concerning the threading, I've created a threaded answer and in the encrypted part of my email, the headers persist:

Content-Type: multipart/mixed; boundary="o71DpCxQ3qQLbEQs9dFKIufk05I12fXSw";
 protected-headers="v1" 
From: u <u @example.org>
To: u <u @example.org>
Message-ID: <151efb5d-02fe-7c96-53b2-f9bfcac39a3f@example.org>
Subject: Re: test
References: <6d423892-5a60-9a71-db42-662dcaa78ac3@example.org>
In-Reply-To: <6d423892-5a60-9a71-db42-662dcaa78ac3@example.org>

I'm a bit lost concerning which part of the setup is not able to show me threaded emails, is it Enigmail's or Thunderbird's fault? I've just sent an email to dkg, anonym & Sukhbir to ask for their insight so that I can report this somewhere.

#11 Updated by intrigeri about 1 month ago

I have pretty good news! I just prepared the new Torbirdy Debian package 0.2.3-1. This is the release that enables Memory Hole by default. With enigmail from Debian Stretch, currently 2:1.9.8.1-1~deb9u, my email subjects get correctly decrypted. I briefly see "Encrypted message", then I see the subject.

Excellent, thanks for testing! I assume this works even with current torbirdy/stable, right? (IIRC Torbirdy merely enables a pref, it doesn't ship the Memory Hole code itself.)

So, my understanding right now is, that it is safe to enable this, at least in Debian.

Agreed.

I'll paste here the reasoning that lead me to the same conclusion (everywhere I've written "MUA" bellow, things apply to "encrypted mailing list software" as well):

My reasoning was that there must be some kind of wake up call for authors and users of MUAs, that states that after $DEADLINE, all the MUAs that support Memory Hole will enable it by default for outgoing email. And then these people have time to write the needed code or switch to a different MUA. The problem is, there's no way to reach out to all these people easily (the devs can probably be reached, but I dunno how to write to all users of $MUA). The problem with my reasoning is that it's very nice in theory, but not applicable in practice. So in some way enabling the thing in Torbirdy is perhaps the best wake up call one can send. It tells a number of innocent bystanders (like me) that they should switch to another MUA or improve the one they use. Then at a smaller scale (e.g. the Tails community) we can hear this wake up call and set our own deadline internally, after which it'll be OK to send Memory Hole -enabled email. I dunno if the Memory Hole people reached out to MUA developers or not, so I'm not in a good position to tell if MUA devs have had enough time to react or not.

An option would be to disable Memory Hole in a Stretch backport or in Tails directly by disabling this preference.

Wrt. Stretch backports: Torbidy is not there yet, and I don't know if/when/why we'll need it there, so let's postpone this. Hopefully we'll have clarified our thoughts & plans then :)

Wrt. Tails: as long as we stick to torbirdy/stable, we're not affected. But I think we should be proactive and explicitly disable the pref now, so we don't forget about it whenever we upgrade to Torbirdy 0.2.3 or newer for a totally unrelated reason (such as… switching to Debian testing :)

#12 Updated by u about 1 month ago

intrigeri wrote:

I have pretty good news! I just prepared the new Torbirdy Debian package 0.2.3-1. This is the release that enables Memory Hole by default. With enigmail from Debian Stretch, currently 2:1.9.8.1-1~deb9u, my email subjects get correctly decrypted. I briefly see "Encrypted message", then I see the subject.

Excellent, thanks for testing! I assume this works even with current torbirdy/stable, right? (IIRC Torbirdy merely enables a pref, it doesn't ship the Memory Hole code itself.)

Absolutely.

An option would be to disable Memory Hole in a Stretch backport or in Tails directly by disabling this preference.

Wrt. Stretch backports: Torbidy is not there yet, and I don't know if/when/why we'll need it there, so let's postpone this. Hopefully we'll have clarified our thoughts & plans then :)

Since I've uploaded a new version of Torbirdy today, we're not that far from a backport for Stretch :)

Wrt. Tails: as long as we stick to torbirdy/stable, we're not affected. But I think we should be proactive and explicitly disable the pref now, so we don't forget about it whenever we upgrade to Torbirdy 0.2.3 or newer for a totally unrelated reason (such as… switching to Debian testing :)

I think I should disable it in the backport directly.

I also created a page on the Debian Wiki, just in case people want to disable it manually: https://wiki.debian.org/TorBirdy

#13 Updated by anonym about 1 month ago

intrigeri wrote:

My reasoning was that there must be some kind of wake up call for authors and users of MUAs [...]

I completely agree that this has to happen at some point. But I don't think now is the correct time. Memory Hole does not even have a full specification: the current draft doesn't even say what do do with In-Reply-To/References. Given this I have very little trust in this "wake up call" strategy ending up with good results.

#14 Updated by u 16 days ago

I discussed this a bit with intrigeri. What I did in the meantime is upload the new Torbirdy version to Debian, not disabling memory hole. I will not create a backport for Stretch so Tails will now continue to use the stable version.

However, we could in Tails use the version from testing and disable Memory Hole in Tails at least until more MUAs implement it.

Also available in: Atom PDF