README: added the Security section

1 files changed, 30 insertions, 0 deletions

diff --git a/README b/README
index 1a0ef97..28488e0 100644
--- a/README
+++ b/README
@@ -123,6 +123,36 @@ great for saving power.
     inconsistent data.
 
 
+Security
+--------
+At the moment only one widget type (Gmail) requires auth. information
+in order to get to the data. In the future there could be more, and
+you should give some thought to the issue of protecting your data. The
+Gmail widget type by default stores login information in the module it
+self, and you are advised to make sure that file is only readable by
+the owner. Other than that we can not force all users to conform to
+one standard, one way of keeping it secure, like in some keyring.
+
+First let's clear why we simply don't encrypt the login information
+and store it in ciphertext. Answer is simple, that is no more secure
+than having it stored in plaintext. By exposing the algorithm anyone
+can reverse the encryption steps. Some claim even that's better than
+plaintext but it's just security trough obscurity.
+
+Here are some ideas actually worth your time. Users that have KDE (or
+parts of it) installed could store their login information into the
+Kwallet service and request it via DBus from the widget type. It can
+be done with tools like "dbus-send" and "qdbus". The Gnome keyring
+should support the same, so those with parts of Gnome installed could
+use that keyring.
+
+Some users move their login into an external file and read it from
+there. Not much different than keeping it in the module, but what if
+you encrypt the file with your GPG key? Users of the GPG Passphrase
+Agent could decrypt the file transparently while their session is
+active.
+
+
 Widget types
 ------------
 Widget types consist of worker functions that take the "format"