"email can't practicably be made secure, and people should stop trying." It's already been done as I've told you before: they're called encrypting proxies and

"email can't practicably be made secure, and people should stop trying." It's already been done as I've told you before: they're called encrypting proxies and mail guards [1][2]. A few ran on OS's that passed NSA pentesting while all the other stuff failed. So, they can be done to much higher security than most things you use or recommended for risk mitigation. There's FOSS tooling available to build modern versions in medium or high security should anyone want to try. Tooling is better than ever for plugging leaks or knocking out code injections without having teams of pros doing all the work. There's also companies selling modern versions for businesses wanting some protection for legacy usage, except not on the secure OS's anymore. So, you're just ignoring prior work again like you did when you dismissed separation kernels because you didn't know high-assurance, security field designed secure, browser architectures or integrated existing ones. Being archaic, secure email does have issues to solve with residual risks that can happen with new solution integrating with legacy tech. Best it will get with current setups is medium-assurance like with most internet protocols, common platforms, and so on. Still useful to build security tech for it given how pervasive email is with too much inertia to eliminate if we're about protection of lots of users and critical activity. "Most email users get their email from a website. " "And where by "agony" we mean "innocent people being put at risk"." The other thing I noticed about this post is a double standard your pushing. When I talked secure OS's, you argued they shouldn't be taken seriously unless they have a browser. The implication was that browsers were a pervasively-used tool (like email) that we should (a) support since in demand and (b) secure to be responsible. We had to do what's practical supporting them even though they're the source of most compromises. Now, when talking email, you're saying people should ditch it for totally-different mediums without the strengths of email (i.e. less practical for their needs). That we should not be practical since it would be irresponsible to push a tech or app with high-compromise potential that could put innocent people at risk. That is, putting people at risk just like browsers do versus using secure, simple, native apps (esp memory-safe) or less-sophisticated formats for documents. Maybe you changed your mind about browsers with you now recommending whatever are the Signal's of document exchange or web-app alternatives. Otherwise, you've done for one medium what you say shouldn't be done for the other. Interestingly enough, those who listen to you that avoid email for messenging apps, but who use browsers, might have their messages stolen anyway from that point on when the browser gets hacked. Among other problems following a hack. "We should stop trying to push this particular boulder up this particular mountain and instead just get people to adopt serious secure messengers." Again. Let me rephrase to illustrate: we should stop trying to push secure versions of (insanely-popular, legacy tech not going anywhere) to get people to quit using it in favor of secure alternatives that don't have benefits that led them to the other one in the first place. I can think of email, browsers, online storage for files, desktop OS's, ISA's, and so on that inherently have risks that we can't fully eliminate. It's insanely impractical to get people off this stuff for clean-slate, secure alternatives. You're making an exception for email expecting people to move mountains changing all the inertia. We do agree that security pro's should get people off email where we can where their requirements don't truly dictate email. We still need secure email, though, for those that won't or can't stop using it. That's only if we're about protecting innocent people, business activities, government practices, and so on who are all over email. [1] An early one https://cryptosmith.files.wordpress.com/2014/10/mailguard.pdf https://cryptosmith.files.wordpress.com/2014/10/mailguard.pd... [2] General concept with newer ones https://en.wikipedia.org/wiki/Guard_(information_security) https://en.wikipedia.org/wiki/Guard_(information_security)