Nice!

This is way more different thing than claiming and proving that Telegram is somehow FSB honeypot.

I did not claim nor attempt to prove that “Telegram is somehow FSB honeypot”. I did claim and I believe I showed that it is indistinguishable from an FSB honeypot. If you’re nit-picking, at least nit-pick the correct claims, instead of some straw-man version of what I wrote that happens to be easier to attack. 😼

Yes, OCCRP received funding from USAID. They put that information very clearly on their own website. Here’s a crazy thought: investigative journalism needs to be funded somehow, and USAID was one of the ways this could be done. If you have a better idea of how to fund investigative journalism, there is a lot of media outlets that would love to hear from you!

The way OCCRP was/is funded does not say anything about the veracity of their reporting. Or that of IStories, which was done independently of OCCRP (that’s an important bit that most people miss).

What does speak to the veracity of reporting is the fact that over a decade and a half of reporting on stuff like this OCCRP has been sued by oligarchs multiple times in the most oligarch-friendly jurisdiction out there, UK (specifically, London), and have not lost a single time. Will Telegram sue OCCRP or IStories? Perhaps. Will they win? I seriously doubt it.

If they do sue, the discovery will be hilarious. IStories folks are going to get access to all sorts of great documents, I’m sure. Can’t wait for these to get published!

Speaking of documents, I like how you quote two random claims made in that OCCRP version of IStories article, and just decide to ignore the bit where Vedeneev claims, in actual court documents, that yes he has access to Telegram infrastructure. And how there are documents showing he owns GNM. And how there are documents showing he also signed documents on behalf of Telegram (hilariously, a document exists that he signed both on behalf of GNM and of Telegram). And how he co-owns or co-owned companies which are also co-owned by people directly connected to the FSB. And a bunch of other stuff.

But that doesn’t fit your “US shill” hot take, so why mention any of that right? 😄

You might also want to read the Russian version of IStories story, for hard documentary evidence of Durov’s connections to FSB:
https://www.istories.media/stories/2025/06/10/kak-telegram-svyazan-s-fsb/

On a personal note, it is so much joy to see all the hand-wavy pushback in this thread. Clearly the story hit a pain point somewhere. The funny thing is that if similar but much less substantiated claims were made about Signal here, there would be a frenzy of dunking on it as an “imperialist tool of surveillance”. 🤡

Ooh, that’s a good question!

I am going to say Sperm Whales, if only because of how amazing they look while… sleeping vertically:
https://www.nationalgeographic.com/photography/article/sperm-whales-nap-sleeping-photography-spd

Autor blogu jednak stwarza wrażenie, że protokoły Matrix lub XMPP/OMEMO są słabe.

Nie “stwarza wrażenie”, a “oferuje swoją ekspercką opinię o tych protokołach, podpartą kupą doświadczenia i wiedzy, oraz dogłębną analizą.” To nie jakiś random z Internetów, a ekspert szeroko znany w kręgach związanych cyberbezpieczeństwem.

Aplikacja może bardzo dobrze uniemożliwić obniżenie poziomu komunikacji do postaci niezaszyfrowanej i odmówić przyjęcia komunikacji niezaszyfrowanej, nawet jeśli protokół pozwala również na pisanie komunikatorów bez szyfrowania

Może, ale jest to dodatkowa rzecz, która musi być dobrze, poprawnie zaimplementowana, i nie zepsuta przypadkiem w następnych wersjach. Kolejny skomplikowany element i tak już nieprawdopodobnie skomplikowanego systemu. A Matrix nie ma zbyt dobrej historii nie popełniania durnych błędów w implementacji własnego protokołu: https://arstechnica.com/information-technology/2022/09/matrix-patches-vulnerabilities-that-completely-subvert-e2ee-guarantees/

Mało tego, musi to też być dobrze zakomunikowane dla osób korzystających, które będą musiały zrozumieć to, że jakaś część komunikacji w danej aplikacji może być nieszyfrowana, i uważać na to, czy w danym momencie komunikują się w sposób szyfrowany, czy nie.

Powtarzam: tworzenie takich aplikacji jest nieodpowiedzialne. To zastawianie pułapek na osoby implementujące, oraz na osoby korzystające. Nie ma tu absolutnie żadnego usprawiedliwienia.

W powiązanym temacie, bezpieczne aplikacje internetowe są możliwe, nawet w świecie, w którym przeglądarki rozumieją niezaszyfrowany protokół HTTP.

Tak, i ataków downgrade na HTTPS były dziesiątki. Dekady zajęło doprowadzenie HTTPS to stanu jako takiego bezpieczeństwa. Zamiast powtarzać ten błąd i wystawiać się na takie ryzyko, lepiej po prostu nie wspierać wysyłania nieszyfrowanych wiadomości.

Chociaż nie poprawia to niczego dla prywatnego użytkownika końcowego, fakt, że siły zbrojne ufają niestandardowemu komunikatorowi opartym na Matrix z poufnymi informacjami

Masz rację, to nie poprawia niczego dla prywatnego użytkownika końcowego. Bundeswehra korzysta z własnej wersji klienta Matriksa (BwMessenger) – o ile się założymy, że tryb nieszyfrowany jest kompletnie wycięty? Mało tego, korzysta z niego we własnej, zamkniętej sieci. Idę o zakład, że ta sieć jest dodatkowo szyfrowana na niższym poziomie.

może wskazywać, że sam protokół nie implikuje słabego szyfrowania.

Sam protokół niczego nie “implikuje”, on po prostu dopuszcza możliwość komunikowania się w sposób nieszyfrowany. I to jest problem, którego porządny protokół komunikacji w 2025r. po prostu nie powinien mieć.

Prawdziwym żalem jest to, że obecnie nie wydaje się istnieć żadna aplikacja końcowego użytkownika, która byłaby otwarta, federacyjna, przyjazna dla użytkownika i bezpieczna.

Ja sobie patrzę na Cwtch z nadzieją: https://docs.cwtch.im/

Albo wystąpiłyby techniczne wady, albo byłaby scentralizowana, co narażałoby użytkowników na ryzyko uzależnienia od dostawcy i gównowacenia.

Ryzyko zgównowacenia istnieje zawsze, decentralizacja je zmniejsza. Zmniejsza je również na przykład nie bycie startupem mającym generować zyski dla inwestorów. Signal zarządzany jest przez fundację, która takim startupem bardzo mocno nie jest. Więc akurat nie mam problemu z polecaniem Signala, choć chciałbym, by był federowany rzecz jasna.

Takie gadanie, że wszystko do dupy, tylko utwierdza ludzi w przekonaniu, że to nie ważne, z czego korzystają, skoro wszystko syf. I zostają na Telegramie. Nie wiem, czy to jest efekt, na którym Ci zależy.

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.

Pracowałem z dziennikarkami i dziennikarzami śledczymi oraz ich źródłami, w tym osobami zajmującymi się publikacją Panama Papers. Odpowiadałem za ich bezpieczeństwo cyfrowe. Z mojego doświadczenia wynika, że wspieranie w jednej aplikacji szyfrowania end-to-end i wiadomości nie szyfrowanych w ten sposób wcześniej czy później doprowadza do tego, że ktoś nie ogarnia różnicy i komunikuje się w sposób nie szyfrowany end-to-end będąc przekonanym, że komunikacja jest w pełni szyfrowana.

Mało tego, nawet jeśli dana osoba korzystająca jest w pełni uważna i nie popełni sama takiego błędu, sam fakt istnienia możliwości wysłania wiadomości nie szyfrowanej end-to-end oznacza możliwość przeprowadzenia tzw. “downgrade attacks”.

Moim zdaniem, podpartym ponad dekadą doświadczenia w cyberbezpieczeństwie, tworzenie aplikacji, która miesza szyfrowanie end-to-end z nieszyfrowanymi wiadomościami jest skrajnie nieodpowiedzialne.

Jeśli możliwe jest wsparcie szyfrowania end-to-end w danej aplikacji, nie ma żadnego powodu, by jakakolwiek komunikacja odbywała się w jakikolwiek inny sposób.

Best I can tell it originated from a satire website. It is still hilarious.

This is a memes community. Take anything and everything posted here with a grain of salt. Or glitter.

You do realize this was posted to a memes-focused community, right?

Do consult your lawyer before throwing glitter bombs at masked, not uniformed kidnappers that might or might not be ICE agents.

Nie mówię, że te zapisy nie są gówniane, bo totalnie są, ale: w jaki dokładnie sposób miałyby wspierać akurat “monopolizację” fedi?

Zadziałał chyba tylko w kontekście “binding arbitrage waiver”. W ogóle dość śmieszne, że linia Gargrona to w zasadzie “no nie przeczytaliśmy własnego regulaminu”.

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 oczywiście ani słowa o tym, że:

1. Izrael jest jedynym krajem w regionie, który posiada broń jądrową.
2. Jak wojna się skończy i Netanyahu przestanie być premierem, możliwe, że pójdzie do więzienia.

Zdecentralizowane system też, choć oczywiście trudniej je kontrolować (o ile są wystarczająco rozproszone).

Nie można już w spokoju polecać usług komunikacyjnych, które nie są federowane.

Pewnie. Bardzo chciałbym, by istniała realna, zdecentralizowana alternatywa dla Signala, która zapewnia taki sam poziom prywatności i bezpieczeństwa. Ale jeszcze jej nie widziałem. Polecanie osobom korzystającym z Signala czegoś, co nie zapewni im podobnego bezpieczeństwa, jest nieodpowiedzialne.

Zdecentralizowane projekty, które wydają mi się obiecujące w tej przestrzeni (nie mówię, że inne nie istnieją, to bardzo subiektywna lista):

• Delta Chat
• Cwtch
• Veilid

Projekty, które warto wymienić (znów, subiektywnie), ale moim zdaniem mogą nie dać rady stać się realną alternatywą z różnych względów:

• Briar
• Matrix, wspominany już wcześniej
• XMPP

Oczywiście bardzo chciałbym się tu mylić. Jak Briar, Matrix, czy XMPP ogarną kiedyś bycie realną alternatywą dla Signala, fenomenalnie!

I bardzo dobrze. Szanse na wywrócenie stolika się pojawiają regularnie, tylko trzeba być na taką szansę gotowymi.

Fedi było sobie w cieniu i rozwijane po cichu przez dekadę zanim Musk przejął Twittera – a wtedy było już ~gotowe, i dużo na tym zyskało. Tak samo Lemmy.

Więc jak najbardziej taka praca u podstaw jest niezbędna i cenna.

Nie mówię, że XMPP nie ma przyszłości. Więc dobrze, że takie poradniki powstają.

Ale alternatywą dla Signala, w tej chwili, nie jest. Choć bardzo chciałbym, żeby było.

Ponieważ XMPP nie jest na dzień dzisiejszy potencjalną alternatywą, przynajmniej nie w zakresie prywatnej, szyfrowanej komunikacji. Mówię to z żalem, jako osoba, która odpaliła i zarządzała kilkoma serwerami XMPP już ponad dekadę temu. XMPP znacznie się poprawiło przez te lata, ale jeszcze sporo mu brakuje do zapewnienia odpowiedniego poziomu bezpieczeństwa:

OMEMO is not the worst attempt at making XMPP encrypted (see: XEP-0027 for that), but it still doesn’t meet the bar for the kind of private messaging app that Signal is, and is not a viable competitor to Signal.

To understand why this is true, you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can).

https://soatok.blog/2024/08/04/against-xmppomemo/

Cały post jest wart lektury, nurkuje w problemy z XMPP znacznie głębiej. Warto też przeczytać bardziej ogólny post Soatoka (linkowałem go w tym wątku poprzednio):
https://soatok.blog/2024/07/31/what-does-it-mean-to-be-a-signal-competitor/

W artykule nie sugeruję też np. Cwtch, który moim zdaniem jest ciekawszym podejściem do stworzenia w pełni szyfrowanej, zdecentralizowanej alternatywy dla scentralizowanych komunikatorów – ponieważ artykuł w OKO.press kierowany jest do osób raczej nietechnicznych, a Cwtch nie jest jeszcze gotowy na takie osoby korzystające.