Encrypted drafts

[renne]

As it makes no sense to send an email encrypted while storing a clear text draft convienently for intellegence agencies, I suggest to encrypt ALL messages stored on servers.

[niklasfemerstrand]

The counter measure currently is to disable automatic drafting. There is also a trigger on the beforesavedraft JS event prompting a confirm() prompting the user before continuing. What's your stake on this?

I agree, drafts should be encrypted if stored at all. The problem is that there's no real clean way of doing it. The ugly version would be to load the message into a variable (client RAM), encrypting the message in a beforesavedraft event catcher (already in place), overwriting the message content box with the encrypted message, saving the draft and finally after saving the draft (we need some form of callback, I'm sure that can be arranged) rewriting the message content box with the cleartext value previously stored.

This solution would probably be resourcefully noticeable for certain users, for example there's a complaint about crypto speed in #99. What's your idea of implementation? I can build it easily, but what's your opinion on the flow - besides that it should work, obviously?

[renne]

Am 2013-10-07 18:56, schrieb Niklas Szilágyi Femerstrand:

The counter measure currently is to disable automatic drafting. There
is also a trigger on the beforesavedraft JS event prompting a
confirm() prompting the user before continuing. What's your stake on
this?

I agree, drafts should be encrypted if stored at all. The problem is
that there's no real clean way of doing it. The ugly version would be
to load the message into a variable (client RAM), encrypting the
message in a beforesavedraft event catcher (already in place),
overwriting the message content box with the encrypted message, saving
the draft and finally after saving the draft (we need some form of
callback, I'm sure that can be arranged) rewriting the message content
box with the cleartext value previously stored.

This solution would probably be resourcefully noticeable for certain
users, for example there's a complaint about crypto speed in #99.
What's your idea of implementation? I can build it easily, but what's
your opinion on the flow - besides that it should work, obviously?

---

Reply to this email directly or view it on GitHub:
#96 (comment)

It makes abolutely no sense to send encrypted mails but store them
unencrypted on the servers. Everyone who has (il)legal access to the
servers can access the mail. On the other hand having drafts is quite
convenient if you e.g. have to look up some information while writing
the email which can cause a timeout by the webserver or if you have to
postpone finishing the email.

So I suggest to store encrypted drafts by default and provide an option
to disable drafts completely.

Regards,

Renne

[niklasfemerstrand]

Did you even read what I wrote?

[bogde]

1. i think draft saving should be disabled while using the plugin. those who care about security can probably live without drafts. remember when most webmail providers didnt support drafts at all?
2. saving encrypted drafts leads to a lot of complexity. (what if the user doesnt have his keys in the browser he's using, what if he just wants to send a clear text message anyway, what if the draft is saved and then the user tries to open it on a computer that doesnt have the keys etc.)
3. still, maybe it would be possible to:
   a. in the beforesavedraft hook get the clear text, encrypt it and send it to the server; return false on the hook so roundcube doesn't process it further
   b. in our 'register action' function get the encrypted message and save it as draft (i'm not very familiar with the rc api, don't know if saving the actual draft is easy or even possible)
4. i think draft saving should be disabled while using the plugin :)

[krautsource]

saving encrypted drafts leads to a lot of complexity. (what if the user doesnt have his keys in the browser he's using, what if he just wants to send a clear text message anyway, what if the draft is saved and then the user tries to open it on a computer that doesnt have the keys etc.)

What a nightmare :-)
I share your thoughts on this.

i think draft saving should be disabled while using the plugin :)

Either that, or, as a less drastic measure, draft saving could be prevented if the "encrypt" option for the message is active.
Pro: Clear-text messages could still be saved as a draft.
Con: If the user intends to write an encrypted message but doesn't activate the "encrypt" option from the beginning, the message may make its way to the drafts folder in the clear.

[niklasfemerstrand]

The Roundcube 1.0-beta includes saving drafts in local storage. Am I adventureous thinking that resolves all of this? http://trac.roundcube.net/milestone/1.0-beta

[renne]

No, I think that's a good approach. Temporary drafts can be stored in local storage. When the user leaves the email editing window and hasn't send the mail, he can be asked if he wants to store the final draft encrypted on the server or keep it unencrypted on the local machine. The only thing I'm worried about is the 5 MByte limit of HTML5 storage.

[michael-dev]

The topic says "As it makes no sense to send an email encrypted while storing a clear text draft convienently for intellegence agencies".

So the point is about an agency spying on the mailserver. If they already have write access to your webserver, you cannot trust roundcubemail at all - so no rc plugin can ever recover your privacy.

So while only saving encrypted drafts certainly removes some additional attack vendors, sending encrypted mails while keeping an unencrypted copy still protects you from some attack vendors and thus the plugin remains useful.

[renne]

In most cases (e.g. big mail providers) intelligence agencies will spy but not tamper the server to avoid leaving tracks or upset thousands of customers by breaking the service. But there's even a workaround for protecting the code against changing. If Roundcube runs as a HTML5 offline app and the user has to allow downloading a new version, he at least knows when code changes. And storing an unencryted draft at any service breaks privacy as a lot of providers scan their customers mail (e.g. for personalized advertisement) or even sell information about their customers. So I suggest to store final drafts encrypted on the server and use local (unecrypted) caching for snapshot drafts.

[jseidl]

I agree with @encomiast . If box is checked, encrypt, save. If not. No worries. We could add a handle on saving the unencrypted draft a warning like "Draft Saved UNENCRYPTED". I'm also dealing with a similar issue but I'll open another thread for that.

[niklasfemerstrand]

So the point is about an agency spying on the mailserver. If they already have write access to your webserver, you cannot trust roundcubemail at all - so no rc plugin can ever recover your privacy.

Maybe not write, but read, and maybe after the email has arrived. Spying begins somewhere, and fighting LEO is often a race condition.