Hacker News Reader

Comment by edelbitter | Hacker News Reader

Public key encryption as in DANE already achieves what can be achieved given the constraints. I have seen some purpose-built apps that use email for auth and then establish a different channel to exchange the documents. But that just nets the security properties that you already had with email.. just with some added methods of sideloading trojans past those pesky email attachment scanners. Turns out, you cannot just sprinkle some "encryption of some sort" magic on top of an already encrypted channel (which was inadequate in auth, not in confidentiality) and get a meaningful improvement from that. Instead, it subtracts from the already way too limited budget that people trying to get actual work done can spend on establishing who they are talking to through distinct comms channels. Not sure what the purpose of those apps even is, other than generating some $$ for the provider (in the most egregious case, Cisco).

View on HN

Christ, ease off the condescension, I'm very obviously not talking about "sprinkling in" domain name authentication, but encrypting the data for an eligible recipient using a suitable root of trust.

You're discussing this as some inachievable science fiction that would require every employee to learn how to use gpg. In reality this could be achieved through a simple to use website.

In fact this is a solved problem. My doctor is not legally allowed to email me my own medical records, not even the most mundane blood test result. Instead they send them through the government-operated portal which employs suitable authentication and prevents any sort of transport-level hijacking.

There is no excuse to be using non-e2ee email for this in 2026. None.

What is the difference between making sure an HTTPs endpoint does not leak and making sure an IMAPs endpoint does not leak? I do not see much of a fundamental difference.

Except, it makes the user experience worse: I can certainly make it infinitely more tedious to open the document exchange site of $superimportantcompany on superimportantcompany.co (or was it .com? or .co.uk? or important-company-le.ai?), and spread out "my" inbox across 30 different sites and spend additional time navigating their unique interfaces to not just read, but also add each document into the appropriate local archive. But what have I gained in making it more likely that each correspondence is kept confidential between the only parties that should read it? Nothing beyond what I started with. Could have stayed with email, no?

I can see the appeal of mitigating part of the usability problem by pivoting straight to bundling up all thematically related messages into centralized repositories to limit the number of pseudo-mailboxes one has to maintain simultaneously, as done in the recent "everything medical related" cases. But someone would grab a full copy in the inevitable compromise, and that is a risk that should rather stay scoped to smaller groups of senders and/or recipients. It seems like a bad tradeoff to force every blood test of everyone into the danger zone for that, given that one could have instead spent 3% of the budget on.. merely policing away the DNS warts in public authorities (or, in the medical example, insurance companies) while keeping data custody unchanged.

The document exchange site isn't hosted by each individual company, that would obviously be ridiculous. There's only one and it's hosted by the government. I already said that in my previous comment but you chose to attack a straw man instead.

Reply on news.ycombinator.com