> 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 _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
