1Introduction
A quick note
To be honest, this article is more an excuse to talk about what I think is missing from discussions about security in messaging applications than mainly a critique of the hackea article.
This piece uses a critique of “Matrix? No, thanks.” as a way into a broader argument: that debates about secure tools often distract from the more important question of operational security. The hackea.org article is worth examining because its flaws are instructive. It gets real things right. Where it goes wrong, it goes wrong in the same ways most tool-focused security discourse goes wrong — and that pattern is worth naming.
2What the Hackea Article Actually Says
The hackea.org piece (H.A.C.K.E.A., 2020) (written in 2020, and still circulating today as an argument against Matrix) makes several distinct claims, and it’s worth separating them before evaluating them.
First, it raises origin concerns: Matrix was born inside Amdocs, a multinational corporation founded in Israel, and various online sources connect Amdocs to Israeli intelligence. The article immediately hedges this, asking readers to treat those connections as “FUD” and promising to focus on “software analysis facts” instead. That self-correction is intellectually honest. It’s also, unfortunately, not quite followed through.
Second, it cites Disroot’s 2018 decision to shut down their Matrix instance and go back to XMPP (Disroot, 2018). Disroot’s own explanation is worth reading carefully: their concerns weren’t purely technical — they were operational. They noted that Matrix stores room data indefinitely across all participating servers, that user addresses are visible to anyone in a room, and that a growing presence of bots mapping the network was particularly problematic for their use case. Disroot described Matrix as prioritizing usability over privacy — not as a malicious design choice, but as a fundamental architectural orientation.
Third, and most substantially, the article leans on a 2019 document by maxidorius titled “Notes on Privacy and Data Collection of Matrix.org” (maxidorius, 2019a). This is the strongest plank of the hackea case.
3The Maxidorius Report: What It Found and What Happened Next
The 2019 research document (maxidorius, 2019a) is detailed, technically grounded, and methodologically transparent. The author’s verification approach was simple enough for anyone to reproduce: open browser dev tools and watch the network tab; tail synapse logs; use a reverse proxy to observe requests in real time.
What it found was a significant amount of data being sent to Matrix.org and vector.im infrastructure even when users ran their own homeservers — Matrix IDs, email addresses and phone numbers from contact discovery, IP addresses, usage patterns, device information, room IDs, and the social graph implied by server-to-server communication. On top of that: uploaded files were publicly accessible without access controls, end-to-end encryption was off by default, and Cloudflare was performing TLS termination on Matrix.org and vector.im, meaning a third party had access to federation traffic in plaintext.
The Matrix project’s co-founder responded in the gist comment thread and conceded several points — contact lookup should require explicit consent, contacts should be hashed before bulk uploads, the integration manager was calling home too frequently, notary servers should eventually go. He disputed other findings as hyperbolic or based on non-default configurations.
What’s notable isn’t who “won” the exchange. It’s that the concessions were themselves significant. The issues were real enough that Matrix shipped what it called “privacy improvements” in Synapse 1.4 and Riot 1.4 shortly after the report appeared (Matrix.org, 2019). A follow-up Part 2 paper (maxidorius, 2019b) documented a global federation data leak and examined in detail how Matrix.org handled a GDPR data subject request — raising pointed legal questions about whether they had a lawful basis for processing the data they were collecting.
4Where the Hackea Critique Holds Up
The hackea article is at its strongest when it stays close to these documented behaviors.
Decentralization as a concept and decentralization as actually implemented are not the same thing. A federated system shares information among servers by design — the question is what it shares, with whom, under what defaults, and whether users are meaningfully told about it. The 2019 research (maxidorius, 2019a) showed that the defaults were privacy-hostile and that users weren’t informed, not as an occasional oversight but systematically, across multiple subsystems.
The gap the article identifies — between the hype of decentralization and what the code was actually doing — is legitimate and worth taking seriously. A project marketing itself as a privacy-respecting alternative to centralized platforms, while silently routing substantial user data through central servers, has a real credibility problem. Pointing to what the protocol could theoretically support doesn’t resolve it. Defaults are what users actually get.
5Where the Hackea Critique Runs Into Trouble
The article’s weaknesses are also instructive, because they’re common.
5.1Origins are not evidence
The Amdocs-Mossad thread is introduced, acknowledged as unverified FUD, and then quietly left sitting in the article without resolution. The reader is told to disregard it and simultaneously left with it. That’s a rhetorical move, not an argument. The core concept behind Tor — onion routing — was developed in the mid-1990s by researchers at the U.S. Naval Research Laboratory to protect American intelligence communications online. The internet itself grew out of DARPA. Signal has its own complicated funding history. What matters for a protocol’s trustworthiness is its architecture, its code, its governance, and whether its claims can be independently verified — not its genealogy.
5.2It conflates layers it should distinguish
Matrix the protocol, Synapse the reference server implementation, Riot/Element the client, matrix.org the public homeserver, vector.im the identity server, and New Vector the company are related but genuinely different things. When the article says Matrix is sending your data to central servers, it’s sometimes describing a default configuration choice, sometimes a client implementation decision, sometimes a protocol design issue. That distinction matters a lot for whether the problem is fixable and what fixing it would look like.
5.3It’s a 2020 document being used as a current argument — and that creates a mismatch
To be fair to hackea, the article was a reasonable contemporaneous critique based on available evidence at the time. The trouble is that it keeps circulating as current ammunition against Matrix, without acknowledgment that Matrix shipped privacy improvements in direct response to the 2019 findings (Matrix.org, 2019). Whether those improvements fully resolved the underlying issues is a genuinely open question that deserves current investigation. But “this was documented as a problem in 2019” and “this remains a problem today” are different claims, and conflating them makes the argument weaker than it needs to be.
5.4It under-examines the alternative
XMPP is endorsed throughout, largely by implication. But XMPP has its own metadata exposure characteristics, its own federation trade-offs, and a long history of inconsistent end-to-end encryption support across clients. The comparison never gets explicit enough to evaluate.
6The Deeper Problem: What Tool Debates Miss
This is where the critique of the hackea article becomes a critique of a whole genre of security conversation.
Arguments about which protocol is safer tend to settle on encryption and metadata at the transport and server level. Those things matter. But for most people whose communications security genuinely matters — activists, journalists, organizers, whistleblowers — the realistic threat model looks quite different.
End-to-end encryption doesn’t protect against infiltration by hostile participants in a group. It can’t prevent screenshots. It can’t stop participants from publishing logs. It doesn’t protect against compromised devices. It doesn’t prevent social engineering or coercion. It can’t do anything about what happens after a message is received.
Disroot’s reasoning for leaving Matrix (Disroot, 2018) is useful here again. Their concern wasn’t primarily cryptographic — it was about room history persisting across servers, user addresses being visible to anyone in the room, and the risk of bots mapping their community’s social graph. Those aren’t protocol-level vulnerabilities in the traditional sense. They’re operational realities that any federated system would face in some form.
The security of a communication system isn’t just a property of the protocol. It’s a property of the entire operational context: who has access, under what circumstances, with what incentives, and with what discipline. A technically solid protocol used carelessly can offer less real protection than a flawed one used with genuine operational awareness.
That dimension is what the hackea article — like most tool debates — gives too little attention to.
Operational security means knowing your threat model before reaching for a tool. It means compartmentalizing information so that not every participant holds every piece of it. It means verifying identities out-of-band, which almost nobody actually does. It means paying attention to what happens on devices, not just in transit — because encryption in transit doesn’t help much if your phone is unlocked and unattended. It means treating metadata as seriously as content, because who you talk to, when, how often, and from where often reveals more than what you say (Mayer et al., 2016). And for sensitive coordination, it sometimes means using abstracted or coded language — not because any given tool is compromised, but because the people at the other end of the conversation are always the real variable.
None of this is an argument against caring which tools you use. Protocol design matters. Default configurations matter. The findings in the maxidorius report mattered (maxidorius, 2019a). But choosing the right tool is one part of a security posture, not a substitute for having one.
7Conclusion
The hackea.org article (H.A.C.K.E.A., 2020) asks a legitimate question: should you trust a platform that routes substantial user data through central servers while marketing itself as decentralized? Based on the documented 2019 findings (maxidorius, 2019a), the trust gap was real and the criticisms were warranted.
But the article’s rhetorical moves — the unresolved Amdocs FUD, the conflation of protocol with deployment, the historical snapshot presented as current fact — illustrate a wider problem. Security discourse that focuses on tool selection is more comfortable than security discourse that focuses on human behavior, threat modeling, and operational discipline. It produces something that feels like a conclusion (use XMPP, not Matrix) while leaving the harder questions untouched.
The real question isn’t just “which tool?” It’s: given your actual threat model, who do you communicate with, about what, with what discipline, under what circumstances, and with what verification? A tool critique that doesn’t help answer those questions is incomplete — however accurate its technical findings may be.