[messaging] Autocrypt 1.0

[Trevor Perrin]

On Sat, Dec 23, 2017 at 12:23 AM, Vincent Breitmoser
<look at my.amazin.horse> wrote:
>> The recipient of this message will accept and use the incorrect
>> gossiped keys for group replies, thus sending unreadable messages.
>
> I don't think that's right? Keys received directly take precedence over
> gossip keys, so everyone who participates in the group and has sent at
> least a single message, will no longer have his key overridden within
> that group.

Sure, but anyone in the group who *hasn't* sent a recent message to
all other group members is at risk of having their key overridden by
an outsider.

Since gossip is intended for encrypted replies within a thread, it
seems weird and unnecessary that gossip from outside a thread can leak
into the thread and cause unreadable messages.
It also seems undesirable that gossiped keys from inside a thread can
leak out of it, and appear as confusing "discouraged" keys when
drafting other messages, or get automatically used in other threads.


>> Advertising "prefer-encrypt: nopreference" doesn't give the advertiser
>> control over whether to receive encrypted messages, it just makes it
>> discretionary for senders, for the next 35 days.  If lots of senders
>> always encrypt when "available", then you won't get much of a test
>> period.
>
> Those senders are the target audience for prefer-encrypt=mutual. A major
> reason of being very shy about encryption by default is that as long as
> encryption remains an at least somewhat conscious decision for most
> communication peers, problems that might occur with particular
> recipients stay much more solvable at the social level.

I'm not sure this mechanism guarantees encryption will be conscious or
problems easy to resolve by the "nopreference" user.

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 that happens then setting "prefer-encrypt:
nopreference" won't be very effective for testing out Autocrypt with
low commitment.

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


I'm harping on the gossip and "nopreference" mechanisms because they
present new UI options for the sending user:

 * Lack of scoping in the gossip mechanism results in senders being
shown "discouraged but available" keys they could encrypt to.
 * The "nopreference" advertisement results in senders being shown
"available but not recommended" keys they could encrypt to.

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.

Asking users vague and confusing questions about keys seems like
exactly the sort of PGP usability failure that Autocrypt was supposed
to avoid.


Trevor