New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PGP-encrypt drafts #2107

Open
rugk opened this Issue Jan 21, 2017 · 13 comments

Comments

Projects
None yet
7 participants
@rugk

rugk commented Jan 21, 2017

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.

@rugk

This comment has been minimized.

rugk commented Jan 21, 2017

Maybe make it configurable whether all drafts should be encrypted or only those of potential PGP mails.

@cketti cketti added the enhancement label Jan 22, 2017

@dllud

This comment has been minimized.

dllud commented Jan 28, 2017

Enigmail does this. It would be much handy.

@J-J-Chiarella

This comment has been minimized.

J-J-Chiarella commented Feb 5, 2017

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.

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.

  1. Have some notification that drafts will be stored in an encrypted form and may not be accessible from other computers without your private keys. Fallout: people panic. My e-mails were always accessible before! I don't want to ever encrypt anything in this message! Just store the draft unencrypted. It's an e-mail to my professor about lunch on Tuesday.

  2. Have no notification and people find out the hard way (if they were already unaware) that their drafts are not accessible in decrypted form when they check their webmail on another computer without a copy of their private keys. This may be okay, since people don't usually revisit drafts on multiple devices. I'll attach some files to an e-mail and write an introduction, then leave my house for a few minutes while I think of what else to include. Then I return and re-open Thunderbird on my computer to finish. I never use my computer to check drafts made on my phone because my phone is nearly always on hand.

  3. Have an opt-in setting in the settings menu.

I advocate no. 2, but I wonder what others' thoughts are.

@dllud

This comment has been minimized.

dllud commented Feb 5, 2017

What about encrypting only drafts of potential PGP emails as @rugk proposes above?

"Potential PGP emails" can be defined as emails manually marked for encryption plus all emails with public keys available for at least one of the recipients.

@rugk

This comment has been minimized.

rugk commented Feb 5, 2017

I'd propose this two versions:

  • By default do not upload potential PGP mail drafts at all (current behaviour) and offer opt-in for uploading encrypted drafts OR
  • By default upload all potential PGP mail drafts encrypted (I'd like this more) and offer opt-out to store mails locally only

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.

@marmistrz

This comment has been minimized.

marmistrz commented Oct 18, 2017

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.

@v01d

This comment has been minimized.

v01d commented Apr 2, 2018

Hi, sorry, but it is unclear to me what is the status of this in latest version. Does K-9 still store unencrypted drafts?
I also think that it would be nice to encrypt everything in the IMAP server for encryption at rest of sent and drafts, even when not sending these e-mails encrypted. This allows you to have your saved e-mails encrypted, safe to any future breaches.

@rugk

This comment has been minimized.

rugk commented Apr 2, 2018

AFAIk the current status is that it does not upload pPGP drafts ("potential pgp drafts"). I think this issue here should now be used for implementing PGP-encrypting and upload pPGP drafts and, optionally, all drafts. (what I proposed earlier)

@Valodim

This comment has been minimized.

Contributor

Valodim commented Apr 3, 2018

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.

\\ edit

actually, there are three viable modes:

  • encrypt all drafts
  • encrypt if encryption enabled
  • keep drafts local
@Valodim

This comment has been minimized.

Contributor

Valodim commented Apr 4, 2018

see #3302 for a first simple iteration on this

@v01d

This comment has been minimized.

v01d commented Apr 4, 2018

Cool!

And what about sent email copies? Would be able to also enable that? (I mean, encrypting the copy of a non encrypted sent message).

@Valodim

This comment has been minimized.

Contributor

Valodim commented Apr 4, 2018

Please open a new issue about that, it's off topic here. Short answer, that feature is fairly low on my list of priorities - users who care about it are better off moving to a mail provider that has server-side support for it.

@v01d

This comment has been minimized.

v01d commented Apr 4, 2018

Ok, I understand, will open an issue for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment