The Next Wave of Encrypted Messengers
Encrypted messengers are experiencing a resurgence. While applications like WhatsApp, iMessage, and Signal have established end-to-end encryption (E2EE) as a standard expectation, most still rely on phone numbers, centralized servers, and collect significant metadata. This metadata can include details about who you communicate with, when, from which IP address, and on which device.
Vitalik Buterin has highlighted the need for advancements in secure messaging, particularly focusing on permissionless account creation that does not require phone numbers or Know Your Customer (KYC) verification. He also emphasized the importance of stronger metadata privacy. In support of this direction, he recently posted on X and donated 128 Ether (ETH) to projects like Session and SimpleX.
Session serves as a compelling example of an application aiming to merge E2EE with decentralization. It operates without a central message server, routes traffic through onion paths, and uses user IDs based on cryptographic keys rather than phone numbers.
Did you know? Forty-three percent of individuals who utilize public Wi-Fi have reported experiencing a data breach. Among the common causes are man-in-the-middle attacks and the sniffing of unencrypted traffic.
Understanding Session's Message Storage
Session is designed around public key identities. Upon registration, the application generates a local key pair, from which a Session ID is derived without the need for a phone number or email address.
Messages are transmitted through a network of service nodes utilizing onion routing, ensuring that no single node has visibility of both the sender and the recipient. The specific node path for a message can be viewed within the application's settings. For asynchronous delivery when a user is offline, messages are temporarily stored in small groups of nodes known as "swarms." Each Session ID is linked to a particular swarm, and messages are stored there in an encrypted state until the user's client retrieves them.
Historically, messages had a default time-to-live of approximately two weeks within the swarm. After this period, the network copy would be deleted, leaving only the messages stored locally on the user's devices.
Session maintains a local database of chats and attachments, allowing users to access conversation history spanning months or even years. This local storage contributes to the application's size, which can grow as media is sent, thumbnails are cached, and chat history is preserved. Public documentation and independent reviews have noted this distinction between short-lived network storage and persistent local storage.
Users can manage storage by deleting chats, utilizing disappearing messages, or clearing media. Any content still visible within the application is stored locally on the device.
The Trade-offs of Fast Mode Notifications
Notifications represent a clear area where privacy and user experience (UX) involve a trade-off. On iOS, Session offers two distinct modes:
- •Slow Mode: This mode employs background polling. The application periodically wakes up to check for new messages via its own network. While more private, this method can lead to delays or unreliability, particularly if the operating system is aggressive in managing background activities.
- •Fast Mode: This mode utilizes push notifications. Session leverages Apple Push Notification Service on iOS and a comparable system on Android to ensure timely alerts.
The use of Fast Mode introduces certain privacy considerations. According to Session's support documentation, enabling Fast Mode means:
- •The device's IP address and push token are exposed to an Apple-operated push server.
- •The Session Account ID and push token are shared with a Session-run push server, enabling it to direct notifications appropriately.
It is important to note that:
- •The servers do not access message contents, as these remain end-to-end encrypted.
- •Session states that Apple and Google do not see who you are communicating with or the precise timing of messages beyond the general logging inherent in their push infrastructure.
For users concerned about these aspects, Slow Mode remains an option, though it may result in missed or delayed notifications. This choice highlights the new considerations that decentralized messengers require users to contemplate.
Jurisdiction, Transparency, and Government Requests
Session's governance structure has also undergone changes. Initially managed by the Australian nonprofit Oxen Privacy Tech Foundation (OPTF), stewardship of the project transitioned in late 2024 to the Session Technology Foundation (STF), a new entity based in Switzerland. OPTF's final transparency report covered the fourth quarter of 2024, with subsequent requests being handled and published by STF.
Session's support documentation regarding information requests outlines the following:
- •Due to Session's decentralized nature and E2EE, the foundation does not possess special access to user messages or keys.
- •The STF publishes retrospective transparency reports that summarize law enforcement requests and the foundation's responses.
The transparency page serves as the primary reference for users interested in governmental requests for information. It documents instances where authorities have reached out, the nature of their requests, and Session's actions in response.
The types of information that can realistically be handed over include:
- •Potential: Logs from websites, file servers, or infrastructure directly operated by the foundation, such as push relays or STUN/TURN servers for calls, subject to Swiss law and any applicable international requests.
- •Not: Decrypted messages or master keys to user chats, provided the implementation aligns with the protocol's specifications.
Switzerland's foundation framework is characterized by a relatively light touch regarding transparency when compared to certain other jurisdictions. This makes voluntary reporting and technical limitations on data handling particularly significant.
In essence, while decentralization does not prevent governments from making requests, it significantly limits the scope of what information can be provided.
Did you know? When law enforcement infiltrated the EncroChat encrypted phone network, they intercepted over 115 million criminal messages from approximately 60,000 users. This operation led to more than 6,500 arrests and the seizure of nearly 900 million euros in assets globally.
Quantum Resistance, Calls, and Ongoing Development
A significant concern in secure communication is the "harvest now, decrypt later" threat, where adversaries record encrypted traffic today with the intention of decrypting it using future quantum computers capable of breaking current public key cryptography schemes.
Session's response to this threat involves a substantial protocol redesign. In a recent blog post, the development team introduced Session Protocol v2, which aims to incorporate:
- •Perfect Forward Secrecy: Achieved through the use of ephemeral keys.
- •Post-Quantum Key Exchange: Utilizing ML-KEM (formerly CRYSTALS-Kyber), a NIST-standardized Key Encapsulation Mechanism that is also being adopted by Signal's PQXDH and Apple's PQ3.
Currently, Session is not strictly quantum-resistant. It still relies on classical elliptic curve cryptography while v2 is under development. The roadmap indicates a move towards hybrid post-quantum schemes, but until these are implemented, audited, and widely deployed across all clients, users should assume standard end-to-end encryption security with an anticipated upgrade path.
Voice and video calls are another area of ongoing development. According to Session:
- •Voice and video calls are available but are considered a beta feature that requires user opt-in.
- •These calls currently use peer-to-peer WebRTC, which exposes the user's IP address to the other party and to a Session-run STUN or TURN server for signaling and media relay.
- •Onion-routed calls over Lokinet are planned to enhance IP privacy more comprehensively but are not yet the default option.
Session's own blog and FAQ explicitly caution that individuals in highly sensitive situations may wish to refrain from enabling calls at this time.
The extended beta period for calls partly reflects the inherent difficulty in combining low-latency communication, onion routing, and robust anonymity guarantees.
The Practical Impact of Decentralization
Session exemplifies both the potential benefits and the inherent limitations of decentralized secure messaging.
On the positive side:
- •Account creation is possible without a phone number or email address, aligning with the concept of permissionless account creation.
- •Messages are routed through a multi-node, onion-routed network, minimizing the amount of metadata accessible to any single operator or subject to logging.
- •The relocation of stewardship to Switzerland and the commitment to open-source clients and transparency reports can foster greater public scrutiny of changes to the codebase and infrastructure.
However, decentralization does not confer complete invisibility:
- •Local storage on a device remains a significant risk if the device is compromised or seized.
- •Fast Mode notifications and WebRTC calls can leak IP-level metadata to infrastructure providers, even if they do not access message content.
- •Post-quantum protection is still a future development, pending the release and maturation of Protocol v2.
For users considering Session, it is advisable to default to Slow Mode if metadata privacy is a higher priority than instantaneous notifications. Employing disappearing messages and regularly pruning old chats and media can further reduce data stored on devices. Similar caution is advised for calls. If linking a Session ID to an IP address is a concern, it may be prudent to disable voice and video features until the calling infrastructure is more robust.
More broadly, end-to-end encryption alone is no longer sufficient. As governmental pressure on messaging platforms increases and quantum threats evolve from theoretical possibilities to tangible roadmaps, decentralization, metadata minimization, and post-quantum upgrades are becoming essential components of secure messaging. Session is one of several projects striving to address these challenges, each presenting its own unique set of trade-offs, strengths, and limitations.