[messaging] Autocrypt 1.0
trevp at trevp.net
Sat Dec 23 11:46:49 PST 2017
On Sat, Dec 23, 2017 at 11:11 AM, Vincent Breitmoser
<look at my.amazin.horse> 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
> 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
If "nopreference" is intended to require explicit sender action for
each encryption, it should perhaps be renamed, and this requirement
>> 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.
More information about the Messaging