Bug 326476 - add a request for advocating crypto to the crypto configuration
Summary: add a request for advocating crypto to the crypto configuration
Status: REPORTED
Alias: None
Product: kmail2
Classification: Applications
Component: crypto (show other bugs)
Version: 4.10.5
Platform: unspecified All
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL: http://userbase.kde.org/Concepts/Open...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-23 03:23 UTC by Hauke Laging
Modified: 2013-12-14 10:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hauke Laging 2013-10-23 03:23:39 UTC
We need everyone we can get for help in advocating the usage of crypto tools. Currently even most crypto users are not aware of the opportunities they have for doing that (even at nearly no effort).

Thus the crypto configuration windows should get a link to a page which tells them,  e.g. the userbase wiki page I created for this purpose: http://userbase.kde.org/Concepts/OpenPGP_Help_Spread (which would solve the translation problem for KMail)

See this similar wishlist entry: https://bugs.kde.org/show_bug.cgi?id=318005

Those who understand German may have a look ta my crypto advocationg site (which contains similar ideas), too: http://www.crypto-fuer-alle.de/

Reproducible: Always
Comment 1 stakanov.s 2013-12-06 12:41:59 UTC
Well, let's fight for this, since I frustratingly try to convince the very few! reliable friends I have to consistently propagate the use of GPG, maybe that can help. Why not. Worth a try. P.S. thank you for the link about crypto for all. Nice. 

Reasons to vote for this: 
a) people really do not understand the importance of encrypting even now
b) people begin to associate through FUD the gpg as something "only agents should do" and as something forbidden, "exposing them".
c) people do not understand the advantages of the use of consistent gpg encryption, regarding personalized spam and social engineered phishing (what do you engeneer if you do not know what they are writing, right?)
d) people are not aware of the little pitfalls on privacy (like the header and the subject NOT being encrypted). 
So such a tutorial and promotion could address all that with few, well done unified info that is (especially important) consistent through different distributions. 
I will vote for this thing with a few points but I think you should consider to "fusion" this proposal with 318005, as redundancy shall disperse the other users votes (a bit as happens here with me). 
YMMV of course.
Comment 2 Hauke Laging 2013-12-14 06:04:43 UTC
Hello,

I think you have misunderstood the difference between the two proposals. Your "Reasons to vote for this" refer more to the other proposal IMHO.

The important point is that crypto users and non-crypto users are quite different target groups for information. In the case of KMail this is less clear as KMail contains crypto support so both groups use the same software. That is very different with Thunderbird and Enigmail e.g.

I want to reach the non-crypto users with a message like "Use crypto. Read here why and how" in two ways:

1) The software they already use (e.g. KMail, Thunderbird) shall point them at that.

2) The crypto users shall spread this mesage with their possibilities (personal web site; text signature in email). The software they use shall ask them to to that. And shall maybe make this easier for them (e.g. by suggesting respective text and links for a text signature).

Thus often these two proposals affect different programs so they cannot be combined. Only this one makes sense for Kgpg e.g.
Comment 3 stakanov.s 2013-12-14 10:25:41 UTC
Hi Hauke. 
Well, whatever floats your boat, for me they are similar. As a Kmail user however, I do just know "what" to advice to install e.g. in Thunderbird, albeit I have just one time seen what it looks like, IMO very invisible).
I agree user should be advocated for encryption of email (although I have to say that as long as distributions install with KDE listening with X as root on 6001 and 6002 .... talk about security). What I would like to warn however is to use of a KDE island solution and of non consistent terminology. Whatever aspect you take there is a huge confusion out there, right from users that I try to begin to dive into it:
FAQs are: why is there Kleopatra and Kgpg and what is their relationship. Can I use them together in the same moment, will they collide. Where should I store keys etc. . If you enrich other programs with encryption and with your initiative,  the look and feel of all these solutions should be to some extend similar, which is difficult to achieve.  That goes even to the use of wording. Private key, public key, secret key. For some time KGPG proposed the dialogue "export secret key" for exporting the public one. And if you import a public key the program states "one secret key imported". An anecdote: at the end I found a friend that did export her "private key" because she wanted to be private and she was afraid to post here "secret" key which was the public one. IMHO we shall begin  to create already a homogenization and to build up a base of consent, of all stakeholder, on a coherent wording that is "intrinsically safe" that is, does not result in misunderstanding. So a kind of root cause analysis and the proposal on the gpg list of using "certificate" for the public key could be a good idea. That said, IF all stakeholders are CONSISTENTLY agreeing on it. 
So yes, you may do a pop-up window with a link to a site explaining cryptography. And yes, very good idea to propose a "standard" signature to promote the use of encryption. By the way this should be fairly easy to achieve for one flavor of software. But here if I well understand one is talking of KDE and your problem, if I well understand, when referred to thunderbird (not developed any more AFAIK but widespread), claws, evolution etc. cannot possibly be solved through  KDE bugzilla?  So it may be nice to set up something like this more centrally, with GPG makers in coordination with all projects. 
If you want to avoid an island solution, I guess, that is then the way to go. Just a thought.