(adding .mail-news because most of my comments are mail related)
Ian McGreer wrote:
>
> Sensing danger in this remark, I should clarify what I mean by "useful".
[snip]
> I don't mean that the PSM UI should scare away casual users, but the
> fact that there is so much UI reflects the nature of the problem
> (security). I still believe that a casual user should not need to
> encounter this UI.
I sense (a slight) danger in this remark. Certainly most parts of the
PSM UI (smart cards, etc) are only useful to advanced users or people in
companies with advanced requirements. But there are aspects of
crypto/security that could be useful to regular surfers, IF the
usability bar wasn't so high.
I'm thinking particularly of signed and encrypted mail. Despite two
useful and effective standards for it (PGP and s/mime) it's never seen
widespread use. In designing a mass-market mail program, we have the
opportunity to change this. But we won't do so by saying "Communicator's
UI was good enough". It wasn't: secure websites are easy and transparent
to access, but secure mail is a closed book to most people.
I'm not terribly knowledgeable about crypto in general, but I understand
the basic principles. For basic secure mail, I'd like to see the
following options available (and preferably under mail, not under
security, simply because the security preferences are so complex)...
[ Generate me a public/private keypair ]
[ Send an email with my public key in it ]
[x] Automatically harvest public keys from incoming email
[x] Automatically sign outgoing messages
[x] Automatically send mail encrypted if the recipients' public keys are
all known
[x] Store encrypted mail encrypted on disk
Also, the installation process should offer to generate you a
public/private keypair (or to import one you already have). The existing
psm-backed encryption of sensitive data on disk could be used to store
the private key's password, or (if generating a new key) the same
password could be used.
The idea of "Send an email with my public key in it" and "Automatically
harvest public keys from incoming email" is to make it trivial to
exchange public keys. This initial exchange may not be particularly
secure, but it's as secure as the plaintext email that the majority of
the world currently trusts to send stuff around in. And the requirement
to trust one initial email is a vast improvement on having to trust
*all* messages.
Okay, so I got off into a rant, but my main point is that we should be
looking to RAISE the bar on crypto usability, not assume that previous
attempts are good enough - especially when those previous attempts
haven't seen wide use.
Stuart.
