On Sat, Dec 23, 2017 at 11:11 AM, Vincent Breitmoser <look@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 _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging