[messaging] Autocrypt 1.0

[Trevor Perrin]

On Sat, Dec 23, 2017 at 11:11 AM, Vincent Breitmoser
<look at my.amazin.horse> wrote:
[Trevor wrote]:
>> 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.

The UI recommendation for senders is only a "SHOULD" in the spec
(4.1), so it doesn't violate the spec to do something different.

It seems reasonable to think the spirit of "prefer-encrypt:
nopreference" is that the advertiser has "nopreference" whether
senders encrypt.

If "nopreference" is intended to require explicit sender action for
each encryption, it should perhaps be renamed, and this requirement
made clear.


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

I guess I'm not sure what "nopreference" is supposed to accomplish.

Is the goal a safe trial mode where someone experiments with Autocrypt
before committing?  If so, I don't think it meets that goal well:
There's ways to do that which would be safer, and which wouldn't
depend on / impose new decisions on the sender.

An example would be for Autocrypt headers to have an expiration time,
which is initially set to a few minutes after the header is sent.
This would be sufficient for testing Autocrypt without risk of
long-term mail disruption.  Once you get comfortable with Autocrypt,
you could lengthen the expiration time.

If "nopreference" is instead intended as the default, long-term usage
mode for Autocrypt, then I'd have the concern that Autocrypt isn't
"automatically encrypting", which I hoped was the point.


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

I wasn't clear enough, I was trying to make a simpler point:  When a
sender is drafting an email, your recommendation algorithm has four
outputs ("disable", "discourage", "available", "encrypt"), each of
which gives a different UI.

I think having 4 UI modes which are chosen based on hard-to-understand
and non-visible criteria (previously gossiped keys, expiration times,
"prefer-encrypt" settings) will confuse users.

If I was you, I'd try to get rid of "discourage" and "available":

 * "discourage" is used for gossiped keys that have leaked out of
their original thread scope (which seems like a bad idea to begin
with), and for old keys (so don't use them).  It seems like you could
get rid of it.

 * "available" is used when "prefer-encrypt: nopreference" is
advertised.  There's a lack of clarity on what this is for, but there
are potentially other ways to provide trial modes / safety-valve
mechanisms, without requiring sender decisions.

If you could eliminate those modes, then you'd only have two modes
("encrypt", "disable"), which seems like a much simpler UI.

Anyways, there's various ways to handle all this, so I'm less trying
to advocate a single alternative, and more trying to advocate for the
goal of simplifying the questions presented to the user.


Trevor