Finding friends in a messenger and keeping an address book private are not the same problem. An app needs to determine which identifiers belong to service members, but the way it performs this matching determines what information the service receives. Hashing a phone number does not, by itself, guarantee that the number cannot be identified.
Why can a hashed number be identified?
A hash function converts an input into a fixed-length value. However, the space of telephone numbers is limited and structured. An attacker can generate plausible numbers, calculate their hashes and look for matches. This is not “decrypting a hash”; it is testing guessable inputs.
Signal explains precisely this limitation of low-diversity identifiers in its discussion of the private contact discovery problem. The same article introduces a design based on a trusted execution environment. This historical example should not be generalized to every messenger without checking the version and newer documentation.
So “the server only sees hashes” is not a complete answer to the privacy question. It must be clear who can compute matches, which requests are logged and how long the data remains.
What does contacts permission allow?
Permission to read contacts gives an app access to address-book data; it does not itself tell you whether the app uploads that data. A contact's name, number, email address and notes may be sensitive, especially when they contain information about people who are not even members of the service.
The Android Contacts Provider documentation distinguishes between broad address-book access and selecting a contact through the system interface. The scope of access depends on the implementation and operating-system version.
| Contact discovery method | Potential benefit | What needs checking |
|---|---|---|
| Sharing a username or invitation link | May not require reading the entire address book | Whether the identifier is searchable and others can find the account |
| Selecting a few contacts | Less data is made available to the app | Does the app receive only the selected entries? |
| Uploading a list of numbers or hashes | Easier matching against registered users | Number guessing, request logging and retention of the list |
| A dedicated private discovery protocol | Can reduce disclosure within a threat model | Trust assumptions, limitations and evidence of independent review |
What does message encryption not prove about the address book?
End-to-end encryption can hide conversation content from the server, but on its own it says nothing about contacts permission, user-search requests or logging connections. Even without an address book, routing information may reveal some communication relationships.
Livara's security page explains the storage and processing of operational information such as group membership, timing and routing. This document does not establish that the address book is hashed using a particular method, that no history is retained or that the social graph is completely hidden. Those claims require a separate explanation of contact discovery.
Ask these five questions before granting permission
- Can I still chat using a username or direct invitation without contacts permission?
- Exactly which fields leave the device: only the number, or also the name and other details?
- How is information about people who have not joined the service used and deleted?
- Does revoking permission only stop future access, or is there also a way to delete data already sent?
- Do the technical explanation and data-retention policy match the current app version?
Review the app's permission in system settings and restrict unnecessary access if you do not need automatic friend discovery. Option names differ between phones. Do not equate revoking permission with deleting previously uploaded information.
Contact privacy is measured by data minimization and clarity about where the data goes, not merely by placing the word “hash” beside a phone number.
