A good threat model connects a specific risk to a measure you can check—not to the longest list of features.
A messaging threat model means identifying which information matters to you, who might gain access to it, and which measures fit your risks and circumstances. A family, a journalist, and an employee using a company phone do not necessarily face the same threats. This guide offers a simple framework for writing your own plan, not a definitive ranking of messaging apps.
Key takeaways
- A threat model is three or four sentences, not a product. Write down what you want to protect, from whom, and how much effort you are willing to make. Without those sentences, choosing a messenger is just collecting a list of features.
- Your chat has four links in the chain: your device, the network, the messaging server, and the other person's device. These four surfaces are a starting point; examine backups, accounts, and connected services separately, too.
- End-to-end encryption protects content from intermediaries; device security, keys, backups, and the recipient's behavior still matter.
- Assess threats in your own circumstances: physical access, notification previews, phishing, backups, and linked devices are examples to examine, not a statistical ranking.
- Metadata is separate from message text. Who you talked to and when can remain visible even when the text is fully encrypted, and you need to make a separate decision about it.
What is a threat model, and why does it matter when choosing a messenger?
A threat model is a short description of “what you want to protect, from whom, and with how much effort.” Until those three elements are clear, comparing messengers just produces a longer list of features, without ever telling you which ones are useful to you.
The Electronic Frontier Foundation (EFF) makes the same point in its Security Planning (Threat Modeling) guide: trying to protect against every possible threat at every moment leads to frustration, because security is a process, not a purchase. For technical teams, the OWASP Threat Modeling Project provides a similar framework, while the threat model library in the OWASP Developer Guide offers many ready-made examples to draw on.
One practical point: a threat model is not a fixed document. A job change, a business trip, or someone joining the family group can change it completely. Whenever that happens, rewrite those same four sentences.
Who can read my messages? Break the chain into four links
The short answer: every message passes through four links—your device, the network, the messaging server, and your contact's device—and copies or linked accounts can create additional routes of access. So the right question is not “Which messenger is more secure?” but “Which link is weaker in my situation?”
Link one: your own device
Anything visible on your phone's screen has already been decrypted. If your phone is unlocked, notification previews are enabled on the lock screen, or someone knows your four-digit PIN, encrypting the message in transit will not stop them from reading content accessible on that device.
Link two: the network
A network observer may see the connection's destination, timing, and traffic volume; a DNS service does not necessarily see the entire route or every message packet. With end-to-end encryption, what they see is encrypted data rather than text, but the exchange of messages and its volume are usually not hidden.
Link three: the messaging server
The server is where devices synchronize. With end-to-end encryption, the server cannot read the text, but it still sees routing metadata and can retain it. This is where the distinction between “encrypted” and “private” becomes clear.
Link four: the other person's device
The last link is outside your control. Your contact can take a screenshot or forward a message, or their phone may be infected. End-to-end encryption reduces this link to “trusting your contact”—nothing more.
In short, end-to-end encryption limits who can access content, but devices, key management, and authorized recipients remain part of the threat model.
Which threats should you examine in your circumstances?
An unlocked phone, account access, notification previews, and backups are examples worth examining. For someone facing professional targeting, sophisticated malware or physical coercion may also matter; do not downplay the risk without understanding the circumstances.
Backups are a separate route of access. If a messenger stores a backup in the cloud and that copy is not end-to-end encrypted, encryption on the phone only gets you as far as the cloud's edge: you have locked the right door but left the key beside it. The guide to backing up encrypted chats securely helps you examine this route.
A second threat is people nearby: a colleague, a housemate, or someone borrowing your phone “just for a moment.” A third is the login account: if you sign in by email and that email account is poorly protected, the whole chain opens at its weakest link. Stronger encryption does not solve any of these problems.
Protecting chats from hackers: which attacks actually happen?
The short answer: common attacks on chats do not break the mathematics of encryption; they involve phishing, malware, stolen login codes, and attacks on the device itself. In practice, the attacker looks for the key instead of breaking the lock.
That is why login behavior matters as much as key length. Livara uses SRP (a zero-knowledge password proof) for authentication: your device proves knowledge of the password without sending the password itself over the network. In practical terms, recording login traffic does not reveal the password. The limitation must also be explicit: SRP does not stop a fake page into which the user types their password. At that point, the issue is no longer mathematics but the user's vigilance.
The second attack surface is the app itself. A modified APK can bypass any encryption safeguards. Livara publishes the SHA-256 checksum of each release so you can compare the downloaded file with a trusted reference; the Proof Lab does this in your browser. If you want to know what to ask of any other messenger, the checklist of questions to ask before choosing a secure messenger is a good starting point.
What does end-to-end encryption cover, and what does it not?
The short answer: end-to-end encryption locks message content from your device to your contact's device so that the server sees only encrypted data. But the name of this feature tells you nothing conclusive about all metadata, backups, screenshots, or public channels; each requires separate controls.
For a specific product, read the feature coverage table instead of drawing conclusions from an algorithm's name. Livara's security page and its threat model explain chats, channels, calls, metadata, and recovery. These are claims published by the maker, not a substitute for independent testing. In particular, examine call-recording exceptions and the distinction between identity recovery and chat-history recovery separately.
What does metadata reveal even when message text is encrypted?
The short answer: metadata says who talked to whom, when, and how much data they exchanged—and encrypting the text does not make that information disappear.
In Livara, standard routing metadata (sender, destination, delivery time) is retained to keep devices synchronizing seamlessly. This is an explicit limitation, not a detail to overlook. Even without reading the text, the “who talks to whom” graph can be sensitive: a doctor and patient, a lawyer and client, or the two sides of a business negotiation. See what messaging metadata reveals for a fuller explanation.
If your threat model includes “someone who can see my communication patterns,” no end-to-end encrypted messenger can address that part on its own. You also need to think about whom you communicate with and from where.
Write your threat model in five minutes
The short answer: answer four questions—whom do I fear, what do they want, what capabilities do they have, and what would happen if a message were exposed—then choose the least costly effective measure, not the other way around.
- Who is the threat actor? Name them: a colleague, former partner, thief, company, or government.
- What is worth protecting? The conversation text, files, or the communication pattern itself.
- What capabilities do they have? Physical access to the phone? Account access? Extensive resources?
- What would happen if it were exposed? Harm to your reputation, job, physical safety, or simply embarrassment.
- Based on those answers, choose the least costly effective measure.
If your threat is an observer on the same Wi-Fi network, a properly validated TLS connection and authenticated end-to-end encryption matter; for physical access, a device lock addresses a different priority. How to verify a chat using security numbers shows how to do this. And if you want to know who can see what in a particular messenger, Livara's published threat model explains exactly that without slogans.
A short example of a threat model
“The work files on my phone are sensitive. The main risk right now is a colleague accessing my unlocked phone and copies saved in the gallery. This week I will shorten the auto-lock delay, limit notification previews, and check backup folders. Then I will assess the result using a test file.”
This is only an example. If a controlling person has access to your device, sudden settings changes may attract their attention. Use a safe device and help from someone you trust to make a plan, and prioritize your physical safety.
Frequently asked questions
How can I define a “threat model” in one sentence?
It means clarifying what you want to protect, from whom, and with how much effort. That sentence determines which security features are worth the cost and which merely add complexity.
If I have end-to-end encryption, should I still worry about hackers?
Yes, but not in the way you might think: instead of breaking the lock, an attacker goes after the device, phishing opportunities, and login codes. So the right questions are: Is my phone locked? Is my cloud backup encrypted? Is my email account protected?
Are public channels end-to-end encrypted, too?
No. A channel is a public, readable broadcast surface so that reports can be handled and abusive content removed. According to Livara's documentation, direct chats and compatible private groups with E2EE active are end-to-end encrypted; an older, incompatible group may visibly remain outside E2EE. Check the status of the actual conversation. The server also continues to control group membership.
How can I tell whether the Android version I installed has been modified?
Compare the downloaded APK file's hash with the checksum for that same version from a trusted source; the Proof Lab is designed to check files in your browser. A matching hash only establishes equality with the reference. If an attacker replaces both the file and the reference hash, a match is not enough. A modified APK can bypass encryption, so checking app integrity matters as much as encryption itself.
