a maximally simplified GUI for OpenPGP (no code)

[Hauke Laging]

Hello,

Am Do 12.12.2013, 14:24:18 schrieb Bernhard Reiter:

> * I'm not quite sure what the aim of your gui is. To create a nice and
> usable gui (which then automatically means it has to be understandable and
> as simple as possible) we need to know what it should do.

may be. But I didn't know that (or that this knowlege is already available; 
and is it public so that people can assess and discuss it?) when this became a 
relevant question for me. I do not believe that "a nice and usable gui" has to 
be "as simple as possible" in any case. I am quite sure that this depends a 
lot on the targeted user category. What I did is targeted at people with 
absolutely no clue about the subject; people who are confused by the amount of 
options and operations of e.g. Enigmail or kleopatra. My approach was: "Show 
less, require more clicks (selection steps)"


> In my point of
> view most of the "crypto" problem should be done in the application that
> needs the crypto operations.

I do not think that this is a big difference. Furthermore: The GUI doesn't 
care whether it belongs to a limited (key management) application which is 
completely covered by it or whether it is part of a larger application and 
covers just a certain part of it. Does it? You could even use the same GUI 
twice (both for the key management application and as part of a bigger one).


> Thjs could improve your gui's wording.

Mine was intentional. Without having the benefit of your discussion I guess 
that "key" is good enough for the no clue target group. I wanted to avoid 
everything (as far as possible) that would probably confuse this kind of user. 
BTW: I went very slowly through the whole process (together with a friend who 
was not familiar with crypto at all): installing Gpg4win, installing Enigmail, 
configuring Enigmail. I am quite sure that I have reached a certain above-
average level of OpenPGP understanding so it was kind of fun to notice that 
the normal key generation with Enigmail lead to a question / option which not 
even I understood... (but that's made by people who think it's clever not to 
show any certificates by default, WTF...)


> * The hard part, IMO is to build, maintain and somehow display the trust
> path and its level to the communication partners. Your draft does not
> address this part.

Really? Importing leads you directly here:
http://www.crypto-fuer-alle.de/wishlist/simple-crypto-gui/index.en.html#certkeyinfo

And: This is a two-level import (using an additional keyring) so that keys do 
not become available to applications before the user has

1) either stated that he has verified the key

2) or stated that he doesn't care

And even in case (2) 
http://www.crypto-fuer-alle.de/wishlist/simple-crypto-gui/index.en.html#keygroups
shows in a very simple way that the key has not been verified yet.

Compare that to 

1) gpg not showing the UID (or overall) key validity by default
2) Enigmail not even being capable of showing it
3) the nightmare GUI of kleopatra

In all these applications import and certification are independent steps (i.e. 
certification has to be started separately). In my proposal they are linked 
together.


CU

Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/bekannte/
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20131212/f4f8a27b/attachment.sig>