“Telegram is not a private messenger. There’s nothing private about it. It’s the opposite. It’s a cloud messenger where every message you’ve ever sent or received is in plain text in a database that Telegram the organization controls and has access to it”
“It’s like a Russian oligarch starting an unencrypted version of WhatsApp, a pixel for pixel clone of WhatsApp. That should be kind of a difficult brand to operate. Somehow, they’ve done a really amazing job of convincing the whole world that this is an encrypted messaging app and that the founder is some kind of Russian dissident, even though he goes there once a month, the whole team lives in Russia, and their families are there.”
" What happened in France is they just chose not to respond to the subpoena. So that’s in violation of the law. And, he gets arrested in France, right? And everyone’s like, oh, France. But I think the key point is they have the data, like they can respond to the subpoenas where as Signal, for instance, doesn’t have access to the data and couldn’t respond to that same request. To me it’s very obvious that Russia would’ve had a much less polite version of that conversation with Pavel Durov and the telegram team before this moment"
Nope, sealed sender does not address the problem because the phone number is collected at sign up time. The whole sealed sender concept is just another trust me bro mechanic because, once again, nobody aside from people who are actually operating the server know what it’s doing. Signal is proof that vast majority of people don’t understand the basics of privacy and security, and they don’t actually care.
the phone number being collected at sign up just proves that you use signal
they can’t build any kind of social graph from it… they can only use the information contained in the message for delivery and rate limiting
Again, the only people who actually know what the phone number is used for are the people who operate the server. I don’t know why this is such a difficult concept for people to grasp. They don’t need the information contained in the messages. Once the phone number is collected, it CAN be stored and associated with your account. There is no way for you to know whether that happens or not unless you have access to that server. There is no way for you to verify that the server does what people operating it say it does. That’s what makes it a trust based system.
yes, i’m aware that you don’t know what the phone number is used for, but what we can guarantee is that it can’t be tied back to your message history, because again that’s what sealed sender is for. in order to send messages, you use a signed, derived value that has never been seen by the signal servers (since it’s derived) but is still signed (so signal knows it’s legitimate: they can validate your identity and rate limit without knowing it)
so whilst the phone number is associated with an account, that only allows them to know that you (person/identity) use signal… but that identity can verifiably not be tied back to any messages you send
nothing about that identity other than derived cryptographic data is ever sent along with your messages
*edit: i’ll slightly retract that: of course your IP address is also sent along with messages, and that may be able to be tied back to your identity… let’s say out of band, of course… so it’s on you to use a VPN or some other method to obfuscate your source IP address. i’d say that’s generally applicable to any other service too
Prove it. And not from some just trust me bro statement from signal.
replied to your other msg, so i wont duplicate it here and we can continue there if you’d like
Again, nowhere did I talk about message history. What I’m talking about the server having unique ids for each user, which is how it connects users to each other, and having a phone number collected initially which can be tied to that id. You don’t need anything from the messages themselves to create a graph of people who talk to each other. The routing is done by the server.
but in that chain what you really care about is your phone number that identifies you in the real world to your messages, right?
yes, and the only thing you need to route is the receiver; not the sender
the sender is only used to validate the senders identity, and for rate limiting
sealed sender solves both of these problems whilst not including any sender information in messages… phone number or user id doesn’t matter: those things are not sent along with any of your messages, and that’s verifiable
your phone number and user id is only known by signal when you retrieve a temporary token (this solves rate limiting: the retrieval of the token is the rate limit, and each token has a limited number of messages it can send)… the client then derives a different key from it, which can still be verified as having been signed by the server, but does not contain any information that can be tied back to your phone number or user ID
It doesn’t matter, what matters is that the server has a unique id for you and the person you’re talking to, and that id can then be mapped to the phone number that was initially collected. That’s all the server needs to identify the real identity of the people you communicate with.
It’s not a question of what the server needs minimally, it’s a question of what the server could be doing if it was set up maliciously. The sealed sender does not solve this problem in any way shape of form.
the key point missing in the middle here though is that the IDs aren’t what matters: it’s having the ability to link those IDs
and i agree, being able to link you->your phone number->your user ID->message->recipient ID->recipient phone number->recipient as an individual is a problem
but again, sealed sender break that chain: there is cryptographically no way to link your user ID to the message you’ve sent
it’s literally impossible for them to build a social graph from your messages
again, i agree… kinda… i put that there to show that you don’t actually need the sender to achieve the goal of delivering the message. it was part of the explanation of why sealed sender works, rather than a point to be made by itself
would you be able to explain how it doesn’t?
sealed sender divorces your user ID from any message you send… your messages can not be tied back to your user ID or phone number without having decrypted the message content
so even with a malicious server, because you can verify your client behaviour (that it derives keys, and that you can verify the message payload contains nothing outside the ciphertext which is unexpected), then even a malicious server (without IP information) doesn’t have the information necessary to infer the sender from the sent message
Again, sealed sender has nothing to do with it. If I run a server, I have access to the raw requests coming in. I can do whatever I want with them even outside Signal protocol. You can’t verify that my server is set up to work the way I say it is. You get that right?
You’re confusing what Signal team says their server does, and the open source server implementation they released with what’s actually running. The latter, you have no idea about.
The core issue is trusting the physical infrastructure rather than just the cryptography. The protocol design for sealed sender assumes the server behaves exactly as the published open source code dictates. A malicious operator can simply run modified server software that entirely ignores those privacy protections. Even if the cryptographic payload lacks a sender ID, the server still receives the raw network request and all the metadata attached to it. Your client has to talk to the server and identify itself before any messages are even sent.
When your device connects to send that sealed message, it inevitably reveals your IP address and connection timing to the server. The server also knows your IP address from when you initially registered your phone number or when you requested those temporary rate limiting tokens. By logging the raw incoming requests at the network level, a malicious server can easily correlate the IP address sending the sealed message with the IP address tied to the phone number.
Since the server must know the destination to route the message, it just links your incoming IP address to the recipient ID. Over time this builds a complete social graph of who is talking to whom. The cryptographic token merely proves you are allowed to send a message without explicitly stating who you are inside the payload. It does absolutely nothing to hide the metadata of the network connection itself from the machine receiving the data.