A Phone Can Ring Without Opening Its Message Archive

A phone rings while the conversation archive is locked. That familiar event exposes a design question: what must the application know to receive the call, and what must remain unavailable until its user unlocks the archive?

Suppose a user has entered an application passcode, later locked the app and then received an incoming call. A reviewer should not infer the state of the stored messages from the ringing screen. Nor should a successful call be presented as proof that the archive was decrypted. These are different operations that need separate evidence.

Enough access to ring is not access to everything

The UseCrypt Messenger explanation of local-data protection describes a minimal operating dataset in the system key store, including an authentication token for the call server. Its stated purpose is to support calls without relying on the full conversation archive. The explanation develops a product document supplied in March 2025; it is not a new observation of today’s application build.

The engineering idea is useful: assign the call-handling function the information it needs rather than treating an unlocked archive as a prerequisite for every operation. The remaining questions concern the actual token. Which requests does it authorise? How long does it remain valid? What happens after revocation? A statement about minimal data is the beginning of that review, not its result.

For example, a test could revoke a controlled account’s signalling credential and then observe whether new incoming requests are rejected. A different test could inspect which account information appears before archive access is granted. These are proposed procedures using synthetic accounts, not findings about a deployed service.

The call has more than one protection boundary

Establishing that a device may receive a call does not determine how the media session obtains its cryptographic keys. RFC 6189, the Informational ZRTP specification, describes media-path key agreement for SRTP. It is relevant protocol reading, not a certification of an application or a complete description of its storage system.

AVLab’s report published on 17 November 2020 identifies ZRTP when discussing an assessment of Messenger for iOS version 2.34. That is the historical connection. It does not establish the protocol used by every later platform release, and it does not specify what a call-server token can authorise.

The separation can be stated without claiming a serverless system. Infrastructure may perform delivery and signalling functions. Whether that infrastructure can recover conversation content depends on key distribution and protocol behaviour. The existence of a server does not settle that question in either direction.

Locking is a state transition worth measuring

“Locked” needs an operational definition. Is the application showing its passcode screen, running in the background, subject to the phone’s screen lock, or no longer running? Record the transitions instead of assuming that the same word means the same thing to the user, the application and the operating system.

A practical test matrix can separate three outcomes: whether the incoming request reaches the device, whether a call can be accepted and whether the stored message history can be read. Test each outcome before unlocking, after unlocking and after terminating the process. Add a known working call as a control, so a network failure cannot be mistaken for successful access restriction.

Record displayed caller information separately from the conversation content. A system that protects an archive may still reveal a name or timing information through its call interface. Conversely, suppressing a name on screen does not prove that no delivery metadata exists elsewhere. The report should name each observed disclosure rather than merge them into one privacy score.

What a clear explanation gives the user

The useful promise is not that calls happen without any supporting infrastructure. It is that supporting one function need not grant unrestricted access to another. Proving that promise requires the application’s state, credentials and stored data to be examined together.

UseCrypt’s security-review register separates historical assessments from technical descriptions. Keeping that distinction visible helps a reader move from a product presentation to the evidence that can actually answer a particular question. A ringing phone demonstrates availability. Protection of the archive needs its own test.