[Enigmail] Usability issues

[Robert J. Hansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The ideas here will probably be at least somewhat controversial.  Please
think them over long and hard before you say "... but that's stupid!"  I
agree that many of these ideas will appear stupid at first blush, but I
think that some of them may actually be stupid-smart as opposed to
stupid-stupid.

I am recommending these ideas to the developers, but any changes like
these should only be made with a lot of community input.  So--give your
input.  :)




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.



1.  BAD SIGNATURES AREN'T.

For a signature to have any meaning, it must be:

	* A good signature
	* From a validated certificate

In no other case does a signature have any meaning.  Let's say that I
receive a bad signature from John Clizbe.  I trust John and have given
his certificate a nonexportable validation.  That bad signature means
the message was changed /syntactically/.  It has nothing to say about
whether the message was changed /semantically/.  Compare these two messages:

a.  Now is the time for all good men to come to the aid of the party.
b.  Now  is the time for all good men to come to the aid of the party.

I don't know anyone who would argue that message A possesses a different
meaning than message B.  Yet, message B would have the signature fail
(due to the addition of a space after "Now"), while message A would have
a good signature.

As we can see from this, a bad signature does not mean your message
semantics have changed, but only your message syntax.  Given that
communications are semantically meaningful, we need to consider--very
strongly--the possibility that a bad signature possesses _no useful
information whatsoever_.

A bad signature on a message does not necessarily mean the semantic
content (which is what we care about) was tampered with.  It only means
that we cannot guarantee it was not tampered with--not that it actually was.

A good signature on a message means we can guarantee the semantic
content is unchanged, since the syntactic content is unchanged.  Thus,
we can guarantee it was not tampered with.

Consequences: maybe bad signatures shouldn't be displayed by Enigmail at
all.  If a bad signature possesses no informational value and is
functionally equivalent to an email that has no signature (no signature
has no guarantees of tamper-free, bad signature has no guarantees of
tamper-free), maybe Enigmail should give two different messages.

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."



2.  WE NEED TO HELP THE USER IGNORE US.

One of the major goals of HCI is to help lessen the learning curve--to
make it easier for novices to develop expert-level skills.  To this end,
we try to figure out what are the hallmarks of expertise.  One thing
that comes up again and again is that an expert is someone who knows
what to ignore.

Signatures are a major part of the stuff we need to ignore.

When I open Patrick's key, I see a whole slew of signatures from people
whose user IDs are unknown.  Even the signatures I see from people whose
user IDs are known are worthless.  E.g., there's a signature there from
wk at gnupg.org, but since I haven't validated the certificate belonging to
wk at gnupg.org, there's no meaning I can associate with those signatures.

So here's my proposal--by default, only display those signatures that
come from validated certificates.

Consequences: what I consider to be the worst attack against
OpenPGP--the credibility attack--becomes less of a problem.  Let's say
that someone wants to ruin Patrick's credibility.  They create a few
bogus certificates, associate them with reprehensible groups, and use
them to sign Patrick's key.

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.



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.

GnuPG is not a UI target.  It is a functionality target.  The UI target
is up to us.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBCAAGBQJHXnJ+AAoJELcA9IL+r4EJmpAIALDZLNVf49dxEu8Km1dH/2wU
dwx74xSU7uzJy50zNwLCJFq8bMQWvbczkRWhL1C6X3+CUA3DvThHT1jWpgGtQEtC
zNI0l+4ER1dERGmXsc8Q+nZ4d00ig8cNCk2q7CblqdSI02BIZSqseLUROAtGDVzE
8XtH3En9+K3Cx+GM/ViOhObvPdMKIGkNPAdVCt9xXqt3Du28CoJw5Q3BOuXGY+bq
A5RaYvYkMAoMOhHRLOoGLqB8lMKepqEXKDC/fxIT0D5/8r3IvDR4OvE9SLW1u1FX
km0jVNEdf9zc/hGUbBQx2bzsPuIm0qtAIuxyV+csVAI53rrS6vXQQ/2YC0t8/YM=
=9ySb
-----END PGP SIGNATURE-----