Is this the longest time between request/bug and fix?
16 years and still pending! All bets are off for this dark horse
31–40 of 281 posts
Is this the longest time between request/bug and fix?
16 years and still pending! All bets are off for this dark horse
I do think there ought to be a way to do good cryptography in email. Email is not going away anytime soon, so giving up on it as a legitimate place where cryptography is needed seems too ivory tower for me. The “dead simple solution” is to just run the Signal protocol over SMTP, although I’m sure it’s possible there is a better design if you were to think about the specifics.
I do think there ought to be a way to do good cryptography in email. Email is not going away anytime soon, so giving up on it as a legitimate place where cryptography is needed seems too ivory tower for me. The “dead simple solution” is to just run the Signal protocol over SMTP, although I’m sure it’s possible there is a better design if you were to think about the specifics.
It's a much better user experience, and honestly I'm surprised that no enterprise orgs have adopted it, because it would probably be cheaper than all this phishing training.
I do think there ought to be a way to do good cryptography in email. Email is not going away anytime soon, so giving up on it as a legitimate place where cryptography is needed seems too ivory tower for me. The “dead simple solution” is to just run the Signal protocol over SMTP, although I’m sure it’s possible there is a better design if you were to think about the specifics.
Not if you want to interoperate with anything currently in existence. And if you don't, why bother building it on SMTP?
How is the Thunderbird development speed nowadays?
Pretty moribund. They got dropped by Mozilla so it's entirely community-driven, and there's only so many things you need to add to an email client, unless you want it to turn into emacs or something. That said it's a damn good product that's damn good at what it does.
It fails to associate my accounts with my keys in my keyring, so I try to import an exported key. Whenever I do this, it gets stuck in a loop asking me for the passphrase for an old, revoked key :( Even after I deleted the revoked keypair -- which I know I shouldn't -- it's refusing to cooperate.
So it looks like I've actually lost this feature by upgrading...
Good for them, but PGP is essentially dead for any non-technical zealot users. S/MIME is better supported and easier to use.
I do think there ought to be a way to do good cryptography in email. Email is not going away anytime soon, so giving up on it as a legitimate place where cryptography is needed seems too ivory tower for me. The “dead simple solution” is to just run the Signal protocol over SMTP, although I’m sure it’s possible there is a better design if you were to think about the specifics.
S/MIME is the closest to dead simple solution, but it requires trusting certificate authorities. It's a much better user experience, and honestly I'm surprised that no enterprise orgs have adopted it, because it would probably be cheaper than all this phishing training.
1. At least until recent, Microsoft implemented it as blocking code in the UI thread – open a message and Outlook won't paint until it can verify the cert, access your local key store (hope your token is in a USB port which is 100% reliable), etc. If you thought “Does that mean that revocation checks block the UI until a network process completes?” you're sadly right.
2. Adoption hasn't been enough to be able to ban untrusted senders. This could still be quite useful for, say, a hard requirement that *@example.com must have signatures but it doesn't help with really common phishing tactics like pretending to be a vendor, business partner, etc.
3. You definitely need to get serious about key management because your ability to read your old encrypted email depends on retaining those keys. This is obviously not impossible but it has a cost when you think about the need to store them securely in a manner which can be restored after the inevitable system failures and compromises.
Earlier quoted context omitted.
Not if you want to interoperate with anything currently in existence. And if you don't, why bother building it on SMTP?
You build it on SMTP because upgrading clients is easier than doing a clean slate redesign of ubiquitous internet protocols. Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack -- and in those cases you want to maintain as much compatibility as possible. "Federated SecureEmail 2.0" would be dead-on-arrival, where "Secure Client on top of bog…
Why not just toss the whole shebang and rebuild it below that layer? Signal Protocol seems to be pretty successful here.
>Presumably we're discussing how an open protocol addition might gain any traction at all over walled garden protocols like Slack
No, I'm asking how a new open protocol can be built on top of email in a way that maintains strong backwards compatibility while offering strong security guarantees, like end-to-end encryption. I don't think it's possible.