A Symbolic Software report was commissioned by the former CFO of Telegram (Vedeneev) in a Swiss lawsuit, attached with the hope that experts would refute an IStories report. Instead, it confirmed the findings. And then it became discoverable.

This post is about how the defendant in a Telegram case produced technical evidence against himself, and a rebuttal page got pre-positioned against an article whose core claims were already confirmed in writing by the litigant’s own expert. Whew. Ready?

Let me begin with the end of the story. Telegram pre-published a rebuttal to claims, which deepen the hole they have been digging for themselves. Three points stand out:

1. The rebuttal from Telegram claims their an auth_key_id “changes regularly.” Does it? What is regularly? The independent expert review claimed the opposite that it “remains constant across sessions, IP address changes, network switches, and geographic locations.” This contradiction is out in the open for scrutiny.
2. Telegram claims infrastructure is “configured, managed and controlled exclusively by Telegram’s internal engineering teams.” Vedeneev told IStories on the record: “Telegram doesn’t have access to the data centers in Singapore or Miami: they’ve never been there. Four data centers have already been built. We are present in all four. At this point, I provide all communication channels. Not someone else — me!” That’s a hard inversion.
3. Telegram floats a denial that “GNM/Vedeneev not connected to the FSB”, which sits within Vedeneev’s own description of an assigned FSB handler, authorized email accounts for FSB IP-to-identity lookups, and his admission “We understand that we can’t not answer.” Telegram does not address the SORM-servicing contract; it addresses only physical residence and current business operations in Russia, which are not the relationships at issue.

All that nonsense, before we even get to the interesting technical issues?

While people speak about a privacy leak allowing users to be tracked, I hope they also consider that auth_key_id as the server-side lookup handle for the per-device auth_key that Telegram uses to terminate the MTProto transport.

The exposed identifier sits one hop away from the decryption boundary for everything that is not a secret chat, which is the overwhelming majority of Telegram traffic. Non-secret chats are stored server-side under keys Telegram controls. An adversary positioned to harvest auth_key_id values on the wire is positioned at the same infrastructure that terminates the transport and reaches the plaintext store. The expert review was about tracking, but I see an architectural can of worms that is much, much larger.

Telegram meanwhile claims their auth_key_id is just pigeon poop by design. Literally. They say that on telegra.ph.

That is like claiming someone can track your car using pigeon poop on the windshield when they can already see the color, model, direction, speed, and approximate location of any car.

Not to take a tangent, but pigeon poop studies claim certain car brands and colors are targeted more than others.

I also should point out this rebuttal was published May 4, two weeks before the article that it criticizes was released.

Regarding the unpublished article, we reject its conclusions

Telegram replied to an unpublished article in enough detail to draft three sections of technical and reputational defense. The Swiss court discovery exposed the Symbolic Software findings to Telegram. Their rebuttal therefore was most likely a response to discovered expert evidence that Telegram knew would be published. Or the FSB has bugged journalists, but that seems hard to prove.

Speaking of hard to prove, the rebuttal page is signed Telegram, yet it isn’t a corporate domain, isn’t a known spokesperson, doesn’t cite documentation, and most of all doesn’t actually clarify the rotation interval for the auth_key_id. Instead it’s just a branded bunch of analogies and attacks on characterizations.

Here are some clear examples. The generic argument from Telegram that someone “can already see better signals” is bog-standard misdirection to obscure a persistent identifier. A tracking primitive that has cross-session linkability under adversarial conditions makes it different than the others: IP rotation, NAT, VPN cycling, mobile-to-wifi handoffs. If auth_key_id persists across these and rotates on a longer cycle than IPs change, it provides correlation that no other listed signal provides.

Then they make a TLS session ticket comparison.

TLS, the protocol used by most web services and recommended in the article, itself allows a much easier way to link connections from the same user: whenever your browser reconnects to a site over TLS, it typically presents a session ticket in cleartext. This is standard behavior across much of the web.

This is the most technically dishonest part of the rebuttal. A session ticket’s contents are encrypted to the server’s key, but the ticket bytes are visible on the wire, and that visibility is what enables linkage when a ticket gets reused. Modern TLS treats tickets as effectively single-use for this reason, so a given ticket value typically appears in one resumption handshake before rotating. An auth_key_id, by contrast, is bound to a long-lived device key (the auth_key) and appears in cleartext on every MTProto message of every connection. The comparison equates a single-use, resumption-only linkage primitive with a persistent device handle observable on every packet for the lifetime of the device authorization.

And I can’t point out enough that “frequently rotating” depends entirely on the interval versus collection threats. If Telegram is talking days, it persists across most movement. If they mean hours, across most sessions. The rebuttal has no actual interval, which is the single quantitative claim that would settle the question. That omission is a serious problem with the rebuttal.

And the glass-building metaphor rounds out the pigeon poopery. If they are going to admit the window exists, why bother going on another minute? The window exists. For a state-level passive collector at a peering point operated by the alleged compromised party, every persistent identifier matters, because correlation across rotating signals is the entire point of the article it’s supposedly refuting.

Each section in the rebuttal was setup to weakly characterize a future article’s claim, then attack that characterization instead of the actual facts of Telegram. The analogies (pigeon poop, electrician, fuse box) make the argument sound absurd in order to avoid engagement with the substance of the criticism. And then the technical claims are drafted as legal statements prepared for cross-examination, using carve-outs and narrowing modifiers to reduce liability by avoiding clarity.

After all that, I suggest you read thoroughly the Symbolic Software report on Telegram, as presented today by IStories: “Independent Review Confirms Critical Telegram Vulnerability Previously Exposed by IStories“.

While researching an alleged Cloudflare blackmail of Canonical, I came across CEO Matthew Prince’s Twitter statements in January 2026 about an Italian fine over Piracy Shield non-compliance.

In a far-reaching decision, the Italian Communications Authority Agcom has fined infrastructure giant Cloudflare exactly 14,247,698.56 Euros

Notably, Prince responded with fascist propaganda aesthetics to frame himself in a battle with grotesque “dark” skinned Europeans.

Cloudflare’s CEO spread overt fascist imagery. Two months later his legal team launched a compliance narrative like “new Trump phone, who this”?

Cloudflare’s legal department published a sanitized cleanup in Italian claiming an appeal, quietly disappearing every Vance reference, every Musk endorsement, every Olympics threat from January. They tried to refocus on Digital Services Act arguments that had been available to the company from the start, pretending as if the CEO hadn’t already made the bed they were lying in.

I also ran through competitive analysis and it was clear that Google complied, OpenDNS quietly withdrew, and Akamai got blocked without theatrics. Only Cloudflare had a CEO who openly engaged in spreading fascist propaganda, taking time to “appreciate JD Vance”, weaponizing the dispute into a Trump-aligned political campaign against European regulatory sovereignty.

Go figure.

Perhaps that DDoS pressure on Canonical, until they gave in to a Cloudflare contract, is somehow related to the CEO rants and ravings in January, 2026 if not earlier.

Russians in Germany pretend they are German to acquire military technology and then launder it through Turkey.

According to the investigative file produced by the German prosecutor’s office, Nikita S. stood at the center of a system that began as a conventional trading business and, after Russia’s full-scale invasion of Ukraine, became what investigators suspect was a European procurement arm for Moscow.

On paper, the operation revolved around Global Trade, a mid-sized trading company based in Lübeck. Before the war, the company exported directly to Russia. But after Western sanctions tightened, the files show, its business model changed. Direct shipments were replaced by a more elaborate structure designed to disguise the Russian end users.

[…]

The scale was recorded in the network’s own documents. A spreadsheet titled “Nikita’s order list” tracked thousands of transactions from request to delivery, listing order numbers, products, prices and delivery status. Prosecutors believe the operation moved roughly 16,000 shipments worth more than €30 million, Ines Peterson, spokesperson for the Federal Prosecutor’s Office, told BILD.

Seawater desalination technology is said to fit Russian nuclear submarines, for example. What else?