In 2021, researchers at ETH Zürich published a formal analysis of Matrix’s Megolm group ratchet. They called the bug what it was: state machine confusion. The name told you the affected component (Megolm), the class of bug (state machine), and the failure mode (confusion between sender and recipient states). Matrix’s developers mapped it straight to their codebase. Fix shipped in weeks.
Now consider a class of Signal Protocol session-restoration issues that bounced through audit reports and academic papers for months without a stable identifier. Every author described it differently. Stale ratchet state. Post-compromise delivery race. Sometimes just a paragraph buried in a threat-model appendix. Mitigation discussions fragmented across mailing lists because no one could search for a canonical term and surface the full conversation.
Here is the argument: the gap between a protocol-level finding and its real-world mitigation is often determined by how the finding is named. Not by severity. Not by the adversary model. By the name.
The Ghost User Attack: A Name That Traveled
In 2019, Rösler, Mainka, and Schwenk introduced the term Ghost User Attack in their analysis of group messaging protocols. It described a specific class of vulnerability: a malicious server injects an additional participant into a group conversation without other members’ knowledge or consent. The term was evocative without being sensationalist. It named the adversary (the server operator), the mechanism (invisible participant injection), and the violated property (group membership integrity). Within months, the term surfaced in Matrix issue trackers, Signal community discussions, and IETF MLS working group drafts. Engineers who had never read the paper grasped the attack class from the name alone.
The Ghost User Attack worked as a name because it compressed a technical finding into a phrase that survived transmission through advisory text, press coverage, and developer documentation without losing precision. A CVE entry could reference it. A ProVerif lemma could be checked against it. A product manager could prioritize it. The name did not need to be clever—it needed to be stable and descriptive. It was both.
I have seen the opposite case more times than I care to count. In a 2022 audit of a messaging client (unnamed here because the issue remains partially unpatched), the finding was documented as Issue #7: unexpected behavior in key distribution during group membership changes. Technically accurate. Completely useless. It named neither the protocol component, the adversary capability, nor the security property violated. The issue sat in the tracker for eight months. When a second auditor independently rediscovered the same problem, they filed it as a new issue—the original title did not match any search query a reasonable person would construct. Two issues, one bug, zero progress.
Marketing Names That Obscure Attack Surface
Some names do damage by being too good. WhatsApp’s view-once feature is framed around the recipient’s experience: the message appears once, then vanishes. The cryptographic reality is that view-once is a delivery-time hint stored in the message’s encrypted envelope metadata, processed by the client at display time, and enforced by client-side deletion logic running on a device the sender does not control. The name describes a user-facing promise, not a security property. When researchers documented that view-once messages could be recovered from SQLite forensic images on unencrypted Android devices using standard Cellebrite extraction workflows, the finding was filed under view-once message persistence—a name that inherits the marketing framing and makes the vulnerability sound like an edge case rather than a structural gap between the feature’s promise and its implementation.
The problem is not that view-once is a misleading name for a product feature. The problem is that when the feature’s security properties surface in advisories, CVEs, and documentation, the marketing name carries connotations the underlying cryptography cannot support. A more precise name—client-enforced ephemeral display flag—would make it obvious that the security property depends entirely on endpoint integrity, which is exactly the assumption forensic extraction tools invalidate.
Google’s SRE Book dedicates an entire chapter to Postmortem Culture: Learning from Failure, and the principle transfers directly: engineering organizations that develop structured conventions for naming and documenting incidents respond to them more systematically than those relying on ad-hoc descriptions. The Google SRE Book’s postmortem and incident-tracking chapters argue that consistent naming is not cosmetic—it is the infrastructure that makes cross-team communication and mitigation timelines possible. Protocol auditors face the same problem at a different layer. When a finding’s name is inconsistent across reports, cross-referencing becomes manual, mitigation tracking fragments, and duplicate discoveries multiply.
The Megolm Case: Precision That Accelerated Response
The Megolm state machine confusion finding deserves close examination because it demonstrates how precise naming creates a direct path from discovery to mitigation. The researchers identified that Matrix’s Megolm protocol—which handles group message encryption—contained a state machine in which a malicious homeserver could trick a client into accepting ratchet states from an unintended sender by confusing the client’s tracking of which session a message belonged to. The finding was documented as Megolm state machine confusion in both the paper and the Matrix issue tracker.
The name did four things at once. First, it identified the protocol component (Megolm), telling developers exactly where in the codebase to look. Second, it identified the bug class (state machine), telling security engineers what kind of analysis to perform. Third, it identified the failure mode (confusion), distinguishing it from other Megolm issues like key compromise or ratchet advancement failures. Fourth, it was short enough to use as a search term, a commit message prefix, and a CVE keyword. Matrix’s developers referenced the name in their fix commits. Downstream clients—Element, FluffyChat, Cinny—could search for the term and verify whether their implementations inherited the vulnerability. The naming convention itself became part of the mitigation infrastructure.
When Findings Go Unnamed
The Signal Protocol’s double-ratchet session restoration behavior is a case study in what happens when findings lack stable names. Between 2018 and 2022, multiple audit reports and academic analyses identified variations of a problem where a client restoring from backup or reconnecting after a long disconnection could emit stale ratchet states—causing messages to land in the wrong session or silently drop. Each report described the behavior differently. One paper called it asynchronous ratchet desynchronization. Another called it stale session state propagation. A bug report in a downstream client called it messages disappear after device restore.
None of these names were wrong. All of them were different. Without a canonical term, searching for prior work meant reading every paper and every issue tracker in full. Mitigation discussions happened in parallel across three or four communities without cross-referencing. A fix developed for one downstream client was never ported to others because the developers did not realize they shared the same problem. The absence of a name did not cause the vulnerability—protocol complexity did that—but the absence of a name extended the mitigation timeline by what I estimate at 18 to 24 months. That is a measurable cost, measured in exposed conversations.
NIST’s Cybersecurity Framework tackles this problem at the infrastructure level through standardized vocabulary that translates technical findings into actionable organizational responses. The NIST CSF 2.0 framework mappings demonstrate how naming conventions—mapping checklist settings to vulnerability identifiers and control outcomes—enable both automated remediation workflows and human-readable communication across teams. The protocol auditor’s precision-audience tension mirrors the CSF’s challenge: the same technical finding must be reframed for CVE databases, developer documentation, and end-user advisories without losing its core meaning.
A Practical Naming Workflow for Protocol Findings
After several years auditing messaging protocols and watching findings both succeed and fail in their journey from bug tracker to mitigation, I have settled on a four-part naming convention that I now apply to every protocol-level finding I document. The structure: affected primitive, adversary capability, security property violated, and verification method.
Affected primitive names the specific cryptographic component. Not Signal—that is a protocol, not a primitive. X3DH pre-key pool is a primitive. Megolm ratchet state is a primitive. MTProto 2.0 server-client authentication is a primitive. The name should be specific enough that a developer can grep for it in source code.
Adversary capability describes what the attacker must be able to do to exploit the finding. Malicious homeserver with full message access is a capability. Network observer with timing analysis is a capability. Physical device access with forensic tools is a capability. This field prevents the finding from being over- or under-scoped during triage.
Security property violated names the guarantee that breaks. Group membership integrity is a property. Forward secrecy of messages sent before compromise is a property. Sender authentication is a property. This is the field that prevents marketing names from creeping in, because security properties have formal definitions and marketing promises do not.
Verification method describes how someone can independently confirm the finding. ProVerif model with attacker query Q is a verification method. JADX decompilation of APK class X revealing call to Y is a verification method. Cellebrite UFED extraction of SQLite database Z showing table W is a verification method. This field separates a finding from an assertion. If the verification method cannot be specified, the finding is not ready to leave the audit notebook.
The resulting name is a composite: X3DH Pre-Key Pool Exhaustion by Malicious Server Violating Conversation Availability, Verifiable via Pre-Key Count Inspection at Server Interface. Not elegant. Precise, searchable, and self-documenting. A CVE entry can abbreviate it. A commit message can reference it. A downstream auditor can verify it. That is what a protocol finding name needs to do.
The Editorial Parallel
There is a direct parallel between this naming problem and the editorial process of titling technical documentation. A protocol finding’s name must be precise enough to match the specific technical query a developer types into a search bar, yet readable enough to travel through advisory text, press coverage, and downstream documentation without collapsing into jargon. Protocol auditors face the same tension when their findings leave the bug tracker and enter CVE databases and developer docs. The name is the finding’s first—and often only—chance to be understood by someone who did not read the full paper.
The core challenge is audience calibration. An editor titling an article for security engineers must select terms that resonate with that readership’s vocabulary—not the marketing department’s, not the general press’s, and not the auditor’s private shorthand. The same principle governs protocol documentation: a finding name calibrated to the audience that must act on it—maintainers, downstream implementers, and triaging security engineers—travels further and drives faster mitigation than a name calibrated to anyone else. I have started treating finding names the way an editor treats draft titles: as artifacts that must be tested against their intended audience before publication. I write the name, then show it to a developer who works on the affected protocol but has not seen the finding. If they can tell me what component is affected and what property is violated from the name alone, the name passes. If they ask follow-up questions, the name needs revision.
The audience-calibration problem is not unique to protocol auditing—editorial teams face it whenever they title content for a specialized technical readership. Tools like the Unsloppy AI title generator address the same structural problem at the editorial layer: matching a title’s precision and framing to the audience that will actually use it. The principle transfers directly to protocol documentation. A vulnerability name is, at its core, a title for a technical finding—and like any title, it should be evaluated against whether the intended audience can parse it, search for it, and act on it without needing the full body text to explain what it means.
What Gets Lost Without a Name
The cost of unnamed findings is not theoretical. I have tracked a class of vulnerabilities in multi-device synchronization protocols—across Signal, WhatsApp, and Matrix—where a compromised secondary device emits ratchet states that desynchronize the primary device’s session state, causing silent message loss or delivery to unintended sessions. The underlying mechanism is similar across all three protocols because they all face the same architectural tension: multi-device support requires synchronizing cryptographic state across devices that may have different compromise profiles, and that synchronization introduces a new key compromise surface that single-device protocols do not have.
Each protocol’s implementation of this vulnerability has been documented separately, under different names, in different trackers, at different times. Signal’s version was discussed in a now-archived GitHub issue titled multi-device message ordering after primary device restore. WhatsApp’s version was described in a 2023 paper as linked device session desynchronization. Matrix’s version was filed as device key mismatch after cross-signing reset. Three names for variations of the same structural problem. If a single canonical name existed—something like multi-device ratchet state desynchronization via compromised secondary device—then cross-protocol mitigation patterns could be shared, and a fix validated in one protocol could inform fixes in others. Instead, each protocol’s community discovered, named, and mitigated the problem independently, duplicating analysis effort and extending exposure timelines.
Conclusion
The naming of protocol findings is an engineering problem, not a stylistic one. A good name is a search key, a cross-reference, a mitigation tracker, and a communication tool. A bad name—or no name—is a finding that will be rediscovered, re-reported, and re-mitigated by people who do not know they are repeating work already done. The four-part convention I described—affected primitive, adversary capability, security property violated, verification method—is not the only possible framework, but it satisfies the constraints that matter: specific enough for a CVE entry, structured enough for a ProVerif lemma, readable enough for a developer who did not write the audit to understand what is broken and how to check.
If you audit protocols, name your findings before you publish them. If you maintain a protocol, demand names you can grep for in your codebase. If you write advisories, refuse titles that describe user experience instead of security properties. The difference between a finding that gets fixed and a finding that gets forgotten is often five words and a decision about which five words they are.