[Enigmail] Usability issues

Tue Dec 11 07:04:29 PST 2007

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

Robert J. Hansen wrote:
> 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."
> 
> 
To me a bad signature is a warning that the message could have been
tampered with.  Numerous people I communicate with use Enigmail for
verification and for the majority do not use the encryption aspect of
GnuPG.  Thus when you receive a message with a bad signature you could
get with the sender and verify the message.  In other words a bad
signature is just a warning for the recipient of the message just like
an Untrusted Good Signature.

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

Only the owner of a key pair should send a key to a key server.
you could set up a cron job with a line like
  gpg --send-key 0x12345678
to make sure that only your version of your public key is on a key server.

Also, you should not accept a signature for your key unless you have
verified the signature like from a key signing party

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

There are a number of us that use numerous xterms and use gpg interactively.
_______________________________________________
Enigmail mailing list
Enigmail at mozdev.org
https://www.mozdev.org/mailman/listinfo/enigmail

- --
 Rev. LeRoy D. Cressy  mailto:leroy at lrcressy.com   /\_/\
                       http://lrcressy.com        ( o.o )
                       Phone:  215-535-4037        > ^ <

gpg fingerprint:  62DE 6CAB CEE1 B1B3 359A  81D8 3FEF E6DA 8501 AFEA

For info on enigmail:    http://lrcressy.com/linux/mozilla.pdf
For info on gpg:         http://www.gnupg.org/

Jesus saith unto him, I am the way, the truth, and the life:
no man cometh unto the Father, but by me. (John 14:6)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBR16m+3lsxrSGsIsqAQhQShAAoMiw4UeZgrIwmBAXTDKkGDL2dd0CLf2R
3byM2vx7+xPgfho1dYHdVZsuUkNrLhm7G9p1Xbmkb1Ztoo17iJ1q09mem3oQnf6G
CCuZtHLevOJcXy8oEYaTkn4qbTOR973qfsX6S3mctvrOgOeTuDeL1J2riKIkUFGG
9wfNiMV+OnCMG1YsmQz0V6qNggjRDzWB/kEDqXPNVll3rBXyiOhF1TM9W9G4Czto
US4YbFnrmpcQjjMG0pCt2CWkDWTvKIDcLqP8SsUJxy3gG7FgnpE/tipJb/mzVPeD
O4l8xgbE3EhOOtwdjNllm4aibl7DvmmUcsFKfRcie5g3NPYcU0j0kmNmRTcTAYTq
rDf8nK+SJQ7sWUvMgFHSMQLKCQdRJD3Qf5lzT5ov3WuEZtx6eBPH+uQ8HTEnQ1Qt
L82MEG/evNFuXD9UlAzkHvZOBlCbszXJ7x+lFA3oemTsa9hPIspYoWmzg5jI7IHW
SBwE5n5QEmAT8yunAAckfRgN5xK1e+Z/aO/MES/y79e4NeN4IZkriEBL7S8G5bP2
ZYIKRHiCj8HeOMNUVTbRralaL07ZHiRsEGBoo5B8MtnD1N7suSgo/dNs2qmAINtT
ZYos8/AYi7z2Hbl5frA9P1CsmTJ60X+hRdRlmbCnEgbOxJoR//SLQwxDatYA3by1
U8ucAxwg9yk=
=DZP3
-----END PGP SIGNATURE-----