Tchap is France's own messenger. Not a procurement contract with WhatsApp, not a Slack licence, but a service the French state built and runs itself, used across ministries and public-sector bodies precisely so that sensitive government conversations would not sit on a foreign company's infrastructure. It was the responsible choice. It is roughly the choice you would make if you took privacy seriously and had a national budget to act on it.
And in June 2026, it got scraped. Around 7 June, France's national cybersecurity agency, ANSSI, detected suspicious activity on the platform. Not a zero-day in the cryptography. Not a flaw in the maths. A single user account, compromised through social engineering. One person talked into giving up access, and from that one foothold the attacker pulled data out of every channel that user happened to belong to.
"A single Tchap account was compromised through social engineering, allowing the attacker to scrape data from every channel that user belonged to."
As reported by The Register, 9 June 2026The attacker claims to have walked away with about 13.5GB of data: roughly 560,000 messages and information on more than 73,000 accounts, including email addresses, organisation details, meeting links, and account and device metadata. French officials said the damage was limited, and that the attacker could only see messages in public chat rooms accessible to all Tchap users. We will take them at their word on the scope. The number that matters is not how bad it could have been. It is how little it took.
§ 01The headline everyone will write
The obvious framing is "a government got hacked," with the implied snark that if the French state can't secure its own chat app, what hope does anyone have. That framing is lazy and it is wrong, and it lets the actual lesson slip past unexamined.
France did almost everything right. It declined to outsource sensitive communication to a third party. It ran its own service. When something went wrong, its national cybersecurity agency caught it quickly. The cryptography wasn't broken. The institutional response was, by the standards of these stories, fast and competent. If a government this serious about the problem can still get scraped through one borrowed login, the problem is not competence. The problem is shape.
§ 02What 'secure' usually means, and what it misses
When a messaging service calls itself secure, it almost always means one specific thing: the messages are encrypted, so that someone intercepting traffic on the wire cannot read them. This is genuinely valuable, and Tchap, built on the same family of technology as many serious secure messengers, has it. End-to-end encryption protects a message in transit. It is the armoured van between two points.
But encryption in transit says nothing about what happens at the destinations. In a centralised system, the server is a destination for everything. It has to be: it stores messages so they can be delivered to people who are offline, it indexes channels so they are searchable, it maintains the membership lists that decide who can see what. The server is the thing that holds the whole conversation graph in one place so the product can function. That is not a bug in Tchap. It is what a central server is for.
And the moment everything is gathered in one place to be useful, it is also gathered in one place to be taken. A compromised account is, from the server's point of view, just a legitimate user asking for the channels it belongs to. The server obliges, because obliging is its job. The encryption was never the part under attack.
§ 03Why one account became a mass scrape
Read the mechanics carefully, because they are the whole point. The attacker did not break a thousand accounts. They broke one, and then asked the server, politely and through the front door, for everything that one account could see. Because the data sits centralised, "everything one account can see" is a very large number. Every channel that user belonged to, every message history in those channels, the membership records, the metadata. The blast radius of a single compromised login is the entire surface that login was entitled to touch.
Social engineering is not exotic. It is the oldest attack there is: convince a human to do something on your behalf. You cannot patch it, you cannot encrypt it away, and you will never fully train it out of a population of tens of thousands of users. Some percentage of people will always be talked into clicking the wrong thing. A secure system has to assume that an attacker will eventually get one valid login, because they always eventually do.
So the real question is not "how do we make sure no account is ever compromised." That is unwinnable. The real question is: when one account inevitably falls, how much does it expose? In a centralised messenger, the answer is "everything that account could reach, all of it, in one pull." That is the architecture answering, not the attacker being clever.
§ 04The thing OpenDescent does differently
Our answer to this is not "we have better security policies" or "we train our users harder." Policies change, training fades, and both depend on an organisation continuing to care. Our answer is structural, and structure does not get tired.
OpenDescent has no central server holding everyone's messages. There is no machine sitting in the middle that stores the conversation graph, indexes the channels, and keeps the membership lists. Your messages live on the devices of the people in the conversation, end-to-end encrypted, moving peer to peer across the network. There is no central database, which means there is no central database to scrape.
Walk the Tchap attack through this architecture and watch where it dead-ends. An attacker social-engineers one user and steals their identity key. Bad, certainly, for that one user: the attacker can now read what that specific person could read, and impersonate them until the key is rotated. But there is no server to turn to and ask for "every channel this account belongs to," because no server holds that. There is no 13.5GB pull, because the data was never assembled in one place to begin with. The blast radius of one compromised account is one account, not a national ministry's message history.
- No central store. Messages live with the participants, not on a server that holds the lot. There is no single database whose compromise exposes the network.
- No single login to the whole graph. Compromising one identity exposes one identity's reach, not everyone's, because no account is a window onto a central index.
- Encryption that protects storage, not just transit. The data at rest sits on participants' own devices, under their own keys, not pooled on infrastructure an attacker can ask once and drain.
You can read the specifics on our security page and the full feature set on the features page. The short version is the one worth remembering: there is no central server, so there is no single account or database whose compromise hands an attacker the whole network.
If the Tchap story made you uneasy, it should: it is the clearest demonstration in a while that "encrypted" and "safe from a mass scrape" are not the same claim. OpenDescent removes the central store entirely. There is no honeypot to social-engineer your way into.
§ 05Privacy as architecture, not policy
This is the idea the whole product is built around, and the Tchap breach is an almost perfect illustration of it. Privacy that depends on a policy is privacy that depends on someone keeping a promise: the promise to secure the server, to train the staff, to resist the subpoena, to not change the terms after an acquisition. Those promises are made by good people in good faith, and they are still promises, which means they can be broken, withdrawn, or simply overwhelmed by one user who clicked the wrong link.
Privacy as architecture is different. It does not ask anyone to keep a promise. It removes the thing that the promise was protecting. There is no central store to be breached, so no one has to promise to defend it well. The French government did not fail to keep its promise. It kept the promise admirably. The promise was just attached to a shape that could be drained through a single door, and shape beats good intentions every time the two are tested against each other.
§ 06For people with something to keep
It is tempting to read a story about a government messenger and conclude that none of this touches you. You are not a ministry. Your conversations are not state secrets. But the lesson generalises downward perfectly. Whatever service holds your messages in one place is the same shape as Tchap, just with a smaller logo and probably a weaker cybersecurity agency watching it. The mechanism that emptied 560,000 government messages through one login is the same mechanism waiting in every centralised chat app you use to plan a birthday, coordinate a family, or vent about a colleague.
None of that is content to be hidden. It is ordinary life, and ordinary life is worth keeping private. We have never built OpenDescent for people with something to hide. We built it for people with something to keep: the dull, daily, unremarkable record of a life that nobody else has any business assembling in one place. The surest way to keep it is to make sure it was never gathered into one place to begin with.
The French government built a careful, well-run, encrypted messenger, and a single social-engineered login still scraped it. That is not an argument for giving up on private messaging. It is an argument for changing its shape. Take the central store away, and the attack that worked on Tchap has nowhere to land.