Join GitHub today
PGP-encrypt drafts #2107
Follow-up of #711.
The fix not to upload drafts of mails, which could later be sent PGP-encrypted is a good easy fix, but it is not really the best one.
User story: As a user I'd like to begin writing my PGP-encrypted mails in K9 mail and finish in another mail client & vice versa.
To make this work, K9 mail should encrypt (all?) drafts (or at least the drafts of later PGP-encrypted messages) with your own key and do upload them. As they are encrypted this is no issue and a user can easily continue to write the mail.
referenced this issue
Jan 21, 2017
For that reason, I would suggest mirroring Enigmail and using MIME. Since it is not the final version to be sent (it must be decrypted and then possibly re-encrypted with the recipient's public encryption key), there is no reason not to. K-9 doesn't have the memory hole (protected headers) yet, but there are at least specifications for memory hole in MIME at the moment. Less room for error as well.
I'm conflicted on whether to make this opt-in or opt-out. I don't want people to realize their draft is unreadable when they check their webmail on a friend's computer, but I also don't want K-9 to store unencrypted drafts of sensitive information that are destined for encryption of some sort when sent. As a matter of fact, it is even possible the user may do some other non-PGP encryption later (copy-paste text into a symmetric encoder, or use S/MIME).
On the whole, leaking sensitive information in drafts is a huge deal and a source of grief for Tails until it switched to Thunderbird/Enigmail. I think server-side encryption of drafts should be the default (if the user has private en/decryption keys on the phone linked to that e-mail account). Maybe there could be some sort of subtle alert? I can't shake the thought of what Moxie Marlinspike would say. His word is not gospel, but he has made very good points at making stuff accessible and not unnecessarily scaring users. No one using a perfect system is less desirable than many people using an imperfect one.
So the developers should weigh which of the following options has more fallout.
I advocate no. 2, but I wonder what others' thoughts are.
I'd propose this two versions:
Then we could offer one additional checkbox for "encrypt all my drafts", which is only available if the previous option for uploading potential PGP mail drafts is enabled.
@dllud "Potential PGP emails" is a great term, so we talk about "Potential PGP emails drafts" here.
Well, the unsent e-mails are even more valuable than the sent e-mails, if you consider your mail service provider spying against you or a data leak in your threat model. It's inconsistent to refuse unsigned encrypted messages somewhere else and leak the plain text message at every step. If you want to protect the user from shooting themselves in the foot, you should do it everywhere. Otherwise it just creates a false sense of security.
There should at least be a warning here.
Hi, sorry, but it is unclear to me what is the status of this in latest version. Does K-9 still store unencrypted drafts?
Yeah now that the encryption semantics changed a bit, might be time to revisit this.
So the simple part is that when encryption is enabled, drafts must be encrypted. My intuition for others would be to have a setting "Encrypt all drafts" that toggles whether messages for which encryption isn't enabled will also be encrypted. The only remaining question then is whether to do that by default?
Unfortunately it's very hard to tell what's "potentially" encrypted, and ideally there should be no surprises in this behavior. So I'd rather go by more simple criteria than the availability of keys for recipients or anything like that.
actually, there are three viable modes: