Large publicly traded tech companies seem to no longer consider their customers – that is, people and organizations who actually buy their products or pay for access to their services – their core focus. The focus has instead turned towards the stock price.

Their real clients, the entities they really care about, are the stockholders. Reasons are many, perhaps one of them being that people making decisions tend to own stock options or have bonuses tied to stock performance of the companies they run.

This means that for a large, established tech company the product or service it offers does not matter all that much anymore. It needs to be just barely good enough to keep people using it. The easiest way to do this is some form of a monopoly.

Monopoly is the business model of Silicon Valley, and they are not even shy about that.

Monopoly as a business model¶

If you ever tried moving an organization wholesale from Google Workspace to Microsoft 365 (or whatever it is called this week), you know what I mean.

These are two sets of office productivity services; on a basic level their functionality is very similar. Mail, calendar, contacts, document editing, access controls, and so on. And yet you can’t even directly share a file from Google Workspace to a person who uses Microsoft 365 (or vice-versa) in a way that would allow them to access it within their own service, using their existing account, without manually exporting and importing the file.

Sidenote¶

This lack of basic interoperability is not a technical necessity but a business decision. For example, Open Cloud Mesh protocol allows for a lot of interoperability between providers of such office productivity services, and is implemented by Nextcloud.

What this means in practice is that two people with accounts on different independently-run instances of any software implementing this protocol, hosted at two different providers, could not only share, but collaborate on a file – each from their own account, using a familiar interface.

Someone confidently using one of the two largest online office suites can quite reasonably feel completely lost when presented with the interface of the other. Interoperability and data portability between them seems like science fiction, to a point where it is genuinely difficult for some people to even understand the concept.

Barriers to migration¶

What this means in practice is that it does not matter if people using their services hate them – it only matters that they don’t hate them strongly enough to want to go through hell of migrating over to some other (or the other) provider.

With a barrier to migration between providers this high, people using the service can be exploited in all sorts of ways they could not have been otherwise. Cory Doctorow aptly calls that enshittification.

At the same time, though, this also makes it really difficult for service providers to compete on quality of the service or its features. It’s not enough to have a product that is just a bit better than the competition. It has to be so much better that it makes it worthwhile for people to go through the hell of migrating over. That’s a tough sell – that’s kind of the point of creating these barriers in the first place.

And yet the line must go up. Somehow, tech companies need to convince investors that their services are really becoming so much better – so that they keep paying more and more for company stock.

Enter the hype.

Learning to ride the Gartner cycle¶

Hype, of course, is nothing new. Gartner even made a graph about it, a long time ago.

Using hype to sell products barely anyone actually needs for prices that make no sense has a long and storied history – so much so that “tulip mania” has basically become a cliché. Using hype to scam people out of their money outright (instead of selling them something tangible, albeit at an unreasonably inflated price) is also not particularly innovative. Just ask Elizabeth Holmes.

What’s new here, I think, is large, established companies using hype not to push products or services, but to push their stock. And doing so in unison, pumping the same bubble together. Smartphones, office suites, image editing software, social media services, graphics cards, CPUs, washing machines, laptops, cars are all just incidental vessels for pushing AI hype.

Big Tech paid close attention to the cryptocurrency and NFT bubble. They tried to get in on it, but they mostly failed. Probably the most useful thing that emerged from the whole NFT frenzy was that Twitter’s erstwhile hexagonal profile pictures for NFT holders made it trivial to block cryptobros for a time.

Then, Facebook tried to manufacture their own hype bubble with Metaverse, somewhat piggy-backing on NFTs – and even changing the company name (partially to distract from their culpability in Rohingya genocide). Metaverse was inevitable. Anyone not on the Metaverse would unavoidably be left behind.

Mark Zuckerberg bet the shop on that particular hype. The shop lost 46.5 billion-with-a-b USD on it. Zuckerberg took “full responsibility” by firing eleven thousand people.

Today Meta is pivoting to – you guessed it – AI.

Pivot to AI, whether you like it or not¶

“AI” is not the only hype game in town (Amazon for years tried to hype drone delivery as the obvious future, for example), but it seems almost tailor-made for huge tech monopolists.

It requires insane resources and access to unfathomable depths of training data, creating a barrier for any potential newcomers. It is just futuristic enough to sound like magic and get people somewhat excited even though many of us are so, so bored with tech – but at the same time not too out there, so that “Serious People” (i.e. large stockholders and rich investors) can pretend to have intelligent conversations about it. It can mean anything under the Sun. And it is pretty easy to integrate with existing services (in the end, it’s all just text).

Since Mark got hooked on spicy autocomplete, Facebook has become even more of a hell-hole than before. Meta is also pushing LLM-based chatbots down users’ throats in WhatsApp, Instagram, and soon almost certainly Threads. Did anyone who actually uses these platforms ask for that? No. Is it already causing harm? Yes. Does that matter? Not in the slightest.

Google is pushing their LLM-based tools into everything from search to Google Workspaces – and making users pay for that. You don’t want these tools anywhere near your files? Tough luck; you might try to disable them, you might even succeed, but you will still be paying for them. Same with Microsoft.

Hype is the product¶

A lot of people paying for access to these services are definitely not happy. But they’re stuck, and they aren’t going anywhere. So that’s not really important, not something that is considered a serious problem. Enshittification and hype-as-the-product are two sides of the same coin; they are both enabled by barriers to user migration.

With such barriers solidly in place, what is important is that in the next earnings call stockholders will hear that usage of “AI” across all product categories went up by double-digits and revenue increased. They won’t know or care that it’s only because somebody flipped a switch and just gave everyone access, while hiking the price, whether they wanted it or not.

There is more and more proof these tools are not as useful as they are hyped out to be. LLM-based coding tools seem to actually hurt programmers’ productivity. “Hallucinations” are not going away because the only thing these LLMs can do is “hallucinate”; they just sometimes (about 30% of the time, in fact) happen to generate some text that has some connection to reality. They also keep causing information security problems and turn out to be vulnerable in most hilarious of ways.

LLM chatbots are also causing real people real harm.

And on top of all that it seems like “AI” is actually a turn-off for prospective customers.

So what? Investors just can’t get enough, and that’s what counts (even as they themselves get high on their own hype supply).

In fact, increasingly, hype is the only thing that counts, as larger and larger chunk of investment money is chasing it – to the detriment of everything else that happens not to bolt the hyped tech onto its unrelated but otherwise solid product or service.

The bubble grows. The line goes up.

Because the hype is the product.

And when “AI” loses it’s sheen, “quantum” is already waiting in the wings.

Many people who focus on information security, including myself, have long considered Telegram suspicious and untrustworthy. Now, based on findings published by the investigative journalism outlet IStories (original in Russian; English version by OCCRP available here), and my own analysis of packet captures from Telegram for Android and of Telegram’s protocol described below, I consider Telegram to be a indistinguishable from a surveillance honeypot.

Telegram generates a long-term identifier, called auth_key_id, on every client device. This identifier does not change depending on where the client is connecting from. Telegram’s current protocol, MTProto 2, requires this long-term identifier to be prepended in cleartext, or at best trivially obfuscated, to at least some encrypted messages sent through the network. When perfect forward secrecy is in use, temporary auth_key_ids are generated every 24 hours or so, and used instead the long-term one – but still prepended in cleartext to encrypted messages. This enables anyone who has sufficient network visibility and a bit of dedication to identify traffic originating from a given user device.

It is a surprising and unnecessary protocol design choice, present neither in Signal nor WhatsApp.

IStories found evidence that all network communication to and from Telegram’s infrastructure go through a company linked to the Russian FSB. This would provide the kind of network visibility that combined with auth_key_id would allow it to identify traffic coming from specific users, globally.

In other words, what for years seemed like a protocol design oddity is now looking more like a deliberate decision to facilitate global surveillance of all Telegram users by the Russian state, while obscuring Telegram’s infrastructure provider’s role and providing some measure of plausible deniability for Telegram itself.

The two decisions Telegram made (choice of infrastructure provider who happens to cooperate with the Russian FSB, and attaching a cleartext device identifier to encrypted messages) taken together reinforce surveillance capability of the FSB considerably more strongly than either of these decisions would have on its own.

It doesn’t matter if these decisions were made on purpose or accidentally. Telegram is indistinguishable from a honeypot.

Background: Telegram the Suspicious¶

For years Telegram felt suspicious and acted suspiciously to a lot of people working in information security. It “rolled it’s own crypto”, MTProto. It reacted poorly to valid criticism of it. Pavel Durov personally kept attacking and smearing – in a completely unsubstantiated way – fully end-to-end encrypted competition like Signal.

Whenever anyone looked closely at MTProto (version 1), they’d scratch their head. The protocol felt off, but nobody could prove that it is not secure. Until finally somebody did identify a protocol bug that was (as one blogger put it) “as close to a backdoor as they’ve ever seen”, potentially allowing Telegram to decrypt end-to-end encrypted messages.

Telegram fixed the issue, and then rolled out a second version of it’s own protocol, MTProto 2. Again, when people started looking closely at it, it felt off, but so far nobody has been able to prove there is a problem with encryption.

Earlier I said “fully end-to-end encrypted competition” – that’s because most communication via Telegram is not end-to-end encrypted, regardless of what Telegram’s own promotional materials relentlessly suggest. Only so-called Secret Chats are end-to-end encrypted, but the UI/UX choices around them make them unwieldy and impractical to use. Telegram’s UI is designed in such a way that it basically discourages Secret Chats use. End-to-end encryption is also not available at all for groups and channels. I dive a bit deeper into this here.

According to information found by IStories reporters, in 2018 98% of all communication on Telegram was not end-to-end encrypted. As best as I can tell, today the situation does not look much better.

At the same time Telegram’s marketing heavily relies on claiming Telegram is “heavily encrypted.” It is hard to see this as anything but misleading. It puts people using the service in danger, by making them think they are communicating in an end-to-end encrypted manner when they are not – something I had witnessed myself in the context of people doing sensitive work.

It’s MTProto 2 all the way down¶

According to Telegram’s own documentation, all client-server communication in the system happens using MTProto 2. Messages that are not end-to-end encrypted – groupchat messages, channel updates, or just default so-called “Cloud Chats” – encrypted using MTProto 2 to a key used for client-server communication (called the “authorization key” in the documentation), and sent.

If a message is end-to-end encrypted – that is, if it is part of a Secret Chat – it is first encrypted using MTProto 2 to a key negotiated between the recipient’s device and the sender’s device. Then, the end-to-end encrypted message is encapsulated in another MTProto 2 message, this time encrypted with the “authorization key” used for client-server encryption.

That “authorization key”, used to encrypt messages between a client and a server, is negotiated once on each device, and it seems valid for communicating with any server in a the Telegram “datacenter” the client device got assigned to at registration time, pretty much for the lifetime of the client on that device.

Telegram’s documentation mentions that “in the future”, under certain conditions, a client device might be migrated to a different datacenter, thus negotiating a new “authorization key”. But in general a client device is assigned to a Telegram “datacenter” once, using the same long-term “authorization key” as basis for all Telegram client-server communication.

auth_key_id¶

Each encrypted MTProto 2 message is prepended with a cleartext 64-bit value, the auth_key_id. That value is derived from the “authorization key” that is being used for client-server encryption, and is required to be strictly unique within a Telegram “datacenter”.

In other words, an auth_key_id derived from the long-term “authorization key” uniquely identifies a specific Telegram client device used by a specific Telegram user.

I have verified that when I block the IP address of the specific server the Telegram client on my device kept connecting to, it will connect to a different IP address in the same subnet, but use the exact same long-term auth_key_id (or the currently active temporary auth_key_id, if perfect forward secrecy is used – I explain this below).

I have also observed that regardless of where in the world the client on my device is connecting from, it always seems to connect to the same server IP address, or at least the same subnet, and the auth_key_id derived from the same long-term key (or, again, the currently active temporary “authorization key”) shows up in cleartext.

The way I checked all this is by observing the same the unencrypted, long-term or temporary auth_key_ids in different packet captures, regardless of where the Telegram client on my device connected from, or which Telegram server IP it connected to. I changed my external IP using Tor, and I also tested this without Tor in two geographically distant locations (Iceland and Poland). I describe my testing setup and dive into analysis of recorded traffic below.

If someone were able to see all traffic coming to and from Telegram’s infrastructure, they would be able to track people around the world by observing their cleartext auth_key_ids prepended to MTProto-encrypted messages, thus learning IP addresses used by targets’s devices at any given time.

They would also be able to reason about who is communicating with whom, by correlating traffic incoming to and outgoing from Telegram’s infrastructure based on size and timing, again connecting specific packets to specific user devices based on auth_key_ids.

How could that someone connect a specific auth_key_id with a device of a specific person in the first place? Perhaps it’s as simple as asking Telegram – the service provided data on tens of thousands of users just in the first quarter of 2025. It is unclear what data is provided, but it is reasonable to assume IP addresses (if not auth_key_ids themselves) and timestamps are included. IP address and a timestamp would be enough to associate a person using the service with a cleartext auth_key_id from packet captures if one had already captured the relevant traffic.

Yes, people using Telegram could use Tor or VPNs to obscure their real IP address. The point I am making here is not that it is impossible to hide from this kind of surveillance facilitated by Telegram’s protocol design and choice of infrastructure providers – but rather that these seemingly unrelated choices of Telegram’s appear to work together exceptionally well to facilitate that kind of surveillance in the first place.

Obfuscation¶

Initially I could not find what I was looking for in my packet captures. With a bit of digging I understood that sometimes Telegram obfuscates the packets using a rather trivial scheme. For some reason all packets in my own captures were obfuscated this way.

Telegram’s documentation is clear that this is not an encryption scheme, and is only meant to thwart some trivial packet filtering deployed to block Telegram traffic. I wrote a de-obfuscation tool for captured Telegram packets to simplify my analysis, which you can find here, along with basic usage instructions.

I decided to publish this code so that others can reproduce my results regarding auth_key_id, and further analyze the protocol and its implications.

Publishing it does not put Telegram users in any additional danger, I believe: the obfuscation scheme is trivial, well-documented in Telegram’s documentation, and already implemtented in countless open-source libraries. If anyone was listening on the wire they’d have their own implementation already integrated, optimized, and deployed.

Perfect Forward Secrecy and temporary auth_key_ids¶

MTProto 2 supports perfect forward secrecy (PFS). Just to be clear: perfect forward secrecy is not the same thing as end-to-end encryption. PFS is possible in all MTProto 2 communication (including client-server encryption). End-to-end encryption in Telegram is only available for Secret Chats.

When PFS is used, a temporary “authorization key” is negotiated using the authorization key currently in use, and then the identifier of that new key (temporary auth_key_id) is prepended to messages, instead of the long-term auth_key_id of the device.

These temporary keys seem to only be valid for 24 hours. When a temporary authorization key expires, or is about to expire, a new one is negotiated using messages encrypted with the old one – and with the old key’s auth_key_id prepended in cleartext to them.

As I show later on, this means that anyone who can observe all communication between Telegram clients and Telegram servers could easily keep track of these temporary auth_key_ids associated with a specific user device, even if PFS is in use and all new temporary “authorization keys” are negotiated without the use of the long-term, permanent auth_key_id of the device.

This is because it is extremely unlikely for the IP address of the client and the temporary auth_key_id to both change at the exact same time. If the client reconnects from a new IP address, it will use an already-observed auth_key_id. When a new temporary auth_key_id is created, it shows up in the traffic immediately after the old one is used. Some of the captures below happened weeks apart, or on from physically distant locations – but the temporary auth_key_ids visible in them would have easily allowed the client device to be identified.

Reinventing TLS, poorly¶

TLS is broadly deployed, well-understood, gradually improved over decades, repeatedly audited, and battle-tested. It provides exactly what is needed for client-server communication in the context of a system like Telegram – that is, confidentiality and integrity of communication. TLS supports perfect forward secrecy.

There also is public key infrastructure available, along with certificate pinning and other facilities that together mean no cleartext client device key identifier needs to be ever transmitted on the wire. TLS is used as transport layer encryption by Signal, for example.

And yet, inexplicably, Telegram decided to mainly use their own MTProto 2 for the client-server transport, instead of using tried-and-true TLS. Even though, technically, HTTPS is one of the possible MTProto 2 transports, but I have not found any indications of HTTPS being used as a transport layer in any of the packet captures I have analyzed.

Once the Telegram “authorization key” is negotiated between the client and a server, it then needs to be identified somehow in the message so that the receiving side (for example, Telegram’s servers) knows which key to use to decrypt it. Thus, this identifier, auth_key_id, needs to be prepended to messages, in cleartext.

Additionally, MTProto 2 is somewhat obvious in packet captures, partially because of sequences of bytes that identify what specific format is being used in any given case (the protocol supports a dizzying array of transport and transport formats). Which is presumably why the obfuscation layer had to be added, so that relatively trivial packet filtering could be thwarted.

None of this would have been necessary had Telegram decided to use TLS for their client-server transport.

TLS is not the only available choice, of course. WhatsApp uses Noise Pipes, which also seems to avoid all these pitfalls while providing similar features.

Global capability¶

This is not the first time attention is being drawn to auth_key_id and the possibility to track specific people based on it. There had been reporting on that before, for example on how it might have been used by the Russian state to target Ukrainian partisans in Kherson.

The assumption seems to have always been that this might be a problem when you’re in Russia or where Russian state can have full network visibility (for example, through SORM), but if you’re outside of these areas and connecting to Telegram’s servers physically located outside of Russia (Telegram makes a big deal of their global infrastucture hosted in many different jurisdictions), this is much less of a consideration.

IStories’ reporting shows that the Russian FSB, through Telegram’s chosen global infrastructure provider, could have access to all traffic flowing to and from Telegram’s servers, wherever they are physically located in the world, and wherever the traffic originates from.

Combined with the cleartext long-term auth_key_id (or it’s temporary version) on the wire, this would give FSB global capability of tracking movements of all Telegram users.

Over the years Telegram grew to be extremely popular, particularly in Russia and Eastern Europe; in 2024 it reportedly had 950 million active accounts worldwide. This translates into the ability to track physical movements of a huge number of people, including Russian dissidents, Ukrainian soldiers, Easter European activists, politicians, and so on.

This also means that every time anyone uses or promotes Telegram, they are unwittingly supporting this possible surveillance operation, by strengthening network effects that pull more people into that network and keep them there. If you use Telegram in any capacity, you have to contend with your personal responsibility here, however small you might consider it to be.

Finally, what is really striking to me is that we – the information security community – have for years been focusing on whether or not Telegram’s encryption scheme is sound, while the obvious (in retrospect) issue of surveillance based on metadata was staring us directly in the face, right there in cleartext in packet dumps.

All the more credit to the investigative journalists from IStories who asked the right questions, and doggedly seeked out the answers.

---

Diving into the technical weeds¶

Below I dive into the techical details: testing setup I used, a bit on Telegram’s protocol obfuscation scheme, and finally analysis of specific packet captures.

My analysis focused on Telegram for Android. I have done my own packet captures, including during the registration of the Telegram account I used for this. These captures were performed in short sessions spread over several weeks, while I was in Iceland and in Poland.

I have also done analysis of packet captures done by others for IStories’ investigation, of both Telegram Desktop, and Telegram for Android, including packets captured within Russia. These also supported my conclusions, but I am not at liberty of sharing the raw data.

Testing setup¶

The testing set-up I used consisted of a QubesOS machine, on which I had:

• regular QubesOS networking setup (sys-net, sys-firewall);
• Tor networking VM (sys-whonix);
• packet sniffing VM (telegram-sniff);
• Ubuntu VM running Waydroid with Telegram for Android installed (telegram-apk).

I used Telegram for Android, version v11.9.2 (5901). The APK was downloaded directly from Telegram’s website.

The telegram-apk VM used the telegram-sniff VM as its network provider. That in turn used as a network provider either sys-firewall (standard QubesOS setup) or sys-whonix (when I wanted to route traffic through Tor). I used Wireshark running in the telegram-sniff VM to perform the packet dumps. When I needed to block certain Telegram server IPs, I did that in the telegram-sniff VM.

This meant that I could change the underlying networking set-up and perform packet captures, while making sure the Telegram app had no way of noticing or interfering with them.

Packet captures¶

All packet captures discussed below are available here. They contain only Telegram-related traffic. The filenames contain a UNIX timestamp of the first packet, and a meaningful description of what was being done while the packet capture was running.

Most packets I observed turned out to be obfuscated using MTProto 2 obfuscation scheme. As mentioned, I wrote a tool to deobfuscate them and try to extract auth_key_ids. Output below is from that tool.

The tool operates on payload data extracted from the packet dumps. The only packets that contain auth_key_id are the initial data packets of TCP streams. So, to prepare *.payloads files for the tool to process, we need to:

1. identify all complete TCP streams in the packet capture file;
2. extract payload data from only the first packet of each stream.

The deobfuscation tool repository contains a short tshark-based script that does just that.

Whenever auth_key_id is printed by the deobfuscation tool, it means that:

1. the data in the packet was in fact obfuscated;
2. after de-obfuscating it the data contained the ef:ef:ef:ef abridged transport marker at the expected offset.

An “null” auth_key_id of 00:00:00:00:00:00:00:00 indicates a message that is not encrypted or otherwise a service message. Specifically, messages that are used in the process of negotiating an authorization key will have auth_key_id set to all zeroes.

Each separate packet capture file was captured during a single session, which means a single external IP address. I am not showing the IP addresses here, because the captures were done on the internal QubesOS network, and only involve private network IPv4 addresses. External IP addresses changed between each session.

Obfuscation¶

When looking at packet payloads carrying MTProto 2 one should see the tell-tale markers of one of the many MTProto 2 transport schemes, and then auth_key_id a few bytes later (depending on the scheme in use). But I kept getting random-looking data, for example:

fa:8f:85:46:94:ab:c7:21 3d:9a:31:61:43:f3:34:e6 ed:43:41:fc:9b:c4:65:20 83:27:f5:ff:0c:20:47:e7
de:f1:24:09:39:6d:9a:1f 31:4e:47:b0:1c:be:93:b3 aa:ed:1a:f2:4b:0a:cc:d2 9c:6c:32:90:1c:25:f9:73
29:e1:09:02:e1:3a:da:77 e5:76:53:4b:4c:c6:e4:b9 6d:c7:af:50:16:d4:30:49 8f:4e:c6:50:56:ac:cc:a3
(...)

This meant that the data was obfuscated. When passed through my deobfuscation library, this payload looks like this:

95:f8:27:6a:d4:e2:2c:82 77:eb:6d:8d:fd:78:4e:2e 78:a0:b5:54:e7:f9:8a:9c 65:3c:04:c1:d5:68:b4:34
79:1c:3d:4e:ec:ae:23:b9 aa:db:73:ce:16:86:09:33 8e:9a:e7:73:6d:1c:ab:1e ef:ef:ef:ef:ed:b2:26:37
2a:64:0a:8a:ff:3a:83:75 54:57:07:07:e2:06:3d:a5 f7:8d:60:f6:a0:48:f3:61 49:f9:2a:3d:1f:ce:1a:df
(...)

Where:

• ef:ef:ef:ef is a marker of the “abridged” MTProto 2 transport, when used with obfuscation;
• ed:b2:26:37 is just random data leftover after obfuscation (in some cases it can be used for information related to Telegram’s “datacenters”, but this seems irrelevant here);
• 2a is the length of actual MTProto 2 message payload;
• 64:0a:8a:ff:3a:83:75:54 is the auth_key_id, at the very beginning of the MTProto 2 message.

Data before the ef:ef:ef:ef marker is random noise, a result of “deobfuscating” the key and initialization vector for AES-CTR used for obfuscation. The key is bytes 8 through 39 of the original payload (yes, cleartext on the wire – otherwise it would be impossible to deobfuscate it on the other end), and the initialization vector bytes 40 through 55.

Bytes 0 through 7 seem to only matter for the server as far as it needs to figure out which transport and format is being used – basically, they need to not contain certain magic byte sequences to be treated as obfuscated MTProto 2.

Registration and first message¶

We get several potential auth_key_ids from sniffing during initial registration:

processing file: 1746314533-telegram-mobile-first-registration-and-message.pcapng.payloads
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 8a:31:86:7d:2e:8e:0c:77 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : c6:00:00:4d:db:fa:12:b8 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : a6:00:00:ae:cf:27:cf:ba 
   auth_key_id : ae:cf:27:cf:ba:e1:58:d5 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : c7:33:a1:24:02:4f:3c:36 
   auth_key_id : 58:d6:c4:e6:fa:bb:0b:68 
   auth_key_id : eb:40:17:49:1e:e4:93:c9 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54

The only one that repeats several times here – apart from the 00:00:00:00:00:00:00:00 null auth_key_id – is 64:0a:8a:ff:3a:83:75:54, so that’s probably the long-term auth_key_id. But we should make note of all of them.

Background sessions¶

Three different background sessions (meaning, without actually starting the Telegram app explicitly). The telegram-apk VM was restarted between these session.

Our suspected long-term auth_key_id is obviously visible:

processing file: 1746315509-telegram-mobile-background-session-no-open-app.pcapng.payloads
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
processing file: 1746318794-telegram-mobile-background-session-no-open-app2.pcapng.payloads
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
processing file: 1746319193-telegram-mobile-background-session-no-open-app3.pcapng.payloads
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 

Background sessions via Tor¶

When Tor is used to change the external IP address from which connections would be established with Telegram servers, again the suspected long-term auth_key_id is obviously visible:

processing file: 1746319792-telegram-mobile-background-session-no-open-app-via-tor1.pcapng.payloads
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
processing file: 1746320078-telegram-mobile-background-session-no-open-app-via-tor2.pcapng.payloads
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 

This is also true for when I blocked the IP address that the Telegram app kept connecting to, and then unblocked it again:

processing file: 1746326453-telegram-mobile-background-session-no-open-app-via-tor-91-blocked1.pcapng.payloads
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
processing file: 1746327628-telegram-mobile-background-session-no-open-app-via-tor-after-91-unblocked1.pcapng.payloads
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 

Joining a channel¶

When I joined a channel – while physically located in Poland instead of Iceland – the long-term auth_key_id was visible initially:

processing file: 1747770014-telegram-mobile-open-app-join-minionquote-channel.pcapng.payloads
   auth_key_id : 64:0a:8a:ff:3a:83:75:54 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : c7:33:a1:24:02:4f:3c:36 
   auth_key_id : 58:d6:c4:e6:fa:bb:0b:68 
   auth_key_id : eb:40:17:49:1e:e4:93:c9 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : 4d:db:fa:12:b8:0b:2a:c8 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : ae:cf:27:cf:ba:e1:58:d5 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 3c:47:69:e8:ba:09:a3:ff 
   auth_key_id : f0:f6:f1:07:b1:a7:31:51 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 3c:47:69:e8:ba:09:a3:ff 
   auth_key_id : 31:b1:e9:42:76:5f:1e:66 
   auth_key_id : 31:b1:e9:42:76:5f:1e:66 
   auth_key_id : 31:b1:e9:42:76:5f:1e:66

Seems like this is when perfect forward secrecy kicked in and several temporary authorization keys were negotiated (as probably indicated by the all-zero auth_key_ids followed by new values). Anyone sniffing my traffic on the wire could have noticed this, while also observing that all of these new auth_key_ids show up in packets from the same IP address as the ones observed beforehand.

Some of the presumably temporary keys (ids: c7:33:a1:24:02:4f:3c:36, 58:d6:c4:e6:fa:bb:0b:68, eb:40:17:49:1e:e4:93:c9) show up in earlier capture. Others (ids: 20:0d:a0:1e:f7:32:e3:2b, 27:41:c4:eb:5e:b6:b5:63) turn out to be used later.

Talking to a bot¶

The next session did not include the presumed long-term auth_key_id. That’s consistent with Telegram’s documentation, that requires the long-term auth_key_id not to be used once temporary keys are in use for perfect forward secrecy:

processing file: 1747770709-telegram-mobile-transparency-for-iceland.pcapng.payloads
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
processing file: 1747773654-telegram-mobile-transparency-for-iceland2.pcapng.payloads
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : e5:c2:9a:fd:8d:5a:23:16 
   auth_key_id : 09:02:40:0f:1a:62:85:89 
   auth_key_id : e7:ee:21:9f:3b:a4:4a:1d 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63

But it did contain two ids (20:0d:a0:1e:f7:32:e3:2b, 27:41:c4:eb:5e:b6:b5:63) of the presumably temporary auth_key_ids seen before in the same packet capture as the long-term one.

This was true also when I switched to Tor in order for the connection to seem to originate from a completely different location:

processing file: 1747787981-telegram-mobile-transparency-for-iceland3-over-tor.pcapng.payloads
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : e5:c2:9a:fd:8d:5a:23:16 
   auth_key_id : 09:02:40:0f:1a:62:85:89 
   auth_key_id : e7:ee:21:9f:3b:a4:4a:1d 
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63

In other words, these packet captures, even though they do not contain the long-term auth_key_id, can still be easily tied to the same user: the temporary auth_key_ids that are visible here were observed with the long-term one before (associated with it via IP address). Any new temporary auth_key_ids would have been negotiated using the current temporary auth_key_ids and could thus be associated with the same device the same way.

As long as we have the requisite global network visibility. Which, thanks to Telegram’s choice of infrastructure providers, FSB does seem to have.

Connecting after a long break¶

I took a break for a couple of weeks, to see what would happen with regards to the temporary auth_key_ids.

Upon reconnecting, yet again I could observe old temporary auth_key_ids (20:0d:a0:1e:f7:32:e3:2b, e5:c2:9a:fd:8d:5a:23:16, 09:02:40:0f:1a:62:85:89, e7:ee:21:9f:3b:a4:4a:1d, 27:41:c4:eb:5e:b6:b5:63, 31:b1:e9:42:76:5f:1e:66) closely followed by newly generated ones (ba:96:5e:72:66:b8:17:91, 3c:47:69:e8:ba:09:a3:ff, 02:5a:6b:98:cc:a4:ea:ce):

processing file: 1749161835-telegram-mobile-transparency-for-iceland4-from-poland.pcapng.payloads
   auth_key_id : 20:0d:a0:1e:f7:32:e3:2b 
   auth_key_id : e5:c2:9a:fd:8d:5a:23:16 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 09:02:40:0f:1a:62:85:89 
   auth_key_id : e7:ee:21:9f:3b:a4:4a:1d 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : ba:96:5e:72:66:b8:17:91 
   auth_key_id : ba:96:5e:72:66:b8:17:91 
   auth_key_id : ba:96:5e:72:66:b8:17:91 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 27:41:c4:eb:5e:b6:b5:63 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 31:b1:e9:42:76:5f:1e:66 
   auth_key_id : 31:b1:e9:42:76:5f:1e:66 
   auth_key_id : 3c:47:69:e8:ba:09:a3:ff 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 00:00:00:00:00:00:00:00 
   auth_key_id : 02:5a:6b:98:cc:a4:ea:ce 
   auth_key_id : 02:5a:6b:98:cc:a4:ea:ce 

Conclusions¶

Based on the analysis of packet captures above, I believe it is clear that anyone who has sufficient visibility into Telegram’s traffic would be able to identify and track traffic of specific user devices. Including when perfect forward secrecy protocol feature is in use.

This would also allow, through some additional analysis based on timing and packet sizes, to potentially identify who is communicating with whom using Telegram.

This blogpost has been improved based on fedi discussions around it; you can find the Polish thread here, and the English thread here. I appreciate all this input!

I have recently been asked by the Panoptykon Foundation if it was possible to create an online age verification system that would not be a privacy nightmare. I highly recommend reading their piece, which dives into several issues around age verification.

I replied that yes, under certain assumptions, this is possible. And provided a rough sketch of such a system.

But before we dive into it, I have to be clear: I am not a fan of introducing online age verification systems. Privacy is just one of the many issues related to them. I dive into some of those later in this post.

However, the broader context is that age verification is becoming required by law in for a lot of services. And systems that are used for it are horrendously bad – like, say, Discord’s idea to verify age of people either by requring a scan of an ID, or enabling the camera in order to let them analyze our face.

What I wanted to show is that it is possible to think about age verification in a somewhat privacy-friendly way.

Rough sketch of a protocol¶

1. You visit a website that requires age verification. The website displays a QR code that contains a formally encoded question (for example, “is the visitor older than N?”).
2. You scan the QR code using an app you trust.
3. The trusted app asks you to confirm you want to provide the answer to the stated question (verify your age).
4. If so, the trusted app sends the formally encoded question to an e-ID service. The request does not contain any information about the website that requires your age to be verified, but it is signed with a key associated with you (so, a key associated with the person whose age is to be verified).
5. The e-ID service responds with “yes” or “no”. The response (which contains also the original formally encoded question) is signed with the service’s private key.
6. Your trusted app forwards the signed response to the website that needs your age verified. It uses an URL that was provided in the QR code.
7. The website verifies the validity of the signature on the response using the well-known public key of the e-ID service.

The point is that the e-ID service gets no information that identifies the website that requires your age to be verified; and at the same time that website gets no information about us, apart from whether or not we satisfy the age requirement.

This “protocol” description is obviously substantially simplified. Also, it is not the only way to create a privacy-friendly age verification system – other methods could rely on zero-knowledge proofs and directly use distributed anonymity overlay networks like Tor or Veilid, which would help improve privacy of people using them.

The aim here is not to design a perfect, ready-to-deploy solution, but to demonstrate, in a way that is possible to grasp for a non-technical person, that creating such a system is possible.

This kind of protocol could also be used as a privacy-friendly way of certifying other things about us, as far as they are available to the e-ID service. For example: “does the person have a valid driver’s license?”, or “does the person live in this particular city?”.

The service that would require such certification would only receive a “yes” or “no” answer, without getting any other information about us.

Devil in the (technical) details¶

The QR code that gets displayed by a website can be replaced by other ways of communicating with the trusted application on our device. For example, if the website is opened on the same device as where the trusted application is installed, this could be done using an application link that directly opens in the trusted application, without any need for scanning anything. The data format could be as simple as JWT, as long as it is clearly defined and described.

The formally encoded question could be written in a simple domain-specific language – just complex enough for that particular purpose, but no more. That domain-specific language should not be Turing-complete.

The question should be bundled with a randomly generated nonce, which would accompany it all the way to the e-ID service, and would have to be included in the signed response. That response should also contain a short date of validity. Otherwise a signed response could be re-used multiple times.

The website asking for age verification would of course have the information on person’s IP address – but it already has that information, as we had visited it in the first place. There is obviously nothing stopping anyone from using anonimization tools like Tor.

Assumptions¶

Privacy of this system relies on correct, non-malicious implementation of that protocol by the trusted application on the device of the person whose age is being verified. This could be something like mObywatel (the official e-government application in Poland) – but it would have to be open-sourced and independently audited.

The protocol should not require any specific application, just like OTP-based multifactor authentication does not rely any specific application. All that is required is an application that implements the protocol. And the more such independent implementations exist, the better.

Communication between the trusted application and the e-ID service will require a cryptographic key asssociated with the person whose age is being verified. Such a key could be generated by the trusted application itself and verified through logging into that application using one’s official government e-ID login service. The private key should never leave the device.

Privacy of the whole thing also relies on the assumption that the website that is requesting somebody’s age to be verified would not separately send any data that could identify a specific request (nonce, IP addresses involved, exact timing) to the e-ID service. Using an anonymizing network like Tor would provide additional level of safety for the person whose age is being verified.

Privacy outside of the protocol¶

Regardless of how effective the hypothetical protocol is in protecing our privacy on its own, the mere fact of using it might already be quite problematic.

If only pornographic sites were implementing it, each and every verification request would obviously be a clear signal to the e-ID service that we are currently visiting a porn site.

So, the more different services implement this protocol, the better for our privacy. And, the more different things about us can be certified, the better it is for our privacy.

As an added protection, any time the trusted application is sending a request to the e-ID service, it could add a few randomly selected questions, like: “is the person’s age above N?”, “is the person’s age below M?”, “does the person have a valid driver’s license?”, “does the person live in Poznań?”. After receiving responses to all of them, the trusted application would only forward to the website the response to the particular question that the website asked. The e-ID service could not reliably tell which question was relevant, and which questions were chaff.

Privacy is not all¶

Once such a system is implemented, it becomes dependent on the e-ID service. If the e-ID service is down for whatever reason (for example, a technical issue), the whole verification system stops working, and so our access to the services that require such verification becomes impossible or at least much more difficult.

The question of who runs and manages the e-ID service is also an important one. Control over it is real power.

For example, if all social networks would be forced to implement age verification, the entity controlling the e-ID service could be able to maliciously block specific persons from accessing to them, or at least make it much more difficult for them – simply by refusing age verification requests coming from these persons.

This is similar to how the Trump administration is abusing the Social Security Number system. Immigrants are being marked “deceased” in this system in order to make it impossible for them to have access to credit cards or other basic banking services.

Although the e-ID service does not know what website our age is being verified for, it knows who we are, and knows the question being asked. If that question was often associated with with social media access (for example, “is this person over 13 years old?”), the e-ID service operator could assume that we are trying to access a social media site, and simply reject the age verification request.

There are ways to lower the likelihood of such abuse. For example, social media sites would not need to verify our age every time we visit, only when we set up the account for the first time. But this has other unintended consequences: it would become impossible to access any social media content without an account.

Squaring the circle¶

If age verification online is an inevitability, then at least it should be implemented in a way that protects our privacy – and this is possible. Our privacy would also be protected the better, the more different kinds of services implement this protocol in order to verify more distinct kinds of information about us.

But privacy is not the only problem here. The broader such a protocol is deployed, the more serious and more dangerous the issues around centralization of power over our access to different online services become.

We must keep that in mind whenever we talk about deploying of – and especially requiring by law – such a system.

Eight years ago Lance Ulanoff had a problem. William Shatner could not find him on Mastodon.

His distress is understandable, relatable even. Who wouldn’t want to be found by Captain Kirk himself! The way he dealt with that feeling of distress, however, was something different. He came to the conclusion that because Captain Kirk could not find him, Mastodon can’t survive.

You see, Lance Ulanoff, like most journalists writing about technology, understands tech. Like, really understands it. As an award-winning tech journalist and former Editor in Chief at PCMag-dot-com he knows the ins and outs of all corporate tech stacks. As I write this, the four latest pieces of his in TechRadar are pushing Microsoft hype like there is no tomorrow. All four published within the last two days.

That is the level of journalistic excellence and rate of creative output I know I could never even dream to attain.

And if you understand tech – like, really understand it – you must recognize, just as Lance Ulanoff had recognized, that some weird wannabe social network with no large corporation behind it and no VC money in the bank cannot work, should not work, will not work.

Ulanoff – a Tech and Social Media Expert, according to his fedi bio – gave six reasons that led him to his conclusion. First and foremost, he just didn’t like the name. Secondly, he completely missed the point of decentralization, calling instances “silos”. Third, he found the term “toot” objectionable. Fourth issue… not even sure what he meant here, I had a Mastodon account before his piece got published and handles were working just fine. Fifth, the Captain-Kirk-Can’t-Find-Me problem. Sixth, the fact that one has a choice of available mobile apps (how gauche!).

Based on all this, TechRadar’s current Editor at Large, whose latest pieces fawn over corporate AI chatbots as if they’re the best thing since sliced bread, delivers his sage verdict:

Mastodon cannot live on hype alone.

Eight years on, Mastodon – along with the rest of the Fediverse, of which Mastodon is but a part, and which Lance Ulanoff decided to wholly ignore of course, the seasoned tech journalist that he is – chugs along nicely.

Turns out what drives and sustains decentralized social media is not hype, but a sense of community and the possibility to have some real agency in one’s social media experience. This decentralization and sense of community allows Fediverse to survive even if individual instances disappear.

Which they sometimes do: at some point very soon, octodon.social, one of the oldest Mastodon instances – started, in fact, days before Lance Ulanoff published his piece – will shut down for good. People who had accounts on it have moved on to other instances by now, and thanks to how Fediverse works the social network fabric and relationships I had built with them over the years remain unperturbed. Had I had an Octodon account that was, inexplicably, followed by William Shatner, he wouldn’t even have noticed I moved.

That’s in stark contrast to, say, Google+, which despite corporate backing, incomparably larger budget, and being pushed down people’s throats through forced integration with YouTube, survived mere seven years, nine months, and a week.

And once it shut down, it shut down. A social network of millions just blipped out of existence one day. All those moments – lost in time, like tears in rain.

Google+, the presumptive Facebook killer, shows tremendous potential. As someone who warms up to any social network with the alacrity of a Galápagos tortoise, this, for me, is saying something.

– Lance Ulanoff wrote in 2011 about a corporate social network that ended up lasting shorter than a tiny fedi instance run by a volunteer.

So celebrate with me the annual Mastodon Won’t Survive Day. You can find me on the Fediverse.

Seems like in all the chaos after the power transition in the US, this was largely missed: Musk-led “Department of Government Efficiency” will have access to all unclassified US government records.

It’s always the unassuming, irrelevant looking stuff like that that people need to pay attention to.

The rise of Joseph Stalin as the leader of the Soviet Union really got going when he became the General Secretary of the Central Committee of the Communist Party of the Soviet Union. At the time, the position was what it said on the can, a purely administrative job with no real political power.

Throughout the history of the Soviet Union, a position of Premier (roughly a “Prime Minister”) existed. Premiership was the ultimate post in the government and whoever held it was the leader of the country. At least initially.

Up until Stalin’s tenure, the position of General Secretary was not seen as important; definitely nowhere near as important as Premier. After Stalin, the premiership was either combined with General Secretary, or sidelined.

Through access to information and ability to make “technical” decisions that influenced political issues being the General Secretary gave him, Stalin took over. He only became the Premier in 1941 – nineteen years after having become General Secretary, and at least thirteen after he became the de facto leader of the country.

As dumb as the name of the Department of Government Efficiency is, with that kind of access to information DOGE can easily become the real power center in the middle of the US government bureaucracy.

Will Musk become the Great Leader thanks to DOGE? I doubt it. He’s too much of a pitifully thirsty edgelord. He’ll get bored of the necessary administrative work, and focus on getting as much money out of it as he possibly can. Or perhaps he gets the boot from Trump.

But keep this in mind. If the department survives, which it might, there will be somebody after Musk heading it. And nobody will be paying any attention to this silly-named, boring part of administration. Until, perhaps, there is no other choice.

Wednesday, August 28th, marked the beginning of the copyright infringement lawsuit filed by the Polish train manufacturer Newag against train maintenance yard Serwis Pojazdow Szynowych and experts from the Dragon Sector group, who revealed weird software locks in Impuls-series trains. The company demands almost six million Polish złotys (about 1.4mln EUR) compensation. Surprisingly, it also admits that the hackers did not modify software in on-board controllers.

In late 2023 Onet and Zaufana Trzecia Strona wrote about Impuls multiple-unit trains that were rendered inoperable. I wrote about this for OKO.press in December that year. For years Newag-manufactured trains experienced suspicious breakdowns, becoming inoperable often after maintenance performed by third-party maintenance yards like Serwis Pojazdów Szynowych (SPS).

SPS had employed hackers, embedded systems experts, to analyze the software installed on on-board controllers. Their analysis indicates intentionally implemented software blockades, locking the trains up under specific conditions. These conditions seem to have been selected such that the trains would lock up after going through maintenance in independent maintenance yards.

These conclusions were deemed trustworthy by the Polish Computer Emergency Response Team.

The hackers were able to unlock the affected trains. They also provided explanations on how they managed to do that, and why Impuls-series trains were locking up in the first place.

Newag’s denial¶

Newag strongly denies implementing the locking functions.

The company does not, however, offer any convincing explanation of how the locking functionality found its way into Impuls-series trains, used by several different train companies all around Poland – and why only these trains seem to be affected. “We have 23 different vehicle types and we have only experienced this with these particular trains” – said Piotr Wakuła, director of operations and technical bureau at Koleje Mazowieckie train company, while speaking at a parliamentary meeting in February this year.

Newag also refuses to answer how exactly were its technicians able to unlock the locked up trains. I asked the company’s spokesperson and received a non-answer: “Our actions amounted to restoring integrity of these systems (diagnostics, verification, and validation).” I asked for a more detailed explanation but received no response.

The “diagnostics, verification, and validation” phrase was also frequently used by Newag representatives during parliamentary committee meetings on the subject; it did not satisfy the train companies nor members of the Parliament.

Instead of providing clear explanations, the company sued Dragon Sector hackers and SPS maintenance yard over alleged copyright infringement. Newag also demanded that the Internal Security Agency (ABW) “puts under special surveillance” everyone who attended the Oh My Hack! conference, where members of Dragon Sector had presented a talk on their findings.

How did the locking code get into the software?¶

A few months ago I had asked Newag how did the locking code, described in Dragon Sector experts’ analysis, get into the software installed on Impuls trains controllers. In his response the company’s spokesperson, Łukasz Mikołajczyk, questioned this code even existed:

“We do not have any knowledge about the locking code, as reported in the media, ever existing. (…) We can only stress one more time that in the source code we have such functionality does not exist.” – I read in his response, dated April 4th.

Just a few paragraphs later in the same document Newag’s spokesperson unsubtly implies that the locking code might have been added to the software in Impuls trains by Dragon Sector experts themselves:

There is a theory according to which SPS Mieczkowski decided to deal with the difficulty of not having access to technical specification by some other means and hired hackers so that maintenance opreations can be finished without buying a license from NEWAG.

If that were the case it would mean that the hackers broke into Impuls trains’ software even though they did not have access to the source code, and not knowing the system well enough they introduced software changes that caused the trains to „go crazy”.

I have asked repeatedly whose theory this is and if according to Newag specialists from Dragon Sector implemented the locking functionality in software. I have not received a response to this day. But Newag did publish similar claims in their statement of December 2023:

According to our assessment the truth might be completely different – that is, for example, that our competitors tampered with the software. We have notified law enforcement about this. This is not the first time we notify law enforcement that our software is modified without our authorization.

And yet Newag’s copyright infringement suit states that:

No modified Software was installed as part of actions undertaken [by experts from Dragon Sector]

Why the sudden change of heart?

The C‑13/20 decision¶

From the very start of the whole Impuls-series trains affair their manufacturer insists that Dragon Sector experts infringed upon the company’s copyrights related to the software installed on trains’ controllers. They had to copy the software off of the controllers’ non-volatile memory and then decompile it for analysis, for which neither they nor the SPS maintenance yard had a license from Newag.

Copyright law does however allow reverse engineering of software in specific situations. This has been confirmed by the C-13/20 decision issued by the Court of Justice of the European Union in the Top System case. That case also involved alleged copyright infringement related to decompiling of software in order to fix errors.

The Court decided that:

…the lawful purchaser of a computer program is entitled to decompile all or part of that program in order to correct errors affecting its operation, including where the correction consists in disabling a function that is affecting the proper operation of the application of which that program forms a part.

And that in such a case getting a license for that from the software vendor is not required.

By admitting that Dragon Sector specialists did not modify the software installed on Impuls-series trains Newag is trying to claim that they have not “corrected errors” in that software, and thus the C-13/20 decision is not relevant to the case.

“DS [Dragon Sector] established that the cause of 45WE Impuls Vehicles locking up allegedly was a parameter held in the memory of the Selectron Controller. After modifying its value it was possible to unlock 45WE Impuls Vehicles. This is not a repair, as no error was identified” – the suit reads.

“Neither DS nor SPS performed any ‘repair’ of NEWAG IP Software”

“Neither DS nor SPS indicated any errors in NEWAG IP Software.”

Since the software was not “repaired”, it follows – according to Newag – that “decompiling of the software was not necessary to unlock 45WE Impuls Vehicles.” And since it was not necessary, the actions performed to unlock the trains did not meet the criteria set in the C-13/20 decision, and thus constituted infringement of software vendor’s copyright.

Different kinds of memory¶

At the same time Newag keeps repeating that specialists hired by SPS “tampered with the control system”, suggesting that this might be somehow dangerous. How does that square with claims that they did not modify the software installed in the trains’ controllers?

Controller units used in Impuls-series trains have three types of memory:

• FLASH
  this is where the binary code of software and the operating system running on the controller is stored;
• NVRAM
  holds the settings and other data that needs to be preserved even if power is lost;
• RAM
  volatile memory that holds data needed by the software while it is running; the data is held there as long as the controller is powered on.

This layout is not in any way special. Memory architecture of a home WiFi router looks basically the same.

When such a device gets rebooted, data in RAM is lost, but settings in NVRAM and software in FLASH are preserved. When we change settings in the user interface, variables stored in NVRAM are being modified, but no changes are made to software installed in FLASH.

In order to unlock the locked Impuls trains Dragon Sector hackers modified specific variables in NVRAM. So they did “tamper with the control system”. However, they did not make any modifications to software in FLASH, simply because that would require full recertification of the new software version before the trains were legally allowed on public tracks.

If unlocking a train required modifying the software itself – for example, when the condition that triggered the lock relied on the current date instead instead of values stored in NVRAM – the train was left unfixed. This was the case with 31WE-015, which locks itself up twice annually, on 21st of November and on 21st of December; it then unlocks itself on 1st of December and 1st of January.

Mental gymnastics¶

Newag’s line of reasoning is a case of pretty fraught mental gymnastics

First of all, how were Dragon Sector hackers supposed to “identify errors” in software, if their analysis showed that the locking functionality in Impuls-series trains was implemented intentionally?

Secondly, this line of reasoning bases on a very narrow interpretation of the term “repair”. From the perspective of train operators the Impuls-series trains that locked-up were obviously “broken”; unlocking meant that they were “repaired” – even if that repair happened not to require modifications of software installed on the controller units in these vehicles (instead relying on changing some values stored in NVRAM).

And finally, Newag claims that since there was no need to modify the software itself (as modifying values in NVRAM was sufficient), it was not necessary to decompile the software. That’s like claiming that since fixing our car required fastening one small screw it was not necessary to understand how the whole engine works. But how are we to know which screw to fasten without such understanding?..

This is certainly not the only line of reasoning used by Newag in the suit agains the experts and SPS – full analysis of 160 pages of it is a job for lawyers. I am only focusing here on aspects that touch on technical issues.

Unanswered questions¶

One important question remains unanswered though – at least by Newag. Why did Impuls-series trains lock up in the first place? Why does 31WE-015 become inoperable between November 21st and December 1st, and then again between December 21st and January 1st?

Experts from Dragon Sector provided a coherent, believable, and data-supported explanation: the software installed in controllers of these trains contains locking functionality that kicks in under specific conditions. For example in 31WE-015 these conditions have to do with the current date, and they just happen to match the dates of the planned maintenance by an independent yard, which was scheduled for November 2021.

In other cases locking conditions involved GPS location of the vehicle falling within specific areas – which again just so happened to cover the areas of independent maintenance yards.

The train manufacturer meanders and evades. On one hand, the company claims that they know nothing of any locking functionality in the software (“in the source code we have such functionality does not exist”). On the other, it implies that this functionality was implemented by Dragon Sector hackers themselves. Then finally admits that the hackers did not modify the software on the trains (and thus could not be the ones who implemented the locking functionality in the first place).

Weird copyright infringement warnings¶

In their “white paper” Newag states that:

When tampering with the control systems, the hackers knew they are committing copyright infringement against NEWAG group, due to warnings being displayed by the system.

I asked the company’s spokesperson about the conditions that would lead to such warnings being displayed. In response I received a statement saying that “we do not know the conditions as we are not the authors.”

So, to summarize:

• company’s spokesperson had no problem whatsoever with stating categorically that the source code of the software used in Impuls-series trains does not contain any locking functionality;
• but he is not able to specify under what conditions copyright infringement warnings are displayed;
• even though Newag itself referred to them in their statements.

Based on available information it seems that these copyright infringement warnings were displayed when the train was moving even though one of the conditions of the locking functionality was satisfied – namely, not having moved for more than 21 days.

The system that manages the displays in the engineer’s cabin is separate from controllers onto which the software that contained locking functionality was deployed. In theory the train manufacturer could have implemented the warning without having a clue about the locking functionality.

But if Newag – as the company claims – had nothing to do with that locking functionality, why should the fact that the train is not locked-up even though one of the conditions for that is met be indicative of copyright infringement? And how did the condition in both of these separate systems end up being identical: 21 days of being stationary?..

And finally, if the locking functionality ended up in the Impuls-series train controllers software without the knowledge and consent of the manufacturer, one would expect the company to work closely with hackers from Dragon Sector in order to uncover, as fast as possible, who, when and how installed the modified software on the vehicles’ controllers. After all, on multiple occassions Newag has stressed how badly this whole affair reflects on the company, and how it negatively impacts its stock price.

Instead of working together to clear all of this up, the company sues the experts, demanding millions in compensation.

SLAPPing the experts?¶

“Based on the media description of the case it seems that we might be talking about a so-called SLAPP – a strategic lawsuit aimed at curtailing public debate.” – I am told by Krzysztof Izdebski, a lawyer working for Stefan Batory Foundation.

The way this works is that people who identify and publicize irregularities are hit with a lawsuit by an entity that had a hand in causing the irregularities, aimed at creating a chilling effect affecting the sued parties, but also anyone else who might be willing to follow their lead.

“EU has recently adopted a directive which is supposed to offer protection from such actions” – Izdebski notes – “The preambule mentions that »as a result of such proceedings, the publication of information on a matter of public interest could be delayed or prevented altogether«”.

It is in public interest interest that journalists and civil society watch this case closely and verify if it indeed is a case of SLAPP and an attempt to curtail freedom of expression and the right to truth.

During the first hearing, Newag requested that the whole trial be made non-public. The judge rejected that request.

Necessary licenses¶

The notorious affair with Impuls-series trains underscores one more issue: the necessity of securing sufficient licenses related to any software that is used for delivering any kind of public service (including public transport).

Today, software is a crucial element of most devices we use daily, including means of transport. It is unacceptable that vendor’s copyright makes it harder to establish a cause of a train becoming inoperable, and makes it illegal for the train operator or a contractor hired by them to fix it! It’s unfathomable that experts who made the analysis and unlocked the vehicles are now forced to deal with a lawsuit claiming they did not have a suitable software license.

From the perspective of passengers and train operators the copyright issue is completely secondary to the question of who implemented the locking functionality in the trains that carry thousands of people on a regular basis, and were purchased using public funds. And to the question of how quickly can they be unlocked and return to normal operation.

One possible solution here is to require that software that is an element of systems or devices funded by public money is released under a free software license, with its source code available. Or at the very least require that organizations that operate devices and systems funded with public money also receive full documentation, source code, and license that explicitly permits modification of that software, including by third parties contracted to do so.

Not only would that remove legal uncertainty and the threat of lawsuits in such cases, but it would also simplify security audits. And, it would allow independent third parties to develop such software further (including fixing bugs) – even if the original vendor is long out of business or simply not interested in continuous development of software for older devices.

Automatically tagging or filtering child sexual exploitation materials (CSAM) cannot be effective and preserve privacy at the same time, regardless of what kind of tech one throws at it. Because what is and what is not CSAM is highly dependent on context.

Literally the same photo, bit-by-bit identical, can be an innocent memorabilia when sent between family members, and a case of CSAM if shared on a child porn group.

The information necessary to tell whether or not it is CSAM is not available in the file being shared. It is impossible to tell it apart by any kind of technical means based on the file alone. The current debate about filtering child sexual exploitation materials (CSAM) on end-to-end encrypted messaging services, like all previous such debates (of which there were many), mostly ignores this basic point.

All the tech in the world¶

Whenever CSAM and filtering of it become a topic of public debate, there is always a bunch of technical tools being peddled as a “solution” to it. These might involve hashing algorithms, machine learning systems (or as the marketing department would call them, “AI”), or whatever else.

And whenever this happens, technical experts spend countless hours verifying the extraordinary claims made by vendors and promoters of these tools, inevitably finding no proof of their purported effectiveness meant to justify their broad deployment to scan everyone’s communication.

But that’s not my point today.

My point today is that even if we had a magical tool that can tell – with perfect 100% accuracy – that a given image or video contains a depiction of a naked child, or that can – with perfect 100% accuracy – identify everything depicted in that media file, it would still not be enough to be able to filter out CSAM accurately and without mis-labeling huge numbers of innocent people’s messages as CSAM.

Context is king¶

This is because, as already mentioned, the information necessary to say whether a given image or video is or is not CSAM is in most cases not available in the file itself.

A video of a naked toddler, sent between two parents or other close family members, is just innocent family memorabilia. A nude photo of a child sent by a parent to a family doctor can be safely assumed to be a request for medical advice. Explicit materials sent consensually between infatuated teens exploring their sexuality are their business, and their alone.

But should any of these same images or videos leak from a compromised phone or e-mail account, and end up in a context of, say, a child porn sharing ring, they immediately become child sexual exploitation materials. Nothing changed about the media files themselves, and yet everything changed about their classification.

Not just the file¶

So, to establish whether a given media file is CSAM or not, whatever magical technological tool being used has to have access to the context. The media file alone won’t do.

This means information on who is talking to whom, when, and what about. What is their relation (close relatives? family doctor? dating?). Contents of their other communication, not just images or videos sent between them. This would have to include historical conversations, as the necessary context might not be obvious from messages immediately surrounding the shared file.

There is simply no way around it, and anyone who claims otherwise is either lying, or has no idea what they are talking about.

Importantly, this is not related to any limitations of our current technology. No amount of technological magic could squeeze any information from a media file that is not available in it. And there is always going to be pertinent contextual information that is not going to be contained in any such file.

The problem is real, the “tech solutions” are not¶

This is not to say that access to all that context is enough to “solve” CSAM. It is not, there are plenty of other problems with any CSAM-filtering proposal and tool out there.

This is also not to say that CSAM – and more broadly, sexual exploitation of children – is not a serious problem. It sadly absolutely is!

But it is not limited to the Internet. It is not going to be solved by a magical filter on our private, intimate communications, even if we could technically build a filter with sufficient accuracy (which we cannot).

If politicians wanted to be serious about solving the problem of sexual exploitation of children they would stop wasting their (and everybody else’s) time and energy on wishful thinking, misdirection, and technosolutionism.

And instead focus all that effort on programs that can actually do something about the problem.

Telegram is a popular – especially in the East – internet messenger. It bills itself as “encrypted”, “private”, and “secure”. One of its creators (and the CEO of the company that operates the service), Pavel Durov, has for years been suggesting, in a more or less direct manner, that other internet messenger services expose our conversations and endanger our privacy.

It’s a pretty crude, yet surprisingly effective strategy for distracting attention away from Telegram’s very real problems with security and privacy. And there are quite a few of those.

What is being encrypted?¶

On Telegram’s website we can find claims, that “messages are heavily encrypted.” This is also how Telegram promotes itself on social media. This would strongly suggest that the contents of messages exchanged using that tool are available only to their senders and recipients – and that nobody else could read them. This kind of encryption is called “end-to-end”, and is exactly what we should expect today when we hear that some communication service is “encrypted.”

In the context of Telegram this is, however, misleading.

For conversations this IM has two modes. By default, messages are encrypted between our device and Telegram’s servers. The company calls it “cloud chats.” Messages sent by us are indeed encrypted, but only between us and the company’s ifnrastructure, and then between that infrastructure and the messages’ recipients. Same goes for messages we receive.

This most definitely is not end-to-end encryptuion. The service’s operator, Pavel Durov’s company, has full access to the contents and the metadata of our conversations, including any files we send, when this mode is in use. And again, this is the default mode for all private and group chats.

A second, optional mode is the so-called “secret chats.” When this mode is used messages are actually end-to-end encrypted, and the only people who could get access to them are us and people we are chating with. Unfortunately, “secret chats” need to be explicitly enabled separately for each of our contacts. And, conversations we are having in this mode are only available between specific devices they were turned on for – if we enable a “secret chat” with one of our contacts while using our mobile device, this conversation will not be available to us when using the desktop client, for example.

“Secret chats” are also not available for group chats and channels. In other words, no groups and no channels on Telegram are encrypted end-to-end. Their contents – and the associated metadata, including members, who sent which message when, and so on – are available to Telegram service operator. And thus to any law enforcement agencies that are able to force or convince the company to comply with data requests.

Suspicious encryption¶

The good news is that MTProto, the message encryption protocol created by Telegram’s team and used both for regular conversations and “secret chats”, does not currently have known vulnerabilities.

But there is also the bad news: cryptologists seem to mostly agree that the way the protocol is designed is generally somewhat suspicious. When desigining and implementing encryption protocols it’s easy to make non-obvious mistakes, and Telegram’s protocol seems to have a lot of places where such mistakes might lurk.

Similar concerns regarding the previous version of MTProto were eventually proven correct.

Cryptology experts indicated where problems could potentially be expected. Telegram’s developers’ reaction was, to put it mildly, not particularly friendly. In the end it turned out that the first version of the protocol indeed had serious vulnerabilities. Including one that was described by an expert as “the most backdoor-looking bug I’ve ever seen.” Time will tell if history repeats itself with the new, currently used version of MTProto.

So, does Telegram use encryption? Yes. Is it possible to use end-to-end encryption in that service? Yes, but in a very limited way, only if you remember to actually enable it, and using a protocol that cryptology experts do not find trustworthy.

Claiming that “Telegram is encrypted” is like claiming that pizza is a healthy food, because there’s a slice of tomato on it.

What about privacy?¶

This is not the only place where Telegram’s promotional materials are misleading or outright false. In the FAQ section of their website the company claims that:

(…) [W]e can ensure that no single government or block of like-minded countries can intrude on people’s privacy and freedom of expression. Telegram can be forced to give up data only if an issue is grave and universal enough to pass the scrutiny of several different legal systems around the world.

To this day, we have disclosed 0 bytes of user data to third parties, including governments.

And yet when a court in India ordered the company in 2022 to provide information – including phone numbers, e-mail addresses, and IP addresses – in relatioon to an on-going case, the company provided the requested data. German law enforcement was also apparently able to receive information about specific Telegram users.

It gets worse. The protocol itself, MTProto, enables tracking Telegram users by simply observing network traffic. Every single message contains an unencrypted header that identifies specific user device (called auth_key_id in the protocol specs).

Among others, Russia has capabilities sufficient to use this for tracking specific peoplewho use Telegram on territory it controlls (thanks to SORM). And apparently it used this capability in Kherson, against Ukrainian partisans. It’s not difficult to imagine, what the consequences could have been.

There are also indications that Telegram might be sharing with law enforcement contents of conversations that are not using the (seldom activated) “secret chats” mode. Activists in Russia learned about this the hard way.

Marketing¶

In some cases, promises made in promotional materials are broken, and the materials then modified accordingly.

For example: as late as 2020 in Telegram’s FAQ one could find the question whether Telegram will ever display ads – along with a simple, clear answer: “No.”

In 2021 Telegramn enabled ads “in some public channels.” The FAQ entry was then modified. Today it is: “Will you have ads in my private chats and groups?”

In and of itself this is of course a pretty small change. But it raises a question about other promises the company makes in their documentation – for example about not selling private data of people who use the service. And they do collect a bunch of such data.

Black PR¶

We should not be surprised, then, that the company, and Pavel Durov personally, deploy a strategy of misdirection and casting doubt on the competition.

A few weeks ago ex-Twitter accounts related to Telegram attacked Signal. Not the first time. For example in 2017 Durov publicly claimed that he expects a backdoor in Signal to be found within 5 years – and that he is willing to bet a million dollars on that.

Tech journalist Max Eddy tried to take that bet, but Durov did not respond.

Telegram vs. Signal¶

There has never been any backdoor found in Signal. As opposed to Telegram’s MTProto, Signals end-to-end encryption protocol is widely considered the golden standard of secure encryption protocol design.

All communication on Signal is end-to-end encrypted – there is simply no way available to send a message that is not fully end-to-end encrypted message on that service. End-to-end encrypted are also groups, stickers, voice and video calls. And all of this is available to all devices connected to one’s account.

Signal is managed by a non-profit organization; Telegram’s operator is a regular company, but it promises it isn’t in it for the money.

Signal does not keep any metadata, apart from date and time of when an account was created, and date and time of the last time the account was active. And has the documentation to prove it – as it does publish all data requests along with its own responses. I have never seen any information that would put that in doubt.

I am not writing this to promote Signal (even though it’s not hard to figure out I find it to be considerably more secure). I am trying to show that it is possible to create a tool that does not have Telegram’s flaws and actually fulfills its promises related to encryption, privacy, and security.

Is Telegram safe and secure?¶

A question about safety and security with regards to any communication tool is always a complex one. A lot depends on individual needs, context in which the tool is to be used, on the reasons for using the tool. But in case of Telegram it is difficult to find situations in which it is the safest available tool for the job. And it is really easy to find situations where using it is dangerous.

There is no such thing as a perfect tool. All internet messaging services, including Signal, had vulnerabilities found in them. Their protocols evolved with time, reacting to often valid criticism. But the way Telegram and Pavel Durov react to criticism and how they misdirect does not build trust.

Safety and security of any tool never boil down only to technical issues (and even these are definitely not Telegram’s strong suit). It is immensely important how strengths and weaknesses of a given tool are being communicated to people who use it. How does the user interface work? Does it make it difficult to make a mistake, for example unintentionally to send a message that is not fully end-to-end encrypted?

Telegram has been misleading people for years, abusing terms such as “encrypted messenger” – and it is not hard to conclude this is intentional at this point. It apparently cooperates with law enforcement even though it claims otherwise. And its user interface seems designed to mislead users into a false sense of security.

This is dangerous. I had worked with investigative journalists who used Telegram to talk to their sources. I had seen on many occasions the shock when I explained what “encrypted” really means in the context of this tool. By trusting Telegram’s claims they had put their sources in danger.

Telegram is certainly aware of all this – many people had pointed all of this out over the years. But it refuses to change.

We find ourselves in a peculiar place. We are more interconnected, yet more misinformed. At ease with more advanced technologies, but more easily mislead by them. “Doing our own research”, but ending up deeper in conspiratorial rabbit holes.

When discussing complex topics — pandemic, war, the housing crisis, or some thorny family affairs — it is surprisingly easy to jump to conclusions, to oversimplify, ignore crucial nuance, and thus get untethered from reality. To label someone as “evil”, “unethical”, fall back on tribalism. Our brains are always looking for a shortcut, and many of these shortcuts lead us astray. Sometimes we get fooled, sometimes we fool others. Neither helps in the long run.

I am as guilty of this as anyone else. But I also feel the only way we can deal with problems we’re facing, on any level, is by talking them through. Here’s a list of a few rules of thumb I find particularly helpful to keep in mind when thinking about and discussing complex politics- and society-adjacent topics.

They are not absolutes, and do not always apply, but they can help avoid some pitfalls we fall into all too often.

Explanation is not a justification¶

The fact that there exists an explanation of an action or decision does not automatically mean that the action or decision was justified. Explanation is only about being able to understand why somebody did something. Justification is about the moral judgment over that person and what they did.

It is chillingly easy to fall into the trap of assuming that a person is justifying an unethical act of someone’s just because that person is trying to understand or explain it. Making such an assumption easily leads to dismissing that person as a “supporter” of that unethical act, and thus unethical themselves. This in turn makes it very difficult to talk about causes of a given situation, and about making it less likely it happens in the future.

We have to be able to discuss reasons behind a specific decision or action, regardless of how we  feel about the morality of it. If we want to make sure something bad does not happen again, understanding the reasons it happened is often more important than passing moral judgment.

The flip-side of this is that providing an explanation of something is not the same as providing a justification for it. “This is why I did it” is not the same as “this is why I was in the right doing it”. If by explaining an action somebody is be trying to deflect blame — they probably should get called out on that.

Of course, this is not to say that an explanation can never be an important element of valid justification.  It can, and it often is. But explanation and justification are different, even if one can support the other to some degree.

Hanlon’s razor¶

We humans are great at ascribing agency and intentionality where there is none. We love to make things about ourselves. We see faces in the clouds, deity’s wrath in volcanic eruptions, and targeted, premeditated malice in somebody else’s decisions or actions — especially ones that affect us in a bad way.

Hanlon’s razor states:

Never attribute to malice that which is adequately explained by stupidity.

I personally expand it to also include incompetence, laziness, and other lesser vices. It is, basically, a tool for assessing explanations of a given set of actions or decisions. In many cases, there is no need to assume malice in order to explain a problematic action or decision. In some cases assuming malice is actually counter-productive.

We don’t need to assume maliciousness on part of civil servants in the Netherlands who deployed the (as it turns out) racist system for flagging “suspicious” use of childcare benefits to know this was unacceptable. Pondering whether that was malicious on their part or not is in this case moot, and can distract from a broader and more immediately important question of: how to fix the broader system such that this never happens again, regardless of malice or incompetence?

That’s not to say that there is never malice, of course. Sometimes there very much is. But in the end, in a lot of cases it might not matter much — bad outcomes are bad regardless of whether they are caused by malice, or by incompetence. Important systems, especially ones on which our livelihoods or health and well-being depends on, should be resilient to either.

Or, as Grey’s law puts it:

Any sufficiently advanced incompetence is indistinguishable from malice

Which is closely related to…

A system’s purpose is what it does¶

Let’s say we have a complex system — technical, political, social, whatever the kind. And let’s say that it keeps having certain bad outcomes. Everyone involved in creating and maintaining it keeps insisting that these bad outcomes are accidental, and keep promising this can be fixed, but somehow it never is. At some point it just makes sense to treat these bad outcomes as the actual purpose of the system. If they really were not, surely the system would have been fixed already!

Coined by Stafford Beer, of Cybersyn fame, this rule is an great way of cutting through elaborate excuses given about any unacceptable outcomes of a system.

For example: if a government policy supposedly meant to fight the housing crisis (say, by guaranteeing low-interest loans to prospective buyers) ends up raising apartment prices but not causing actual improvement in the overall housing availability, at some point it’s reasonable to say that the purpose of this policy is not to fight the housing crisis — but to funnel free money to real estate developers.

Or: if a policy intended to combat drug abuse ends up predominantly incarcerating only a specific part of the population (say, young Black men), but in no real reduction in overall drug use, then it is reasonable to say that the purpose of the policy is not reduction of drug use — but persecution of a specific group.

Mind you, this doesn’t necessarily mean that the system in question was deliberately designed to be like this! It doesn’t necessarily mean its designers and maintainers are intentionally lying about what its purpose is or was supposed to be, maliciously hiding the fact that the purpose was different (see Hanlon’s razor above). It might be accidental, or related to incompetence, or to the fact that we’re all a product of the society we grew up in and the circumstances we inhabit.

In the end it doesn’t really matter what the original idea for that system was. If a system is allowed to stay in place even though it is clearly ineffective in its stated purpose, then it is fair to say that the actual purpose has to be something else.

Life is not a zero-sum game¶

There are situations which are a zero-sum game. Trying to get tickets to a popular concert is an example: if you get your tickets, I might not get mine. The resource is strictly limited and we are competing for it. Your win is my loss.

But in a lot of cases, things that are talked about as if they were a zero-sum game — are not. Take immigration: it is often talked about in “us vs. them” terms, with an implied assumption that there is some kind of resource that is strictly limited, and that the migrants, once let into the country, will compete over it with its current residents.

This is simply not the case. Yes, people coming into the country might need education, healthcare, social services — but they will also create more demand for local goods and services, strengthening the economy. Often they might be willing to work jobs that nobody else wants to take. They will pay taxes. They will bring their culture and cuisine with them, enriching the lives of everyone.

This is true for a lot of thorny political and social issues that are portrayed publicly or talked about as if they were a zero-sum game. Sometimes this becomes outright absurd and almost self-parodying, as with the so-called “Schrödinger’s immigrant”, who supposedly “steals our jobs” and simultaneously is “too lazy” to get one, hanging on unemployment benefits instead.

Two things can be true at the same time¶

In a way, truth is also often not a zero-sum game. For example, it is true I work a lot, but it is also true that I am quite a lazy person. It is true that Titanic’s captain’s actions can be considered reckless by today’s standards, and had contributed to the catastrophe, but it is also true they probably did not appear reckless to him or his peers at the time.

This perhaps sounds obvious, but becomes much less so when strong emotions come into play.

Are COVID vaccines a miracle of science, developed and tested in impossibly short time and saving countless lives? Or are they another vestige of Big Pharma’s flavor of neo-colonialism, based on who gets easy access to them and who doesn’t; who gets to manufacture them and who doesn’t; and who gets to profit from them? Both are true. We should be able to admire the former while insisting the latter is outright unacceptable.

This became particularly stark (and somewhat personal) to me when Putin’s Russia launched a full-scale invasion against Ukraine in February 2022. A lot of left-leaning, anarchist-y people seemed to defend Russian aggression by pointing out atrocities committed by US and NATO in Iraq or Afghanistan. How dare I “take side of NATO” here, have they not done enough evil?

But two things can be true at the same time — the US and NATO should be rightfully made accountable for their actions, of course, but that does not make Russia’s invasion and the atrocities it brought on civilians in Ukraine acceptable or justifiable in any sense.

This is a form of a false dichotomy, making it seem as if we have to “choose a side” out of a limited set of options. But the world is more complex than that. We have to be able to walk and chew gum.

These are not absolutes¶

All of these are guidelines, not absolute and unshakable rules. In some cases they might even run against one another. That’s okay.

An explanation can be an important part of a justification of some action — it’s just that it should not automatically, always be assumed so. An action or a decision can be underpinned by malice, and in some cases it is important to establish if it is — it’s just that it’s not necessarily always so, and it’s not always worthwhile to get stuck on that question.

A system’s outcomes might misalign with its stated purpose temporarily, and a fix might be on the way — question is, how long has the system been allowed to remain broken, and will it actually get fixed? Even if some problem is not a zero-sum game, resources are rarely truly unlimited and it might still make sense to ask about how they get allocated. And sometimes we do have to choose a side.

To me, these guidelines act as useful safety valves when thinking and discussing complex subjects. They help me notice when an argument might be going astray.

Bringing it all together¶

I find it startling how easily, how eagerly we retreat into tribalism when discussing important, complex, emotionally charged subjects. How quickly we decide there surely is malice involved, how quickly we can be manipulated into thinking something is a zero-sum game and we better, in our own interest, deny somebody’s access to some perceived “limited resource.”

And once we do, we gleefully dismiss “the other side” — suddenly there’s an “other side”, as if every problem only ever had two possible solutions! — as unethical, outright malicious or at least woefully misinformed. Then we don’t have to consider arguments that go against our strongly-held convictions anymore, we don’t have to deal with the fact that the world is more complex than “us vs. them.” After all we are “us”, and if “they” are not with us, they’re clearly against us.

The complexity, however, does not go away, regardless of how hard we try to ignore or hide it.

Recent moves by Eugen Rochko (known as Gargron on fedi), the CEO of Mastodon-the-non-profit and lead developer of Mastodon-the-software, got some people worried about the outsized influence Mastodon (the software project and the non-profit) has on the rest of the Fediverse.

Good. We should be worried.

Mastodon-the-software is used by far by the most people on fedi. The biggest instance, mastodon.social, is home to over 200.000 active accounts as of this writing. This is roughly 1/10th of the whole Fediverse, on a single instance. Worse, Mastodon-the-software is often identified as the whole social network, obscuring the fact that Fediverse is a much broader system comprised of a much more diverse software.

This has poor consequences now, and it might have worse consequences later. What also really bothers me is that I have seen some of this before.

As seen on OStatus-verse¶

Years ago, I had an account on a precursor to the Fediverse. It was based mainly around StatusNet-the-software (since renamed as GNU social) and the OStatus protocol. The biggest instance by far was identi.ca — where I had my account. There was also a bunch of other instances, and there were other software projects that also implemented OStatus — notably, Friendica.

For the purpose of this blogpost, let’s call that social network “OStatus-verse”.

Compared to the Fediverse today, OStatus-verse was miniscule. I do not have specific numbers, but my pull-numbers-out-of-thin-air rough estimate is, say, ~100.000 to ~200.000 active accounts on a very good day (if you have the actual numbers, do tell and I will gladly update this blogpost). I do not have exact the numbers for identi.ca either, but my rough estimate is that it had between 10.000 and 20.000 active accounts.

So, around 1/10th of the entire social network.

OStatus-verse was small but lively. There were discussions, threads, and hashtags. It had groups a decade before Mastodon-the-software-project implemented groups. It had (desktop) apps — I still miss the usability of Choqok! And after a bit of nagging I was even able to convince a Polish ministry to have official presence there. As far as I know this is the earliest example of a government-level institution having an official account on a free-software-run, decentralized social network.

Identipocalypse¶

Then one day, Evan Prodromou, the administrator of identi.ca (and the original creator of StatusNet-the-software), decided to redeploy it as a new service, runningpump.io. The new software was supposed to be better and leaner. A new protocol was created because OStatus had very real limitations.

There was just one snag: that new protocol was incompatible with the rest of OStatus-verse. It tore the heart out of that social network.

People with identi.ca accounts lost their connections on all OStatus-compatible instances. People with accounts on other instances lost contact with people on identi.ca, some of whom were pretty popular in OStatus-verse (sounds familiar?..).

It turned out that if an instance is 1/10th of the whole social network, a lot of social connections lead through it. Even though other instances existed, suddenly a huge chunk of active users just vanished. Many groups fell mostly silent. Even if one had an account on a different instance, and contacts on other instances, a lot of familiar faces just disappeared. I stopped using it soon after that.

From my perspective, this single action set us back at least five if not ten years as far as promoting decentralized social media is concerned. Redeployment of identi.ca fractured the OStatus-verse not just in the social connections sense, but also in the protocol and developer community sense. As pettter, a fellow OStatus-verse veteran put it:

I think a bit of nuance on the huge-blow thing is that it didn’t only impact by cutting social connections, but also in protocol fragmentation, and in fragmenting developer efforts into rebuilding basic blocks of a federated social web time and again. Perhaps it was a necessary step to them come back together in designing AP, but personally I don’t think so.

Of course, Evan had all the right to do that. It was a service he ran, pro bono, on his own terms, with his own money. But that does not change the fact that it crippled the OStatus-verse.

I believe we need to learn from this history. Once we do, we should be worried about the sheer size ofmastodon.social. We should be worried by the apparent monoculture of Mastodon-the-software on the Fediverse. And we should also be worried about identifying all of Fediverse with just “Mastodon”.

Cost of going big¶

There are real costs and real risks related to going as big as mastodon.social has. Those costs and especially those risks are both to that instance itself, and to the broader Fediverse.

Moderation on the Fediverse is largely instance-centric. A single gigantic instance is difficult to moderate effectively, especially if it has registrations open (as mastodon.social currently does). As the flagship instance, promoted directly in official mobile apps, it draws a lot of new registrations — including quite a few problematic ones.

At the same time, this also makes it more difficult for admins and moderators of other instances to make moderation decisions about mastodon.social.

If an admin of a different instance decides mastodon.social’s moderation is lacking for whatever reason, should they silence it or even defederate from it (as some already have, apparently), thus denying members of their instance access to a lot of popular people who have accounts there? Or should they keep that access, risking exposing their own community to potentially harmful actions?

The sheer size of mastodon.social makes any such decision of another instance immediately a huge deal. This is a form of power: “sure, you can defederate from us if you don’t like how we moderate, but it would be a shame if people on your instance lost access to 1/10th of the whole fedi!” As GoToSocial’s site puts it:

We also don’t believe that flagship instances with thousands and thousands of users are very good for the Fediverse, since they tend towards centralization and can easily become ‘too big to block’.

Mind you, I am not saying this power dynamic is consciously and purposefully exploited! But it undeniably exists.

Being a gigantic flagship instance also means mastodon.social is more likely to be a target of malicious actions. On multiple occasions over the last few months it found itself under DDoS, for example. A couple of times it went down because of it. Resilience of a federated system relies on removing large points of failure, and mastodon.social is a huge one today.

The size of that instance and it being a juicy target also means that certain hard choices need to be made. For example, due to being a likely target of DDoS, it is now behind Fastly. This is a problem from the privacy perspective, and from the perspective of centralization of Internet infrastructure. It is also a problem that smaller instances avoid completely by simply being smaller and thus less interesting targets for anyone to take down with a DDoS.

Apparent monoculture¶

While the Fediverse is not exactly a monoculture, it is too close to being one for comfort. Mastodon-the-non-profit has outsized influence on all of fedi. This makes things tense for people using the social network, developers of Mastodon-the-software and other instance software projects, and instance admins.

Mastodon is neither the only instance software project on fedi, nor the first. For example, Friendica has been around for a decade and a half, long before Mastodon-the-software got it’s first git commit. There are Friendica instances (e.g. pirati.ca) operating today within Fediverse which had been part of the OStatus-verse a decade ago!

But calling all of Fediverse “Mastodon” makes it seem as if only Mastodon-the-software exists on the Fediverse. This leads people to demand features to be added to Mastodon and to ask for changes that have sometimes already been implemented by other instance software. Calckey already has quote-toots. Friendica has threaded conversations and text formatting.

Identifying Mastodon with the whole fedi is also bad for Mastodon-the-software developers. They find themselves under pressure to implement features that might not entirely fit with Mastodon-the-software. Or, they find themselves dealing with two groups of vocal users, one demanding a certain feature, other insisting it does not get implemented as too big of a change. Many of such situations could probably be more easily dealt with by clearly drawing a line, and pointing people to other instance software that might fit their use-case better.

Finally, Mastodon is currently by far (measured by active users, and by number of instances) the most popular implementation of the ActivityPub protocol. Every implementation has its quirks. With time, and with new features being implemented, Mastodon’s implementation might have to drift further away from the strict spec. It’s tempting, after all: why go through an arduous process of standardizing any protocol extensions if you’re the biggest kid on the block anyway?

If that happens, will every other implementation have to follow it, thus drifting along with it but without actual agency in what changes to the de facto spec are implemented? Will that create more tensions between Mastodon-the-software developers and developers of other instance software projects?

The best solution to “Mastodon misses feature X” is not always “Mastodon should implement feature X.” Often it might be better to just use a different instance software, better suited for a particular task or community. Or to work on a protocol extension that would allow a particularly popular feature to be reliably implemented by as many instances as possible.

But that can only work if it’s clear to everyone that Mastodon is only a part of a bigger social network: the Fediverse. And that we already do have a lot of choice as far as instance software is concerned, and as far as individual instances are concerned, and as far as mobile apps are concerned.

Sadly, that seems to go against recent decisions by Eugen, which go towards a pretty top-down (not quite vertically integrated, but gravitating towards that) model of official Mastodon mobile apps promoting the flagship mastodon.social instance. And that is something to worry about, in my opinion.

A better way¶

I want to be clear I am not arguing here for freezing Mastodon development and never implementing any new features. I also agree that the signup process needs to be better and more streamlined than it had been before, and that plenty of UI/UX changes need be implemented. But all this can and should be done in a way that improves resilience of the Fediverse, instead of undermining it.

Broader changes¶

My laundry list for broader needed changes to Mastodon and the Fediverse would be:

1. Close registrations on mastodon.social, now
   It is already too big and too much of a risk for the rest of the Fediverse.
2. Make profile migration even easier, also across different instance types
   On Mastodon, profile migration currently only moves followers. Who you follow, bookmarks, block and mute lists can be moved manually. Posts and lists cannot be moved — and that’s a big problem for a lot of people, keeping them tied to the first instance they signed-up for. It’s not insurmountable — I had moved my profile twice and found it perfectly fine. But it is too much friction. Some other instance software projects are working on allowing post migrations too, thankfully. But it’s not going to be a quick and easy fix, as ActivityPub design makes it very hard to move posts between instances.
3. By default, official apps should offer new people a random instance out of a small list of verified ones
   At least some of these promoted instances should not be controlled by Mastodon-the-non-profit. Ideally, some instances should run different instance software as long as it uses compatible client API.

What can I do myself?¶

And here are things we ourselves can do, as people using the Fediverse:

1. Consider moving off of mastodon.social if you have an account there.
   That’s admittedly a big step, but also something you can do that most directly helps fix the situation. I had migrated frommastodon.social years ago, and never looked back.
2. Consider using an instance based on a different software project
   The more people migrate to instances using other instance software than Mastodon-the-software, the more balanced and resilient Fediverse we get. Hearing a lot of positive opinions about Calckey, for example. GoToSocial is also looking interesting.
3. Remember that Fediverse is more than just Mastodon
   Language matters. When talking about the Fediverse, calling it “Mastodon” is only making the issues I mention above more difficult to deal with.
4. If you can, support projects other than the official Mastodon ones
   At this point Mastodon-the-software project has a lot of contributors, a stable development team, and enough solid funding to continue safely for a long while. That’s great! But same cannot be said about other fedi-adjacent projects, including independent mobile apps or instance software. In order to have a diverse, resilient Fediverse, we need to make sure these projects are also supported, including financially.

Closing thoughts¶

First of all, the Fediverse is a much more resilient, more long-term viable, safer, and more democratized social network than any centralized walled garden. Even with its Mastodon monoculture problem, it is still not (and can’t be) owned or controlled by any single company or person. I also feel that it is a better, safer choice than social networks that only cosplay decentralization and pay lip service to it, like BlueSky.

In a very meaningful way, OStatus-verse can be said to have been an early version of the Fediverse; as noted before, some instances that had been part of it then are still running and part of the Fediverse today. In other words, Fediverse had been around for a decade and a half by now, and survived the Identipocalypse even as it got badly hurt by it, while observing both the birth and the untimely passing of Google+.

I do believe Fediverse is leaps and bounds more resilient today than OStatus-verse had been before the identi.ca redeploy. It’s an order of magnitude (at least) larger in terms of user base. There are dozens of different instance software projects and tens of thousands active instances. There are also serious institutions invested in its future. We should not be panicking over all I wrote above. But I do think we should be worried.

I do not attribute malice to recent actions of Eugen (like making official Mastodon apps funnel new people towards mastodon.social), nor to past actions of Evan (redeploying identi.ca on pump.io). And I don’t think anyone should. This stuff is hard, and we’re all learning as we go, trying to do our best with the limited time we have available and restricted resources in our hands.

Evan went on to be one of the main creators of ActivityPub, the protocol the Fediverse runs on. Eugen had started Mastodon-the-software project in the first place which I strongly believe allowed Fediverse to flourish into what it is today. I really appreciate their work, and recognize that it’s impossible to do anything in social media space without someone having opinions on it.

That does not mean, however, we cannot scrutinize these decisions and should not have these opinions.

---

Update: I did a silly; mastodon.social is behind Fastly, not CloudFlare, of course. Fixed, thank you to those who poked me about it!

Update 2: Heartfelt thanks to Jorge Maldonado Ventura for providing a Spanish translation of this blogpost, published under CC BY-SA 4.0. ¡Gracias!