[tor-bugs] #28493 [Applications/TorBirdy]: Stop forcibly enabling protected headers (aka. Memory Hole) by default

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#28493: Stop forcibly enabling protected headers (aka. Memory Hole) by default
---------------------------------------+---------------------
     Reporter:  intrigeri              |      Owner:  sukhbir
         Type:  defect                 |     Status:  new
     Priority:  Medium                 |  Milestone:
    Component:  Applications/TorBirdy  |    Version:
     Severity:  Normal                 |   Keywords:
Actual Points:                         |  Parent ID:
       Points:                         |   Reviewer:
      Sponsor:                         |
---------------------------------------+---------------------
 Let's move the discussion from
 https://github.com/ioerror/torbirdy/issues/33 here.

 I have three new arguments in favour of not Torbirdy not touching this
 pref anymore:

 1. Enigmail now makes this feature visible to users in a better place

 My understanding is that when #21880 was implemented, this feature was
 hidden behind a hidden pref so from the Torbirdy PoV, the simplest way to
 make it available to the masses was to do add UI in the Torbirdy prefs,
 but since most users won't go in the prefs to enable it, it was decided to
 enable it by default. Nowadays, things are very different: Enigmail itself
 prompts the user wrt. whether this pref should be enabled, so they get to
 choose; and it has UI to toggle it on/off. So it seems to me that the main
 reason that justifies why Torbirdy took ownership of this pref is gone.

 Besides, having to go to the Torbirdy settings to change this pref is
 confusing: protected headers only make sense with encrypted email, so it
 makes sense that they're configurable via the Enigmail settings. Adding
 one more layer of indirection is bound to cause user confusion, and
 indeed, since 1+ year I've seen lots of Enigmail+Torbirdy users wondering
 why protected headers come back enabled after they've disabled it in the
 Enigmail prefs.

 2. The corresponding code in Torbirdy seems to be unmaintained

 The corresponding pref was renamed in Enigmail and its type changed in
 Enigmail 2.0. It seems that Torbirdy was not updated accordingly.

 3. The strategy and timeline for protected headers adoption is unclear

 Protected headers are currently a big pain for every email recipient,
 unless they use Thunderbird + Enigmail or K9. At Tails we would like to
 enable protected headers ASAP so our plan was to do some social media
 propaganda, announcing we would enable it at $DATE, and encouraging email
 client authors to support protected headers. But the Memory Hole spec is
 currently not good enough for us to point software developers to, and the
 timeline for updating it is unclear. For details, see
 https://redmine.tails.boum.org/code/issues/13649 and the email discussions
 linked from there. I also hope that at some point, the critical mass of
 users who send email with protected headers encourages email client
 authors to add such support, but this has not happened yet and I don't see
 it happening any time soon.

 So all in all, my current position is that Torbirdy should stop
 interfering: it should let Enigmail do its thing (which it does pretty
 nicely) wrt. communicating to the user that this feature exists, and
 providing UI to toggle it on/off as desired.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28493>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs