A privacy label is a disclosure to investigate, not a measurement of everything an app knows.
There is no defensible universal winner for “the messaging app that collects the least data” without defining what counts: registration identifiers, address-book data, retained connection records, advertising use, or message content. A privacy label is a useful starting point, not a measurement of everything an app processes.
This guide explains how to compare disclosures. It is not a completed independent audit of every messenger, and it does not award a lowest-data badge to Livara or any competitor.
Read the label before counting its categories
Apple’s App Privacy section and Google Play’s Data safety section are based on developer declarations, but their definitions differ. Apple’s guidance distinguishes data linked to a user, tracking, and collection purposes. Processing that remains on the device is not treated as collection, and some transient processing and optional disclosures have specific exceptions.
Google’s guidance also has exceptions: qualifying end-to-end encrypted data unreadable by intermediaries is outside its collected-data disclosure, and some service-provider transfers do not count as sharing. “Encrypted in transit” in a store listing is not a promise of end-to-end encryption. A blank category therefore does not prove that no network request or service-provider relationship exists.
Do not compare the number of Apple boxes against the number of Google boxes and declare a winner. Compare the same store, date, region, and feature assumptions.
A five-layer privacy comparison
| Evidence | Useful question | What it cannot establish alone |
|---|---|---|
| Store label | Which data types and uses are declared? | Complete accuracy or actual retention |
| Privacy policy | Who receives data, for what purpose, and for how long? | Whether implementation matches the policy |
| Device permissions | Can the app access contacts, location, microphone or photos? | What happened to data already uploaded |
| Protocol documentation | Which surfaces and keys protect content? | Protection of every device or software build |
| Independent assessment | Which version and components were tested, and what was fixed? | Permanent security of future releases |
These layers answer different questions. An open-source client is inspectable; that fact does not itself reveal live server retention. An audit may cover cryptography without examining analytics. Read the scope before using either as a privacy score.
Use this comparison worksheet
For each app you are considering, record the following privately. A short, dated record is more useful than an unsupported ranking.
| Field | What to write down |
|---|---|
| Product and platform | Exact app, store link, operating system and version |
| Observation date | When the label and policy were checked |
| Registration | Required and optional phone, email or payment identifiers |
| Discovery | Address book, username, QR code, invite link or account ID |
| Technical records | Declared IP, device, diagnostic and usage data |
| Retention | Stated duration, deletion conditions, or “not specified” |
| Feature exceptions | Backups, bots, business interactions, payments, public channels and calls |
| Evidence gap | What the documents do not answer |
If a policy only says data is retained “as necessary,” mark the exact duration unknown rather than inventing one. If a label changes after an update, keep the earlier date with your notes so the comparison remains interpretable.
Phone-number-free is one dimension, not the whole result
Session and SimpleX offer ways to connect without a phone-number-based identity. Threema makes phone or email linking optional. Livara’s public documentation describes registration without a phone number or email, but also describes routing and membership metadata. These architectures should not be treated as interchangeable.
Signal now documents an optional phone-numberless registration path in its Android beta. That does not mean every Signal version or existing account is numberless. A username on a number-based account and creating an account without a number are different features.
Even without a number, a reused profile photo, payment account, shared file, IP address, or conversation context may link an account to a person. “No phone required” is not evidence of complete anonymity. For the separate issue of routing information, see messaging metadata explained.
How to test contact access without exposing your address book
- Install the official app and decline contact permission initially.
- Add one consenting test contact using a supported identifier, invite or QR code.
- Confirm whether ordinary messaging works without address-book access.
- Inspect the app’s contact-sync setting as well as the operating-system permission. They are not always the same control.
- If contacts were previously synced, look for a separate deletion option or documented request process. Revoking permission limits future device access; it does not necessarily remove the server copy.
Do not upload an address book merely to see whether the app uploads it. A permission prompt reveals requested access, not a complete data-flow audit. A network inspection may reveal destinations and timing, but encryption can prevent you from understanding the transmitted fields.
What E2EE leaves out of the comparison
End-to-end encryption protects eligible content between participating endpoints. It does not automatically remove account identifiers, connection times, group membership records or push-token data. Nor does it protect a copy deliberately sent to a bot, business tool or support service outside that encrypted conversation.
For Livara specifically, the security documentation distinguishes encrypted direct messages and compatible private groups from server-readable public channels. Its hybrid key agreement is a content-protection claim, not evidence that it collects less metadata than every other messenger. This article has not independently measured its server behavior.
Choose the minimum data needed for your use
Start with the information you most need to withhold. If that is a phone number, test numberless registration. If it is the address book, verify manual discovery. If it is readable chat history in cloud storage, investigate the backup separately. If it is connection metadata, read the routing and retention design rather than the cipher list.
A useful final question is: What does this service learn when I use the exact features I need, and which of those disclosures can I avoid? That produces a more honest decision than a single “least data” trophy.
