STEED - Usable end-to-end encryption

[reynt0]

On Oct 25, 2011, gnupg at lists.grepular.com wrote:
  . . .
> (*) there's a nasty privacy issue when you're able to trigger a
> receiving email client to do arbitrary http lookups. It means the sender
> is able to determine when the recipient downloaded the email, and what
> IP address they were using at the time. Perhaps MTAs could look up the
> public key on delivery and add it to the email headers.
  . . .

A comment about social psychology, FWIW:

Just from talking to ordinary users, it seems to me that a
hesitation they have is not to get involved with something
they do not much understand, particularly when the people
trying to sell it to them are telling stories about bad things
happening to people because of stuff the people do not
understand.  People live their lives aware they are dependent
on a lot of stuff they can not control or really understand,
and cope by separating what is their own self and what is
"other".

Isolating the user's involvement in the system as much as
possible (eg to just locally running en/decrypt actions
including using whatever keys) might both (i) technically
protect users from bad stuff (including the bad effect
mentioned in the quote above) and (ii) make it more
comfortable for them to internalize into their own psychology
that there is this security stuff happening, because it is
OK since the experts are taking care of it for them and if
things go wrong, they (users) themselves are not to blame.
If users do not internalize the situation, they are unlikely
to want to go along with it, that is how psychology works.

Cf consider a strategy of aiming for something like technical
modularity which mimics users' psychological modularity about
the product.  The system designers' problem is that they have
to look at the overall system objectively technically as well
as to take the position of the individual user and look at
the system from that point of view, too.