Hacker News new | past | comments | ask | show | jobs | submit login

Signal has no concept of trust delegation: also, the verification API is extremely hidden and sucks (i.e. my brother working at a FAANG had no idea it existed or what it did - it's also extremely confusing when you open it).

This creates two problems: (1) is that Signal functionally operates as "trust on first use", and (2) Signal has no system by which you can communicate to "conceptual entities" - i.e. companies. There's no way in Signal to talk to say, a bank or a government agency as an entity (IMO: to turn a profit, this is the business Signal actually need to be in).

Which makes it a bit of stochastic security measure: encrypt enough communications and probably when something important does come up, the window to intercept it has failed - except of course, that those verification number messages nobody knows what to do with and so they ignore them.




> (2) Signal has no system by which you can communicate to "conceptual entities" - i.e. companies.

This has always kind of bugged me with email as compared to physical mail: While with a physical mailbox I can write a letter "to whom it may concern" and throw it in, with email I need to find out if the special, general purpose inbox is info@, contact@, hello@, or whatever other address the company uses, assuming they use the same domain for their email as they do for their website.

On the next level, there is no first-class support for stuff like 'send this message to person X, although it is adressed to organisation Y, where X works.' Basically, acknowledging the legal and organisational reality that while (single) humans might read, process and respond to communication, it is the legal entity that is actually being adressed.


There is a standard for this, most US companies I encountee over 100 people seems to support at least the security, info, postmaster, and support mailboxes at least.

https://www.rfc-editor.org/rfc/rfc2142


I agree that the verification UI sucks. I have similar stories about otherwise technical people not knowing about it or otherwise not understanding it.

At the same time: the relevant comparison here is email. Email isn’t even TOFU between arbitrary identities; it’s trust-on-each-message. Similarly for conceptual identities (like a bank’s catch-all address).

(I also agree with your point about this needing to be one of Signal’s businesses. WhatsApp and other chats already do this, I believe.)


Email these days is however tied to DKIM and domains. We have UI problems, but communicating to a companies email servers at their domain name can be reasonably expected to be communicating with that company.

It's just the security story on that if you never want the content disclosed isn't great, but conversely, conceptual entity communications are always going to be a bit public by nature.

There's a whole other rant I have about this problem, where we really lack domain specific trust standards - i.e. communicating with a business, what I want to know is "is this a recognized legal business entity in it's jurisdiction, and what's it's status to mine?" which is very different to "I need to make absolutely sure me and John Smith's communication is just between us" - but they're in the same space of problem.


> There's a whole other rant I have about this problem, where we really lack domain specific trust standards - i.e. communicating with a business, what I want to know is "is this a recognized legal business entity in it's jurisdiction, and what's it's status to mine?"

I have the same pain, but this seems more like a regulatory issue than a technological one. Here in Germany, (basically all) legal entities need to publish a physical adress where they are reachable, it would be easy, in theory, to extend this to a reachable domain or email adress, thereby giving a guarantee, at least in Germany, that you are interacting with the business you are expecting. As you said, DKIM already exists.

Unless I have missed your point, then rant away.


DKIM is an anti-spam tool, not an end-to-end encryption tool (obviously, it's not end-to-end at all, and if you're relying on it, you might as well forget about message encryption, because you've simply decided to trust your server).




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: