Is this feature request to store drafts in localstorage defined in any detail anywhere? Is it partially implemented anywhere, or part of a plugin? I looked and couldn't find anything other than a couple of messages in the dev archives.
My main question is whether we're going to save the drafts as
unencrypted data? Is this something that people are comfortable with?
Especially given that we would not store this as session-only data
(because we presumably would want to restore data from an interrupted
session), it seems like storing it as unencrypted might represent
problems (at least for some more sensitive e-mails). The obvious
solution would be for the server to store a private key and to send a
public key to javascript for encrypting localstorage. That raises
issues of where to store the private key, and how/when to generate it.
It also starts to overlap with Alec's GPG plugin. Would we want to use
the same GPG key that we use for sending encrypted messages (essentially
sending them to ourselves), or would this be a completely separate key
just for localstorage that we could potentially generate at setup and
just store along with the userdata in the database.
If I can get some answers to these questions, I'd love to start developing this.
-Charles
Charles McNulty wrote:
Is this feature request to store drafts in localstorage defined in any detail anywhere? Is it partially implemented anywhere, or part of a plugin? I looked and couldn't find anything other than a couple of messages in the dev archives.
No, this isn't implemented or started yet.
My main question is whether we're going to save the drafts as unencrypted data? Is this something that people are comfortable with? Especially given that we would not store this as session-only data (because we presumably would want to restore data from an interrupted session), it seems like storing it as unencrypted might represent problems (at least for some more sensitive e-mails).
True, although it's supposed to be a rare situation where email texts actually remain in the local storage. The idea is to remove it after each successful saving of a draft on the server and of course on successful sending.
Private key encryption certainly comes to mind but that opens a huge can of worms that we currently don't have a solution for. The only feasible way would be client-side PGP encryption but that's not fully ready and adds some barriers in terms of requirements to the client and the user.
The obvious solution would be for the server to store a private key and to send a public key to javascript for encrypting localstorage. That raises issues of where to store the private key, and how/when to generate it. It also starts to overlap with Alec's GPG plugin. Would we want to use the same GPG key that we use for sending encrypted messages (essentially sending them to ourselves), or would this be a completely separate key just for localstorage that we could potentially generate at setup and just store along with the userdata in the database.
As said, PGP/S-MIME encryption isn't yet ready for Roundcube so we better leave this for the moment.
If I can get some answers to these questions, I'd love to start developing this.
The initial idea was indeed to store the message body in plain text and make sure it only remains in local storage if the session timed out and the message could neither be sent nor saved as draft.
If we want some sort of encryption for these contents, I propose to start with a simple DES or AES encryption using a key that is derived from the user ID and the Roundcube's des_key config option. That would at least deny access to the contents for other users of the same webmail as well as for direct access to the local storage through the browser's console.
Regards, Thomas
Am 30.10.2013 12:16, schrieb Thomas Bruederli:
Charles McNulty wrote:
If I can get some answers to these questions, I'd love to start developing this.
That would be just great!
The initial idea was indeed to store the message body in plain text and make sure it only remains in local storage if the session timed out and the message could neither be sent nor saved as draft.
Or if it could be saved as a draft some time, but if the last attempt(s) failed for whatever reason (i.e. unstable Internet connection which does not necessarily lead to a session timeout).
If we want some sort of encryption for these contents, I propose to start with a simple DES or AES encryption using a key that is derived from the user ID and the Roundcube's des_key config option. That would at least deny access to the contents for other users of the same webmail as well as for direct access to the local storage through the browser's console.
I second that. Although I could even live with unencrypted data (at least better than with no local storage at all).
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Thomas Bruederli wrote:
Charles McNulty wrote:
Is this feature request to store drafts in localstorage defined in any detail anywhere? Is it partially implemented anywhere, or part of a plugin? I looked and couldn't find anything other than a couple of messages in the dev archives.
No, this isn't implemented or started yet.
Now we have a start in latest git master.
The storage is yet unencrypted but ready to do some first testing.
Whenever one leaves the compose screen "intentionally", the copy in local storage is removed. One is supposed to save the compose state as draft. Also when somebody logs out (by hitting the "logout button), I take this as an intentional action and clear the entire compose storage for this user. Only in cases where you quit the browser (and thus the session) in other ways or if the server loses the session data, the local copy remains in the browser's storage. When you then re-login an open the compose screen again, a dialog will ask you whether to restore the locally saved message contents.
Along with the local storage, I also tried to improve the general behavior on session timeout or other unexpected errors when the client communicates with the server.
Everybody is invited to give it a try with git master. Probably the behavior when to keep data and when to ask to restore is subject for improvements. I'm waiting for your feedback on this.
Kind regards, Thomas
-
Charles McNulty -
Michael Heydekamp -
Thomas Bruederli