[messaging] Autocrypt 1.0

[Vincent Breitmoser]

> I'd worry that developers of security-conscious email clients will
> encrypt in the "available" case by default, or at least have an option
> for this that security-conscious users will turn on without fully
> understanding.

If they do, they are quite simply breaking the spec, if not in rfc-words
then in spirit.

> If that happens then setting "prefer-encrypt:
> nopreference" won't be very effective for testing out Autocrypt with
> low commitment.

Hopefully this scenario can be avoided by communicating with
implementors, and push them in the direction we actually intended.
Existing implementations do have user expectations and are rarely
willing to break with those, so I'm not getting my hopes up too much to
be universally successful in this regard.

> There are other testing possibilities that seem more reliable, e.g.
> having a short expiration for the header.

I'm not sure I understand this model. Is your suggestion that mails that
are sent in quick succession will be encrypted, dropping to plaintext
after some cooldown?

> Ideally I think Autocrypt should make automatic yes/no decisions on
> whether to encrypt.  Instead, it's mostly going to produce "up to you"
> decisions, asking the user to manually resolve the above cases.

How would we make those automatic decisions, though? Encrypted mail is
just inherently less convenient to use (can't even search those
buggers!), I'm not sure when the decision would ever be "yes" if we
don't have express user intent that some content/thread is important and
should be extra-protected.

It's also worth mentioning that "up to you" doesn't necessarily mean "in
your face". With a simple yes/no mechanism, hopefully users can
experiment a bit without burning themselves.

 - V