Hi, author here. First of all, in that piece I don't happen to recommend using any specific piece of software. I mention Signal and WhatsApp for comparison, as tools that are considered similar, and yet avoid making the same weird protocol choices.

Secondly, if you have any proof that any specific communication tool is used to "spy" on people, I am sure I am not the only person who would love to hear about it. That's the only way we can keep each other safe online. Surely you wouldn't be making unsubstantiated claims and just imply stuff like that without any proof, would you?

And finally, I've spent a good chunk of time and expertise on analyzing Telegram's protocol before I made my claims. I provided receipts. I provided code. I explained in detail my testing set-up. You can yourself go and verify my results.

Instead, you claim it's "propaganda", while mischaracterizing what I say in that post. Classy!

Thank you, that's really great to hear!

AMA is AMA

What have I done.

What lead you to dive into examining Telegram?

I do information security work, and I used to work closely with investigative journalists hailing from Russia, Kazachstan, Ukraine, and other places in that general area. Telegram is massively popular there. Because of this Telegram has been on my radar for a very long time as a serious security threat – not just because its protocol and management are suspect, there are plenty of other IMs like that, but also because of how many people I worked with had used it.

I've written about Telegram before, on amore general level (linked in the blog post), so when IStories reached out to me for comment on this it was a good inspiration to dive deeper.

How would you use it if abandoning it is not an option, safety-wise, on android? Like, opening it in browser instead, killing app from the background, or using some app\tool? Not using it for anything sensitive is obvious.

I would not use it. I refuse to accept that abandoning it is not an option. There are plenty of options. It's always a decision one can make.

Please remember that even if hypothetically you could use it in a way that protects you from the spying – something I am very, very doubtful of! – the mere fact you are using it sucks other people into using it. You personally become one more reason for someone to start using or keep using Telegram. You personally become one more "user" of Telegram, justifying another media organization or NGO to set up or maintain a presence there – which in turn pulls in even more users into the dragnet.

In other words, your decision to use Telegram anyway, even though you know what the issues are, becomes one of the many things that make other people feel that "abandoning is not an option". I refuse to be a part of that. The only thing I can recommend is to stop using it.

What are other potential worms is in there you may think of? Recently, Yandex and Meta analytics tools got caught in sending browsing data to phone’s localhost - where their locally installed apps caught it and sent back home. If the FSB conection is that deep, there is no end to what they’d want to mine from users.

I think this hits the nail on the head: If the FSB conection is that deep, there is no end to what they’d want to mine from users.

I don't want to speculate. The possibilities are vast. But I will say what I said in the blogpost: Telegram is indistinguishable from an FSB honeypot.

I don't trust Telegram the company, I don't trust Telegram the software, I don't trust MTProto. I certainly do not trust Pavel Durov. I don't think we need to speculate on what more could possibly be hiding there, what is already known about Telegram should really be enough to stop using it.

Heh, thanks. AMA I guess.

they already who which user is which IP from the servers they control
(...)
when they already control Telegram’s servers

Who is "they" here?

If you meant "the compromised provider" here, then no, we cannot assume they know which IP address is used by which user. Full disk encryption exists, you can rent a (physical, dedicated, as is the case here) server from a provider and set it up in such a way that you can be reasonably sure that the provider does not have access to the data on the server.

So in that case the provider would only see the traffic without the ability to connect easily IP addresses with actual devices or users. That is not enough to reliably track anyone long-term, as IP addresses change in ways that often make it difficult to figure out if some traffic comes from the same user/device or not – especially when you travel. But add an identifier visible directly on the wire, like the auth_key_id, and you can pretty easily say "yes, this new IP address is now used by the same device".

If you mean "Telegram", and assume Telegram cooperates fully with the FSB, to the point of providing unfettered access to data on Telegram's servers, then sure. But I cannot prove that, and neither could the IStories team. Can you? You can of course make any assumption you want to (and I am not saying your assumption here is necessarily wrong – only that I cannot prove it), but when I publish I can only work on things that I or somebody else can prove.

And in this story, I can prove that Telegram's protocol has a very weird, unexpected "feature" that combined with IP address allows anyone with sufficient access to track Telegram users. I can show that this feature is not necessary in such a protocol – other protocols used by other similar tools do not have that issue. And IStories team seem to be able to prove that all Telegram traffic flows through a single infrastructure provider that has ties to the Russian FSB.

That's all we got currently, but that's already plenty. Because both of these are decisions made by Telegram, and they strongly reinforce one another.

It just seems like an incompetent implementation.

If that was the only weird technological decision by Telegram with strong consequences for privacy of its users, I could agree.

But as I discuss at length in that blogpost, Telegram has a long, long history of such "incompetence"; they also tend to react badly to anyone pointing this kind of thing out. The auth_key_id issue has been pointed out years ago and not only is it not fixed, there is no indication that Telegram even considers fixing it.

Can you imagine the veritable shitstorm if Signal pulled something like that?

As I wrote in my blogpost, in the end it does not matter if this is incompetence or malice – the end result is exactly the same.

I hate it when I don’t know an acronym, but this one is particularly hurtful to my brain since everyone is saying “yeah, that link to the FSB was obvious glad someone demonstrated it.” So… I will just assume FSB=KGB and be done.

Russian FSB is the successor of the Soviet KGB, so yeah, that works.

Take for example Tor network (high number of exit nodes are controlled)

I substantiated my claims about Telegram by a pretty deep technical analysis. Mind at least providing a link for your pretty strong claim about Tor?

Except those apps or protocols that are truly decentralized (e.g. OMEMO in XMPP), these are good.

Nope. Decentralization is important from power dynamics standpoint, but can actually be detrimental to information security due to (among others) metadata and complexity.

I would most definitely not recommend Matrix for private or sensitive communication, no.

https://soatok.blog/2024/07/31/what-does-it-mean-to-be-a-signal-competitor/
https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/

Matrix is fine as IRC replacement, it might also be a decent replacement for Telegram's channels thingy, sure. But I would not trust my family photos to it. Much less anything actually important.

For the internet messenger functionality that would be Signal.

For other things (channels, mostly), anything that does not pretend to be end-to-end encrypted when it is not. A website with an RSS feed would be one trivial choice for channels that are open to anyone. Public communication like that has no business going through "platforms".

Also, AMA I guess.

Transparency though. 🫠

HAproxy cannot serve static files directly. You need a webserver behind it for that.

Apache is slow.

Nginx is both a capable, fast reverse-proxy, and a capable, fast webserver. It can do everything HAproxy does, and what Apache does, and more.

I am not saying it is absolutely best for every use-case, but this flexibility is a large part of why I use it in my infra (nad have been using it for a decade).