[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-active
Subject:    encrypting mails with kmail-mobile
From:       Michael Bohlender <michael.bohlender () kdemail ! net>
Date:       2013-08-01 19:21:29
Message-ID: CAOF1ztzOEnv5ODFGFyFsVeBX_P3Q+s5UeyWGgL4MoyRioO9n6Q () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


I  messed up the "encryption" part in my last mail so here are some
thoughts and how we could do things.

Supporting encryption is a hard problem from a UX point of view but I
really want to make it happen. This is a little braindump.

We have some Problems:

# It breaks webmail

nothing we can do about that

# it breaks other clients unless they have the same private key

this is especially relevant for kmail-mobile because it is not meant to be
the single email client but a (mobile) addition. So we need to make it
really simple / semi automated to exchange/copy keys between kmail and
kmail-mobile

# it is an overhead to the communication that can't be fully automated.

we need to make it as seamless as possible. this means making it the
default configuration. so you "need" to do a key setup during the account
creation. mails will be sent encrypted and signed  whenever possible unless
the user explicitly tells us not to. Whenever you receive someones public
key you get a dialog that asks you if you want to  add that to your keys
and so on. Maybe even include a little tutorial that teaches the user about
encrypting emails.

# It requires both parties

There is not much we can do about that but a little footer that we could
enable by default that tells the receiver what the strange public key
attachment (that we also send by default) is.


This is out of scope for my GSoC project but we need to keep that in mind
when designing the basis.

Cheers Mike

[Attachment #5 (text/html)]

I =A0messed up the &quot;encryption&quot; part in my last mail so here are =
some thoughts and how we could do things.<div><br></div><div>Supporting enc=
ryption is a hard problem from a UX point of view but I really want to make=
 it happen. This is a little braindump.</div>
<div><br></div><div>We have some Problems:=A0</div><div><br></div><div># It=
 breaks webmail</div><div><br></div><div>nothing we can do about that</div>=
<div><br></div><div># it breaks other clients unless they have the same pri=
vate key</div>
<div><br></div><div>this is especially relevant for kmail-mobile because it=
 is not meant to be the single email client but a (mobile) addition. So we =
need to make it really simple / semi automated to exchange/copy keys betwee=
n kmail and kmail-mobile</div>
<div><br></div><div># it is an overhead to the communication that can&#39;t=
 be fully automated.</div><div><br></div><div>we need to make it as seamles=
s as possible. this means making it the default configuration. so you &quot=
;need&quot; to do a key setup during the account creation. mails will be se=
nt encrypted and signed =A0whenever possible unless the user explicitly tel=
ls us not to. Whenever you receive someones public key you get a dialog tha=
t asks you if you want to =A0add that to your keys and so on. Maybe even in=
clude a little tutorial that teaches the user about encrypting emails.</div=
>
<div><br></div><div><div># It requires both parties</div><div><br></div><di=
v>There is not much we can do about that but a little footer that we could =
enable by default that tells the receiver what the strange public key attac=
hment (that we also send by default) is.</div>
</div><div><br></div><div><br></div><div>This is out of scope for my GSoC p=
roject but we need to keep that in mind when designing the basis.</div><div=
><br></div><div>Cheers Mike</div><div><br></div><div><br></div><div><br>
</div><div><br></div>


_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active


[prev in list] [next in list] [prev in thread] [next in thread]