Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #28493

Closed
Open
Opened Nov 17, 2018 by intrigeri@intrigeri

Stop forcibly enabling protected headers (aka. Memory Hole) by default

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 (closed) 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.

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

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

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#28493