21–30 of 281 posts
I have some serious feels for the guy, that had to have been a frustrating experience.
Why even bother at this point? PGP encryption in email is... not a good way to do secure communication.
What’s wrong with PGP? Or are you referring to email
https://blog.filippo.io/giving-up-on-long-term-pgp/
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
https://blog.cryptographyengineering.com/2014/08/13/whats-ma...
https://www.techrepublic.com/article/why-pgp-is-fundamentall...
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?
Because there are too many users on SMTP/Email, but not many PGP users to worry about interoperating? I mean, Hey.com shows that people still like SMTP/Email.
People use email because everyone uses email; you're not going to get people to change how they use email entirely. Nobody cares that it's running on SMTP, they care that they can email everyone they know with an email address.
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 don't feel confident enough to actually try this project yet, but at least I wrote what my ideal chat app would be, oh and came up with the fancy name 'chattaur' for it.
36 comments, 1 day ago: https://news.ycombinator.com/item?id=24501872
226 comments, 2 months ago: https://news.ycombinator.com/item?id=23864934
51 comments, 12 months ago: https://news.ycombinator.com/item?id=21197327
How is the Thunderbird development speed nowadays?
That said it's a damn good product that's damn good at what it does.
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?
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-standard email" is ever so slightly less DOA. You get to re-use the existing identity/routing system, existing servers, existing authorization, etc.