Guides
Part of How messaging platforms lock you in, and how to move
How to check messaging platforms facts in three sets
Messaging platforms facts in three sets: what two accounts can test, what only a policy or transparency report shows, and what nobody outside can settle.
Almost everything published as a fact about a messaging service—WhatsApp, Signal, Telegram, iMessage, Facebook Messenger—is a fact about its marketing. The interesting properties of a messenger are not in its feature list, and they are not hard to establish. They are things you can test in an afternoon with two accounts and a spare device.
This page is about messaging platforms facts: which questions have checkable answers, what the test for each one looks like, and which questions cannot be settled from outside no matter how long you look.
What to take away
- A handful of the properties that matter can be tested directly by you, and testing beats reading.
- A second set can only be read, never tested, so the wording of the document is the whole of the evidence.
- A third set is unknowable from outside, and the honest record says so rather than guessing.
Set one: things you can test yourself
You need two accounts you control and, for a few of these, a second device. Every test below produces an observation with a date on it, which is worth more than any published claim.
Tests you can run yourself
- Find you by phone number, then name
- Delete a message, check other device
- Restore backup to fresh install
- Second account adds you to group
- Forward a message, inspect what travels
- Request your data, open the file
- Send offline, reconnect, watch the queue
| Question | The test | What the answer tells you |
|---|---|---|
| What am I reachable at? | Have a stranger try to find you using only your phone number, then only your display name | Whether your reachability is tied to a telecoms account you may lose |
| What does deleting do? | Send a message, delete it, then look at the other device and at any backup | Whether deletion is a removal or a request to the other end |
| Where does the backup go? | Turn on backup, then restore to a fresh install and see what comes back | Whether a sealed conversation is sealed at rest |
| Who can add me to a group? | Get a second account to add you without asking | Whether group membership is an invitation or an imposition |
| What does a forward look like? | Forward a message and inspect what travels with it | Whether attribution and context survive being passed on |
| What does the export contain? | Request your data and open the file | Whether you have an archive or a screenshot of one |
| What happens offline? | Turn off the network, send, then reconnect | Where messages queue, and for how long |
| Does the other person know I read it? | Send with receipts on and off, from both sides | Which social signals are on by default and who controls them |
Run these on the account you actually use, not a clean test account. Defaults sometimes depend on account age and region. Write down the date.
The tests land on settings and tools that have names: disappearing messages in WhatsApp, Signal and Telegram; last-seen and read-receipt toggles; the control over who can add you to a group; and each service's own data-request tool — Request account info in WhatsApp, Download your information in Meta Accounts Center for Messenger, Get a copy of your data at Apple's privacy site for iMessage, and Export Telegram data. Write down the menu you found each one in, because menus move.
A behavior you tested is the strongest evidence in a platform record. Record-keeping conventions are built to preserve that kind of evidence, as the notes on keeping a platform record set out.
Set two: things you can only read
Some properties leave no trace you can observe. For these the document is the evidence, and the exact wording is the finding.
Retention. How long the operator keeps a message, a delivery record, or an account after deletion is invisible from the client. It is stated, if at all, in a policy document, and the useful reading is the qualifiers rather than the period: what is excluded, what is kept for a different purpose, and what survives account deletion.
What is handed over on request. Operators publish, in varying detail, what categories of information they can produce when compelled. This is the single most informative document a privacy-minded reader can find, because it describes what actually exists rather than what the marketing implies.
Whether content is scanned before it is sealed. Sealing rests on public-key cryptography and protects a message in transit. Whether anything happens on the device before that point is a design decision, described in documentation or not described at all.
What the operator does with the address book you uploaded. This one is worth reading closely, because you consented on behalf of people who did not.
Three defaults are worth stating plainly, because each one is documented and each one changes what the tests show: WhatsApp and Signal encrypt messages end to end by default, iMessage does too but its iCloud backup does not unless Advanced Data Protection is switched on, and Telegram's cloud chats are stored on Telegram's servers, with end-to-end protection reserved for secret chats.
The documents behind those statements have names. Signal publishes a transparency report and a privacy policy describing how little it retains. Meta publishes law enforcement guidelines covering WhatsApp and Messenger, alongside its reports on government requests. Apple publishes Legal Process Guidelines and government-request reports that cover iMessage. Telegram publishes a privacy policy and the protocol documentation behind its secret chats.
In the United States, compelled handover runs through a warrant or a court order under the Stored Communications Act, 18 U.S.C. § 2703, and requests for data held abroad through the CLOUD Act or a mutual legal assistance treaty. Those are the instruments the guidelines above are describing, which is why the category of data matters more than the wording of the request, and why you copy the retention passage rather than summarize it.
A message you send is handled by several machines before it reaches anyone, and which of those machines belongs to whom is a design fact you can read about but never watch. Mail is the clearest published example of the shape. Signal's open-source repositories and Telegram's protocol documentation describe the same routing question for their own services; WhatsApp's architecture mirrors Signal's protocol layer but adds Meta-operated servers.
Copy the passage into your notes rather than summarizing it. A summary loses the qualifier, and the qualifier is usually the point.
Set three: things nobody outside can establish
Be plain about the limit. From outside an operator, you cannot verify:
What outsiders cannot verify
- Server runs the software described
- Stated retention matches actual systems
- How many accounts exist
- What proportion of accounts are automated
- Forward secrecy held on a past date
Independent audits, published source code, and reproducible builds narrow some of these. None of them closes the gap entirely, and a page that presents any of these as a settled fact is overstating what it knows.
Signal publishes reproducible builds of its Android app, so anyone can compare the published source with the shipped binary. That is stronger evidence than a policy sentence, and it is still a statement about one build on one date.
Why the popular claims are the least checkable ones
The statements that circulate most about messengers are almost exactly the statements in set three. Which service is biggest, which is safest, which is used by whom. They travel because they are simple, and they are simple because they have dropped every qualifier that would make them testable.
Properties that change your choice, like what your backup does and who can add you to a group, take minutes to check and rarely get discussed. That inversion is the most useful fact about the category's public information: attention is inversely related to verifiability.
The general structure under the tests is in the messaging platforms overview.
A record worth keeping
For each service you use, one short page, updated when something changes.
Your one-page record
- Identifier you are reachable at
- Default state of each setting
- Date of last export test
- Policy passage on retention, verbatim
- Unestablished items as open questions
As a worked example, a filled page for iMessage reads roughly like this: reachable at a phone number or an Apple Account address — tested; no disappearing-messages setting; backups go to iCloud, and whether Apple can read them turns on Advanced Data Protection, a switch you can look at; content scanning before sending — none described; what Apple produces on legal process — set out in its Legal Process Guidelines; number of accounts — unknown, and it stays unknown.
The last line is the one people skip. An unanswered question in the file is a finding; an empty space is an invitation for someone to assume the comfortable answer.
Run the same short page for whatever you are considering moving to, before you move.
Comparing two filled-in records is a real comparison. Comparing your tested experience of one service against a description of another is how people switch to something worse.
That is why choosing a replacement starts with your requirements rather than with candidates.
Common questions
Is a test on my own account representative?
Of your account, yes. Of everyone's, no. Defaults vary by region, account age, device and rollout group, so treat a single result as one observation rather than a general fact. Two accounts on different networks in different places is a large improvement for very little effort.
Which single test gives the most information?
The backup and restore. It reveals what is protected at rest, what the export actually contains, and how much of your history exists in a form somebody else could read. Run it on iMessage, which routes backups through iCloud, and on Signal, which keeps a local encrypted backup. Most people have never run it, and it takes an hour.
Should I trust an independent audit?
It is much better than nothing and narrower than it sounds. An audit covers a defined scope on a defined date. Read the scope statement first: it tells you what was not examined, which is the part that matters for the claim you were about to make.
If nothing is fully verifiable, what is the point of checking?
Because the checkable set is where your real risks are. Losing a conversation because you never tested an export, or being added to a group by a stranger, are ordinary failures with ordinary fixes. The unverifiable questions get the attention while the fixable ones do the damage.
