From encrypted conversations to decentralized messaging
Encrypted messaging apps are experiencing a resurgence.
Platforms like WhatsApp, iMessage, and Signal have set end-to-end encryption (E2EE) as a standard expectation. However, many still rely on phone numbers, centralized servers, and substantial metadata, including details about your contacts, timestamps, IP addresses, and devices used.
Vitalik Buterin has recently addressed this topic in his X post and donation. He proposes that the future of secure messaging should include permissionless account creation without the need for phone numbers or Know Your Customer (KYC) processes, and enhanced privacy for metadata. In this context, he pointed out Session and SimpleX, donating 128 Ether (ETH) to each to encourage further development.
Session serves as an illustrative example, attempting to meld E2E encryption with decentralization. It operates without a central message server, routing traffic via onion paths, and uses user IDs as keys instead of phone numbers.
Did you know? Forty-three percent of individuals utilizing public WiFi report having experienced a data breach, often due to man-in-the-middle attacks and packet sniffing targeting unencrypted traffic.
How Session manages your messages
Session operates using public key identities. Upon signing up, the app generates a keypair locally and creates a Session ID based on it, eliminating the need for a phone number or email.
Messages are transmitted through a network of service nodes via onion routing, preventing any single node from accessing both sender and recipient information. (You can view the message node path in the settings.) For times when you’re offline, messages are stored in small clusters of nodes labeled “swarms.” Each Session ID connects to a specific swarm, where your messages remain encrypted until your client retrieves them.
Traditionally, messages had a default expiration of roughly two weeks within the swarm. After that, the network copy is deleted, leaving only what’s stored on your devices.
Indeed, Session maintains a local database of your messages and attachments, which allows you to review history spanning months or years. That’s why the app installation might be around 60 to 80 MB, but the size increases as you send media, cache thumbnails, and retain chat history. Public documentation and independent evaluations have highlighted this dichotomy between temporary network storage and enduring local storage.
You can manage storage by deleting chats, utilizing disappearing messages, or clearing media. If you can still access it, it resides somewhere on your device.
Fast Mode notifications
Notifications reveal the privacy and user experience (UX) trade-off clearly.
On iOS, Session provides two modes:
Slow Mode involves background polling. The app periodically checks for new messages over its own network. This offers more privacy but can lead to delays or unreliability, particularly if your OS aggressively limits background activity.
Fast Mode employs push notifications. Session utilizes Apple Push Notification Service on iOS and a similar method on Android for timely alerts.
The contentious aspect is Fast Mode. According to Session’s own support documentation, using it means:
Your device IP address and push token are visible to an Apple-operated push server.
Your Session Account ID and push token are shared with a Session-managed push server, enabling it to send notifications accordingly.
Importantly:
The servers cannot access message contents as they remain E2EE.
Session states that Apple and Google also do not know your contacts or the exact timing of messages beyond what their generic push infrastructure log.
If this is concerning, Slow Mode offers an alternative, though it may lead to missed or delayed notifications. This choice is part of the new considerations decentralized messengers impose on users.
Jurisdiction, transparency, and government requests
Session’s governance has evolved.
Initially governed by the Australian nonprofit Oxen Privacy Tech Foundation (OPTF), a new Swiss entity, the Session Technology Foundation (STF), has since taken over the project’s governance. OPTF’s last transparency report encompasses Q4 2024; subsequent inquiries will be managed and published by STF.
Session’s support documentation regarding information requests states:
Given that Session is decentralized and E2EE, the foundation cannot access user messages or keys.
The STF publishes retrospective transparency reports summarizing law enforcement requests and their handling.
This transparency page is likely the reference users consider when discussing a source that details governmental information requests. It documents the inquiries made by authorities and how Session responds.
What can they feasibly provide?
Potentially: Records from websites, file servers, or infrastructure directly operated by them, such as push relays or STUN and TURN servers for calls, subject to Swiss regulations and any relevant international requests.
Not: Decrypted messages or master keys for user chats, provided the implementation adheres to the protocol description.
Switzerland’s foundation regime offers comparatively loose transparency compared to several other jurisdictions, making voluntary reports and technological data limits especially crucial.
In essence, decentralization does not prevent governments from making requests, but it does limit what can be disclosed.
Did you know? When law enforcement infiltrated the EncroChat encrypted phone network, they intercepted over 115 million criminal messages from approximately 60,000 users, resulting in over 6,500 arrests and nearly €900 million in seized assets globally.
Quantum resistance, calls, and “beta forever?”
The concern is that adversaries can harvest data now and decrypt it later. They can record encrypted traffic today and wait for future quantum technology to compromise existing public key systems.
Session addresses this with a significant protocol overhaul. In a recent blog post, the team introduced Session Protocol v2, which seeks to incorporate:
Perfect forward secrecy with temporary keys
Post-quantum key exchange utilizing ML-KEM (formerly CRYSTALS-Kyber), the NIST-standard key encapsulation method also featured in Signal’s PQXDH and Apple’s PQ3.
So, is Session currently quantum resistant?
Not entirely. It still depends on classical elliptic curve cryptography while v2 is still in development. The roadmap indicates plans for hybrid post-quantum solutions, but until these are implemented, verified, and deployed across all clients, one should expect standard end-to-end encryption security with plans for future upgrades.
Calls present another ongoing issue. According to Session:
Voice and video calls are available but remain beta features that you must opt into.
They currently use peer-to-peer WebRTC, which exposes your IP address to the other party and to a Session-operated STUN or TURN server for signaling and media relay.
Plans are underway for onion-routed calls over Lokinet to better conceal IP addresses, but this is not yet the default.
Session’s blog and FAQ explicitly caution that individuals in highly sensitive contexts may wish to refrain from enabling calls for the time being.
Thus, the extended beta period reflects the challenges in merging low-latency calls, onion routing, and robust anonymity assurances.
What decentralization truly changes for you
Session exemplifies both the potential and the limitations of decentralized secure messaging.
On the positive side:
You can establish an account without needing a phone number, email, or any form of ID, which aligns with Buterin’s vision of permissionless account creation.
Your messages navigate through an onion-routed multi-node network, which diminishes the amount of metadata visible to any single operator or potentially subject to logging.
The governance shift to Switzerland, along with the use of open-source clients and transparency reports, may bolster public oversight regarding modifications to the codebase or infrastructure.
Conversely, decentralization is not an invisibility cloak:
Local storage on your device poses a significant risk if your device is seized or compromised.
Fast Mode notifications and WebRTC calls leak IP-level metadata to infrastructure providers, even without exposing your plaintext messages.
Post-quantum security remains on a roadmap until Protocol v2 is finalized and fully integrated.
If you’re considering using Session, it’s advisable to adopt Slow Mode as your default should metadata privacy be a priority over immediate notifications. Opt for disappearing messages and periodically prune old chats and media to limit what’s stored on your devices. The same caution applies to calls. If the association of a Session ID with an IP address raises concerns, it might be safer to keep voice and video functionalities disabled until the calling stack is more robust.
More generally, E2EE alone is no longer sufficient. As government scrutiny on messaging platforms increases and quantum threats transition from theoretical to practical, decentralization, metadata minimization, and post-quantum enhancements are increasingly integral to what secure messaging entails. Session stands as one of many projects tackling these challenges, each presenting its own trade-offs, advantages, and limitations.
