Description: Screenshot 1: new proposal Screenshot 2: highlighting changes Screenshot 3: current situation
I opened a wishlist entry (feature request) at http://bugs.kde.org/show_bug.cgi?id=122310 So if you care, vote for it!
When you always (or often) use GPG encryption, it gets annoying by time, how incoming and outgoing messages are formated. Of course it is important, that encrypted and unencrypted messages can be easily visually distinguished, but the "incoming encrypted message:" and "outgoing encrypted message:" text that is displayed ahead of every messages is to much visual overhead by time. So it would be nice if this was more decent or could be configured by the user. Best would be if the display of encrypted messages in chat window could be setup by XSL-Styles, so style designers could integrate encrypted messages nicely with the rest of their style.
Furthermore, you should be more easily able to recognize if a message you are going send and which is currently typed in respectively, will be encrypted or not. Just indicating "outgoing encrypted message:" (current situation) after the message was sent can be too late in some cases.
Best would be if the message input area could be customized by XSL-styles, too (like the chat window). Well, there should be different states or classes for the message input area (at least encryption on / encryption off) so that different formatings could be applied by the style.
Finally, since there is enough toolbar space left, it would be nice if one could add an encryption button to the main toolbar for faster encryption on/off switching (like Kmail has).
ARGH : its *not* important at this stage to show encryption or not (with an mockup) , but make GPG encryption AS EASY AS POSSIBLE !!! , its too complicated !!!
first : auto-fetch keys from emailadresses (protocols jabber + msn) !!
second : perhaps evaluate OTR @ http://www.cypherpunks.ca/otr/
when you lose your key , no older chats get compromised !! very nice
anyway , *first* make ist useable for the masses (default = on)
chris
Well, I think KGpg is good enough to make GPG useable for the masses. Of course, there could be some tweaks or enhancements.
Auto fetching public-keys does not mean you can automatically trust those keys. All the public-keys I have in my keychain I got while I was in contact with that person at this moment (e.g. we were talking on the phone and comparing the fingerprints or we directly exchanged the keys (USB-Stick, ...)
The main problem is, that users must be aware that there is encryption and they have to know at least the basics of public-key / private-key concepts. Default = on doesn't help much if users don't know what it's good for and how it works.
Maybe a wizard like Kwallet has, could be launched at the very first KDE startup, explaining public-key / private-key concepts in a convincing and understandable way for end users. Showing examples what GPG can be used for with KDE and providing the possibility to generate a public-key / private-key pair is the last step of the wizard.
Ratings & Comments
2 Comments
ARGH : its *not* important at this stage to show encryption or not (with an mockup) , but make GPG encryption AS EASY AS POSSIBLE !!! , its too complicated !!! first : auto-fetch keys from emailadresses (protocols jabber + msn) !! second : perhaps evaluate OTR @ http://www.cypherpunks.ca/otr/ when you lose your key , no older chats get compromised !! very nice anyway , *first* make ist useable for the masses (default = on) chris
Well, I think KGpg is good enough to make GPG useable for the masses. Of course, there could be some tweaks or enhancements. Auto fetching public-keys does not mean you can automatically trust those keys. All the public-keys I have in my keychain I got while I was in contact with that person at this moment (e.g. we were talking on the phone and comparing the fingerprints or we directly exchanged the keys (USB-Stick, ...) The main problem is, that users must be aware that there is encryption and they have to know at least the basics of public-key / private-key concepts. Default = on doesn't help much if users don't know what it's good for and how it works. Maybe a wizard like Kwallet has, could be launched at the very first KDE startup, explaining public-key / private-key concepts in a convincing and understandable way for end users. Showing examples what GPG can be used for with KDE and providing the possibility to generate a public-key / private-key pair is the last step of the wizard.