[Enigmail] Usability issues

John W. Moore III jmoore3rd at bellsouth.net
Tue Dec 11 09:02:30 PST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Robert J. Hansen wrote:

> 0.  KEYS AREN'T.
> 
> The idea of a 'key' is pretty poorly defined.  In the original days of
> PGP 2.6 we used a single keypair for all operations.  This hasn't been
> the case for many years, though.  Instead, we use collections of
> keypairs to do all our operations.  This means that instead of 'key' we
> should probably be talking about 'certificate'.  GnuPG is beginning to
> make this terminological shift.  For the rest of this, I'm going to use
> 'certificate' to refer to key collections that are associated with one
> person.

Any concern about confusion with x.509 Certificates?

> For good signatures from validated certificates, Enigmail should tell
> the user "this message is exactly as your recipient sent it, its
> provenance is assured."  For all other messages--bad signatures and
> unsigned messages both--Enigmail should tell the user "this message may
> have been tampered with in transit.  Its provenance cannot be assured."

Since Enigmail currently uses the colors 'Green' & Blue" could this also
be indicated with a 3rd color?  Perhaps "Yellow"?

> Now consider what happens if we have a policy of "by default, only show
> meaningful keys".  Since I would presumably not have certified this
> (fake, slanderous) neo-Nazi key, the user would never see it.  Only
> those people whom I trust who have signed Patrick's key would show up.
> 
> All other keys--those keys that possess no probative value in
> determining whether a key should be trusted--could be collapsed into a
> category of "Missing or Untrusted Keys".  If for some reason you really
> need them, you could click on them and view them.  But 99% of the time
> they would be hidden away, where the user would never have to notice
> them and thus could easily ignore them.
> 
> There are many other instances where this "ignorance is bliss"
> philosophy could be productively used.

I very much like this concept.  However, I foresee a lot of Users
curious to know [& understand?] "What am I missing?"  Perhaps this
behavior could be 'switchable' like the 'Display All Keys' feature is?

Of course, the addition of UI features always runs the risk of making
the Code more complex to the extreme of Patrick demanding a raise. :-D

> 3.  WE NEED TO STOP THINKING GNUPG IS A UI TARGET.
> 
> GnuPG is a command-line app written by some very sharp people.  It's
> good stuff.  However, it gives us a lot more information than we
> actually need.  E.g., something as simple as redundant signatures on a
> key... sure, those signatures exist, and GnuPG is correct to tell us all
> those signatures exist.  But when it comes to presenting signatures to a
> user, the user needs to have those redundant signatures
> stripped--redundant signatures on a key tell us absolutely nothing.

The above example could be solved by having Enigmail --import-clean by
default.

JOHN ;)
Timestamp: Tuesday 11 Dec 2007, 12:02  --500 (Eastern Standard Time)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8-svn4645: (MingW32)
Comment: Public Key at:  http://tinyurl.com/8cpho
Comment: Gossamer Spider Web of Trust: https://www.gswot.org
Comment: My Homepage:  http://tinyurl.com/yzhbhx
Comment: MySpace Page:  http://www.myspace.com/jmoore3rd

iQEcBAEBCgAGBQJHXsKjAAoJEBCGy9eAtCsPaiYIAJVwjycCgDgO2JVxDJHielAH
J6R/Fg4II0qZ0XJ8+Gmt2UBRCtBdGFgvyvhGmA8302v+BNYYoGQYoH9KC5kiq9/E
phxftY1Wy4qvJX6vna+luKUCvTWrT+Xb8JuNs109mF4Dh7ZL1cpBb58cu02Uatc1
rYJv2+/avWE1yo4tjUxPXsODffP/aOtt+QNluVk8wBpwG2hcAE0SWcL9SizU56p3
lfiFviI5k3aRbGrZJuO52NuiSCyKtt9AR7q30QwdluCc5srYs0RnLJcc2RzypNaA
6qHbHcF/vUNfItZ3ZS/ilrGBe8P0S7J1sSr6mNrRsffNLWmyj0zVaKT7lnvnfXc=
=rFfW
-----END PGP SIGNATURE-----


More information about the Enigmail mailing list