The Security of the Session Messenger – A Guide

Security-conscious users are increasingly on the lookout for messenger apps that take privacy seriously. You may already have heard of Signal, the well-known secure messenger. But there’s another service that goes one step further when it comes to anonymity and metadata protection: Session. In this article, you’ll learn what makes Session special, how its technical architecture works, and how it differs from Signal. Whether you have little tech experience or you’re an IT pro, this guide will explain Session’s security in a clear and detailed way.
 

1. Introduction to Session

What is Session?
Session is a free, end-to-end encrypted messenger app that’s specifically designed with confidentiality and anonymity in mind. Unlike many common messengers, Session does not require any personal data when you register: no phone number or email address. Instead, your device generates a random, 66-character alphanumeric ID as your Session Account ID.

Who is behind it?
Session is currently stewarded by the Session Technology Foundation (see https://session.foundation), previously managed by the Oxen Privacy Tech Foundation.
 Since 2024, the foundation has been based in Switzerland, aiming to operate outside the jurisdiction of Five/Nine Eyes countries. The developers wanted a messenger built on the reliable foundation of Signal, but without the weaknesses that come from centralization. In fact, Session originally started as a fork of the Signal messenger. Much of Signal’s robust encryption framework was adopted, but Session pursues additional goals: greater anonymity and decentralization. This developer team—supported by the Loki/Oxen Foundation and a community of privacy enthusiasts—mainly targets users for whom data protection and freedom from metadata are crucial. These might be journalists, activists, whistleblowers, or simply everyday users who prefer not to share their communications data.

Who is this messenger for?
In principle, it’s for anyone who wants secure communication, especially those who are unable or unwilling to share a phone number. If, for example, you want to communicate with someone anonymously—without your phone numbers or email addresses being linked—Session is ideal. It can also be helpful in countries with heavy surveillance or censorship, since there’s no central infrastructure that can be blocked or monitored (more on that in a moment). In short: Session is built for privacy enthusiasts but remains simple enough for non-tech-savvy users.
 

2. The Technical Architecture of Session

To understand why Session places such importance on anonymity, let’s look at the technical architecture. Session differs fundamentally from traditional messengers through its decentralized structure and use of onion routing.

Decentralized Infrastructure
Most messengers (e.g., WhatsApp or Signal) operate central servers to relay messages. Session, on the other hand, uses a decentralized network of so-called Service Nodes instead of a single main server. These Service Nodes—servers worldwide run by the community—are responsible for transporting messages. What’s special is that there’s no single point where all data converges. The Service Nodes operate in a peer-to-peer network based on the Oxen blockchain. Put simply, many independent computers work together to provide the messenger service. This means there’s no single point of failure or control that an attacker could exploit—no “single point of failure.”

Onion Routing
Communication in Session uses a three-layer onion routing system, similar to the Tor network. That means a sent message is wrapped in multiple layers of encryption—like an onion with several skins. It then passes through three randomly selected Service Nodes in the network. Each node removes one layer of encryption to figure out which node it should go to next. The first node only knows you (the sender’s IP) and the second node.
The ultimate recipient isn’t directly the recipient’s device - it’s a decentralized node within the recipient’s Swarm. Messages are onion-routed again when the recipient fetches from their Swarm, ensuring anonymity on both sending and receiving sides (There’s a good visual illustration of this on page 9 of the Session whitepaper: https://arxiv.org/pdf/2002.04609). No single node knows both sender and recipient—making traceability extremely difficult. Your IP address is hidden from the recipient and most of the network, giving you a major boost in anonymity.

Service Nodes and Swarms
The Service Nodes in the Oxen network don’t just function as relay stations but also provide storage. They’re grouped into so-called “Swarms.” A Swarm is essentially a small group of nodes responsible for temporarily storing messages. Every Session user is assigned to a specific Swarm, based on their identity (public key). When you send a message, it goes to the recipient’s Swarm and is buffered there if the recipient is offline. Redundancy is built in: multiple nodes in the Swarm typically store the message, so there’s no data loss if one node fails. Once the recipient goes online, they retrieve the message from the Swarm—again via onion routing, preserving anonymity. This system ensures Session is decentralized and resilient: there’s no central server to be taken down or censored, and multiple nodes guarantee delivery even if some fail.
 

3. Metadata Freedom and Anonymity

One of Session’s central promises is: “Send Messages, Not Metadata.” Metadata are information about your communication—for example, who talked to whom and when, from where, and using which device. Such data can be as sensitive as the content of the messages themselves. Session’s approach is to generate and store as little metadata as possible.

• No Phone Number, No Email
  You can already see this approach in registration: you don’t have to provide any personal information. In contrast to Signal, which uses your phone number as an identifier, your identity in Session remains pseudonymous (only the random ID). This eliminates a major category of metadata—there’s no user directory with real identities, no links to your address book, and no connection to your personal details. For example, you can give a stranger your Session ID without letting them derive your phone number or real name from it.
• No Central Metadata Storage
  Because there’s no central server relaying messages, there’s also no single database where communication profiles are collected. For instance, a Signal server could theoretically track which users talk to each other and how often (even if the content is encrypted). With Session, this is much harder: message paths are distributed randomly across many nodes, and nothing is logged in a central database. The Service Nodes only store undelivered messages temporarily and delete them once they have been delivered (time-to-live). Logs such as “User A talked to User B at 3:00 PM” are not needed by the system—and what doesn’t exist can’t be stolen or misused.
• IP Addresses and Location
  Thanks to onion routing, Session hides your IP address from your communication partner and from most of the network. No server that forwards your message sees both your IP and your friend’s IP at the same time. Hence, no one can simply glean your geographic location or internet provider from connection data. Session itself states that it does not log IP addresses or other device data. In contrast, with classic messengers, you must trust the server operator not to analyze or store IP addresses—whereas in Session, it’s solved architecturally.
• Leaving Out Avoidable Metadata
  Session doesn’t collect geolocation data, device information, or usage statistics that could be traced back to you. Even the status display (“online”/“last seen”) is either nonexistent or works without central storage. Where Signal, for example, must store at least account creation time and a minimal record of the last server connection, Session tries to eliminate even those. One expert called the metadata problem the “Achilles’ heel” of many otherwise secure messengers and praised Session for addressing that. Of course, Session can’t prevent all metadata—your internet provider can still see that you’re sending data to the Service Node network (but not the content or recipient). Compared to other services, though, you leave a much smaller data footprint with Session.
• Anonymity in Practice
  What do these technical measures mean for you as a user? In short, you can use Session without anyone (neither the service operator nor a wiretapper) easily figuring out who you are, with whom you’re talking, or where you’re located. Even if someone were to intercept your messages, they would only see gibberish thanks to strong encryption. And even the connection data reveals almost nothing. This metadata freedom makes Session especially attractive for sensitive communications—e.g., for whistleblowers who want to remain anonymous, or any conversation you don’t want linked to your identity. Essentially, you can focus on sending messages rather than metadata, just like the slogan says.
   

4. Security Aspects and Encryption

Session’s security works on two levels: first through its architecture (decentralization, anonymity, as described above), and second through cutting-edge encryption technology. In this section, we’ll take a closer look at Session’s encryption model, including the keys used (public/private keys, Account IDs), group chats, and how file attachments are handled.

End-to-End Encryption and Key Principles

Session employs end-to-end encryption (E2EE) at all times. This ensures that only you and your communication partner can read the cleartext of messages—nobody else, not even the servers in the network. To achieve this, Session uses a system of public and private keys (public/private key cryptography).

Every Session user has a key pair:

• Private key: remains secret on your device. It lets you decrypt messages intended for you and create digital signatures.
• Public key: shared with others (it’s included in your Session Account ID). With this key, others can encrypt messages for you—messages that only you can decrypt with your matching private key.

Think of it this way: your public key is like an open padlock you can hand out to anyone. Someone who wants to write to you “clicks” their message into this padlock. Once it’s locked, only your private key (which only you have) can open it again. This principle ensures that no one other than the intended recipient can read a message, even if it’s intercepted in transit.

The Session Protocol
Session initially used the well-known Signal protocol (hence the fork). However, to better fit its special infrastructure, the Session protocol was developed. It’s closely related to Signal’s methods (the Double Ratchet algorithm, X3DH key exchange, etc.) but has been adapted. One of the casualties of this transition is a security feature called Perfect Forward Secrecy (PFS). PFS usually ensures that past messages remain secure even if your long-term key is later compromised. Currently, Session has not fully implemented PFS. The developers emphasize that this doesn’t pose an acute security risk and that they’re working on improvements, but it’s still a difference compared to Signal.

What does that mean for you? Session messages are strongly encrypted, but theoretically, a full device hack could allow more past messages to be decrypted than would be the case with Signal. Deniable authentication (a feature allowing you to deny after the fact that you sent a message) is also not available right now. These points matter more to crypto experts; for everyday security, Session is still considered highly secure. The important thing is that the core principle—only sender and recipient can read the messages—remains in place.

Account IDs and First Contact (Key Exchange)

How does secure communication between two people who have never chatted before get started? This is where Account IDs come in. Session no longer uses prekeys or prekey bundles. Users directly share Account IDs (66-character strings or QR codes), and messages are encrypted directly for the recipient’s Account ID using the libsodium cryptographic library.

Let’s say you want to message someone for the first time and you only have their Session Account ID. You send a friend request, which includes:

• A brief introductory message (e.g. “Hello, this is so-and-so...”),
• Your Session Account ID,
• Meta information such as your displayed profile name.

This request is encrypted with the recipient’s public key—so only the intended recipient can read it. When the request reaches the network, the recipient can decide to accept or reject it.
If they accept, their app uses your pre-key bundle to establish a secure session key between you both. From that moment on, you share a common secret (similar to Signal’s Double Ratchet start) and can exchange encrypted messages asynchronously. The friend request is thus comparable to an initial handshake: it ensures each side has the necessary public keys of the other to send end-to-end encrypted messages. Technically, Session uses methods similar to the Signal protocol (X3DH—Extended Triple Diffie-Hellman), but wrapped in its own network model.

For you as a user, this is fairly straightforward: you give someone your Session Account ID (for example, via QR code or as text). That person adds you as a contact and sends the first message (which is also the request). You then see a contact request in Session containing the message, and you can accept it. From that point on, you chat normally—everything else is automatically encrypted in the background.

Group Encryption (Group Chats)

Nowadays, group chats are indispensable. Of course, group messages in Session are also end-to-end encrypted, so only participants can read the content. Session offers two types of groups:

• Closed groups: Private groups you’re invited to. Previously, the limit was 10 participants, but now up to 100 members are possible.
• Open groups: Essentially public chats or forums where any number of people can participate (theoretically unlimited). These require a special server (Open Group Server) to distribute messages, but the content remains encrypted.

In a closed group, encryption works similarly to one-on-one chat—just with multiple recipients. Practically, each message is either encrypted separately for each member’s key or a shared group key is used that’s distributed to all members (the latter is more efficient). Signal, for instance, uses so-called Sender Keys for group chats. Session originally used Signal’s methods; current details depend on the Session protocol, but from your perspective, you’ll just see a lock icon indicating that group messages are private. No outside party or server can read those chats. Newly added group members can’t access old messages, as those were encrypted with keys they didn’t have at the time—same as in Signal.

Open groups are a special case: They allow large community discussions. Open groups do not use end-to-end encryption. Instead, messages are encrypted and onion-routed only in transit to the open group server, but the server itself can read messages. Open groups are intentionally public (similar to Telegram channels), so end-to-end encryption isn’t used, avoiding unnecessary performance impact.

Spam Protection?

You might wonder: what does spam have to do with security? Quite a bit—on an anonymous network with no central authority, someone could theoretically spam or launch denial-of-service attacks by sending mass requests or messages to random Session Account IDs. To make that unprofitable, Session leverages a cryptographic trick: The sender of a message must perform a small computation before sending.

Session no longer uses Proof-of-Work per message. Instead, it uses a “message requests” feature, where incoming messages from unknown contacts are isolated, requiring manual user acceptance before appearing in conversations. Additionally, Service Nodes deploy various anti-spam measures at the network level.

File Attachments and Media Sharing

Session of course supports file attachments (photos, videos, PDFs, etc.) and voice messages, all encrypted end-to-end. However, it’s handled differently compared to simple text messages, because large files put more strain on the network.

When you send a file (e.g., a photo) in Session, the following happens under the hood:

1. Your app encrypts the file locally with a one-time file key (e.g., using AES encryption).
2. The encrypted file isn’t sent directly to the recipient (that would be slow via onion routing for large MB files). Instead, your app uploads it—via onion routing—to a special file server.
3. This file server returns a unique link to your app, under which the recipient can retrieve the file.
4. Your app now sends a normal chat message to the recipient that basically includes the download link and the decryption key (all within the E2EE of the chat).
5. The recipient’s app reads the link and key, then downloads the file—again through the anonymous network—from the file server. Using the included key, it decrypts the file to make it viewable.

Importantly, while the file temporarily resides on a server, it’s fully encrypted—the server can’t make sense of it without the key. The standard file server is currently provided by the Session developers (centralized). Why is it centralized? Large files would burden the decentralized Service Nodes and potentially bog down the blockchain network. Thus, they decided to offload file transfers for now, without compromising privacy (since the server doesn’t hold the decryption key).

The good news: This file server is open source, and it’s planned that you’ll be able to run your own server in the future. For instance, an organization could run its own attachment server, or multiple public servers might appear. The code is already public, so anyone could set one up. This remains aligned with the principle of decentralization, even though one component is currently centralized for practical reasons.

For you as a user, this doesn’t change the user experience: just tap the paperclip, choose a photo or PDF—Session takes care of encryption and secure transport behind the scenes. Attachments are protected just as well as normal text messages, even if the path to the recipient is slightly different.

Note: Voice and video calls are already available in Session. Calls are end-to-end encrypted today but aren’t yet onion-routed, a feature still under development. These features are still in beta (noted in an official “Session Updates” channel in the app). We’ll be keeping an eye on how this feature develops.
 

5. Comparison with Signal – Advantages and Disadvantages of Session

Signal is something of a gold standard among secure messengers, so it’s worth looking at how Session compares. Both apps share the philosophy of strong encryption but differ in areas like infrastructure, data protection strategy, usability, and somewhat in target audience.

Session’s biggest advantage is in privacy/anonymity: no phone number, no central logging, encrypted delivery through a distributed network. Signal, on the other hand, shines in maturity and usability: It’s been mainstream for years, is very polished, and is extremely convenient—especially if your existing contacts already use it.

A few points stand out:

Metadata & Privacy:
While Signal collects only the minimum data and is exemplary in privacy among major messengers, Session collects practically nothing. Even Signal needs your phone number and stores that user X (you) is registered with number Y. Session doesn’t have such a user record; you’re just a random string. For many, that’s a key advantage. “The lack of metadata is a huge plus. Metadata is the Achilles’ heel of many secure services,” says a report about Session. And that’s true: by not generating such data in the first place, Session eliminates a whole class of attack vectors (e.g., disclosing connection data to authorities, social graph analysis, etc.).

Security of Encryption:
Both apps offer strong encryption. Signal has been tried and tested for years and is considered extremely secure. Session is built on that foundation. An audit by Quarkslab in 2021 reviewed Session’s security and confirmed its claims. However, it’s worth mentioning that when Session switched to its own protocol, some theoretical security guarantees like Perfect Forward Secrecy were (temporarily) missing. Signal still has the edge here, as it supports PFS. In real-world use, this only matters in very specific scenarios, but hardcore security experts will notice the difference. The Session developers are working to close this gap, aiming to make Session at least as secure as Signal—while also being more private.

Performance and Reliability:
In day-to-day use, there’s almost no difference—messages arrive quickly on both. Session can sometimes be slightly slower (due to relay hops), but we’re talking seconds or fractions of a second. Conversely, Session is more resistant to a single point of failure: if the Signal server goes down or is blocked, Signal users are stuck. Session is more resilient, thanks to its thousands of distributed nodes. That’s a plus for resistance to outages or censorship.

Features and Convenience:
Signal is feature-rich (calls, large group sizes, desktop clients with full multi-device sync, etc.). Session also supports multi-device use (already possible, but more complex than Signal). Voice/video calls are well-established in Signal, while Session has them in beta. Long-term tests show promising results for Session calls, but if you rely on calling extensively right now, Signal is currently more polished.
Another difference: adding contacts is simpler in Signal—anyone in your phone book who has Signal shows up automatically. In Session, you must manually exchange IDs, which can be a small hurdle for spontaneous chats.

To sum up, Session offers greater anonymity, while Signal is more convenient. Both are open source and secure, but they cater to slightly different needs. Which to choose depends on your use case—more on this in the next section.
 

6. Use Cases & Recommendations

When should you use Session, and when might Signal or another messenger suffice or be better? Here are some common scenarios and recommendations:

• Maximum Anonymity Required:
  If you’re in a situation where your identity must remain protected, Session is the top choice. Example: a journalist wants to communicate with a whistleblower. They can use Session without sharing phone numbers. Even if chat content were leaked later, the source’s identity would remain concealed because no personal metadata is attached. Political activists or human rights organizations in repressive regimes similarly benefit from Session, where surveillance is far more difficult. This is the core use case Session was built for.
• Communication Without Personal Number:
  Maybe you want to connect with online acquaintances or communities without giving out your phone number. That’s impossible with Signal (you must share your number), but very easy with Session. For instance, you can post your Session code on a forum so people can message you privately without revealing anything personal about yourself. You can always discard that Session Account ID (by creating a new account) if it becomes too public—though you would have to share the new code with your contacts.
• Secure Group/Team Communication:
  Consider a team of investigative journalists in different countries working on a sensitive story. They can all communicate in a closed Session group without fear that phone connection logs will reveal their collaboration. Or a group of activists in diverse locations uses Session group chats—no eavesdropping, no listening in, no membership list in any cloud. Session excels here. However, if the team wants regular group calls, that’s still not fully implemented in Session (you’d need a separate solution like Jitsi or maybe Signal calls).
• Everyday Communication with Friends/Family:
  For everyday chats with existing contacts, Signal (or sometimes WhatsApp/Threema, depending on your circle) often wins out because people already use it. If you just want to reach Grandma or your schoolmates, and privacy is important but not critical, then Signal is usually sufficient—and easier because your contacts likely already have it. Session’s user base is still smaller. A practical approach: run multiple messengers in parallel—Session for sensitive chats or new acquaintances, and Signal for those who already use it. They’re not mutually exclusive.
• Voice/Video Calls and Multimedia:
  If you rely heavily on voice or video calls, Signal (or possibly WhatsApp, with its privacy drawbacks) is currently more convenient. Session is working on it, but until it’s stable, you might want to use Signal for secure calls. The same goes for advanced multimedia features—Session currently supports GIF searching on Android and iOS (not desktop, but desktop can display GIFs). Emoji reactions are available across all platforms. However, stickers aren’t yet supported.
• Censorship Circumvention:
  In countries where Signal or WhatsApp is blocked by governments (e.g., by targeting known server IP addresses), Session can get through more easily. Because Session’s traffic moves across thousands of distributed nodes and primarily uses higher-numbered ports, like port 22023, rather than port 443. Reports indicate that Session has proved to be a reliable channel in some heavily censored regions where other messengers fail. That’s a technical advantage for Session.
• Business Communication or Team Work:
  Businesses often use other solutions like Matrix/Element, but smaller teams that require high confidentiality could use Session. Keep in mind that Session doesn’t have official admin or user management tools, so it might not suit large organizations. But for small teams needing secure, informal communication, it can work well.

Our recommendation: Evaluate your need for privacy vs. convenience. If you say, “I want maximum security, even if it requires some adjustment,” then give Session a try—it might be exactly the messenger that fits your philosophy. If you say, “I just want a big user base and convenience,” then Signal is an excellent compromise, offering robust security (though it can’t hide your identity from the service itself). Of course, you can also have both: many people use Signal for everyday chats and Session for special cases. Ultimately, it’s great that we have these choices—and Session fills a niche that was previously underserved.
 

7. Open Source and Independence

Security and trust strongly depend on who’s behind an app and how transparent the development is. Both Signal and Session rightly emphasize being open source—i.e., all the code is publicly available and inspectable. But Session takes further steps in terms of independence.

1. Open Source Code
   Session’s code is freely available on GitHub. Any interested developer can review it, submit suggestions, or contribute changes. This is vital for the security community: only if the code is open can experts verify there are no backdoors or serious flaws. In 2021, Quarkslab performed a security audit of Session and found no major issues. This transparency fosters trust. Improvements can be quickly introduced from the outside. Session’s cryptography uses well-documented standards (X25519, AES-GCM, etc.)—no hidden or proprietary algorithms. Everything is set up so the community can verify it.
2. Oxen, Session Technology Foundation and Funding
   Behind Session is not a profit-seeking company but the nonprofit Session Technology Foundation. Interestingly, the project is also funded by the Oxen cryptocurrency. Operators of Service Nodes must stake Oxen coins and receive new coins as rewards for running the nodes. Hence, the network has an incentive model ensuring enough global servers—without a company having to rent them. This economic model differentiates Session from services like Tor, which rely solely on volunteers. It helps ensure the network remains self-regulating and decentralized.
   Some may ask: what if the cryptocurrency fails? So far, the system has worked well, and it means Session doesn’t belong to any single entity. There’s no big tech giant or billionaire investor—just a network of many participants.
3. Freedom from Government Influence
   A major topic in the privacy community is organizational jurisdiction. Signal, for instance, is based in the US. Though the Signal Foundation has an excellent reputation, the US is part of the “Five Eyes” intelligence alliance, which makes some people uneasy. Session originated in Australia (also a Five Eyes country), which prompted them to move the organization to Switzerland in 2024. Switzerland is known for strong data protection laws and political neutrality. This relocation to the newly established Session Technology Foundation in Zug (CH) was a deliberate move to avoid the reach of large intelligence alliances. In the end, security depends mainly on the technology (it should be secure no matter where servers are located), but it does reflect the developers’ philosophical stance.
4. Community and Ongoing Development
   As an open-source project, Session has an active community. Bugs are often identified by users and sometimes fixed even before official updates roll out. Development is transparent—roadmaps and discussions are public. The goal is to maintain a messenger that meets the highest standards in the long run. Part of that includes keeping the code open and allowing forks should the community be dissatisfied. Because the project isn’t tied to a single company or investor, many feel more comfortable: even if the original developers lose interest one day, the community could continue Session.

In summary, Session is independent by design—financially supported by the community and crypto, technically decentralized, legally under a privacy-friendly jurisdiction, and open source at its core. These qualities reinforce the credibility of its security promises. Like Signal (also open source and foundation-driven), Session shows how privacy-focused tools flourish under non-commercial frameworks. Neither Session nor Signal uses ads or sells data—and both rely on donations or alternative funding models. In Session’s case, you can be confident your data isn’t being monetized—simply because Session doesn’t collect any usable data in the first place, and it has no interest in doing so.

8. Criticism of Using Session: Soatok Blog Posts

In his two blog posts “Don’t Use Session (Signal Fork)” (January 14, 2025) and “Session Round 2” (January 20, 2025), the cryptography blogger Soatok raises several points of criticism that are meant to fundamentally argue against using Session. Summarized, the allegations can roughly be divided into the following categories:

Lack or Incomplete Implementation of Essential Security Features
Soatok primarily criticizes that Perfect Forward Secrecy (PFS) is not yet fully implemented and points to a possible deviation from the original Signal protocol that could open up vulnerabilities. Indeed, in earlier versions of Session and in the whitepaper, it was confirmed that Perfect Forward Secrecy has not yet been flawlessly implemented. However, this is not an “unknown” or concealed issue; it is a publicly documented aspect that developers are actively working to improve.

• The fact is: Session is based on a modified version of the Signal protocol (“Session Protocol”) and, in some parts, omits certain security features like PFS, which are well-established in Signal. This shortcoming is real but not a secret. At the same time, independent audits (e.g., by Quarkslab in 2021) have not found any fundamental security flaws but have instead identified improvement potential regarding “Forward Secrecy” and key-management processes.

Uncertainties or Gaps in the Onion Routing and Decentralized Architecture
The articles also claim that Session has an “incomplete” onion-routing concept and leaves user data to the service nodes. Soatok partly questions whether the implementation truly provides increased anonymity or whether attackers could more easily de-anonymize the network than the developers claim.

• The fact is: Session uses a customized onion-routing technique (multi-stage relaying via three random service nodes). Unlike Tor, however, there is no separate, large “directory system”; instead, there is a swarm/node system based on the Oxen blockchain. It’s difficult to directly compare its security level with Tor’s because both networks are structured differently. Nonetheless, the core idea—namely that no single server can simultaneously identify both sender and recipient—remains convincingly implemented. Despite some criticisms regarding possible traffic correlation, most independent analyses (e.g., the whitepaper, audit reports) assess Session’s design as basically solid and conducive to anonymity.

Lack of Transparency or Issues in Code Audits
Soatok accuses the Session developers of not having sufficiently documented all relevant code changes compared to the original Signal fork, seeing this as a risk for undiscovered vulnerabilities.

• The fact is: Session is fully open source. All major code changes are visible, commented on, and versioned through public repositories (GitHub). Larger modules (e.g., the PoW system, the Session protocol) have been documented separately and, in some cases, externally audited. It is true, however, that a fork can quickly diverge from its origin, and the development team must always thoroughly document how it deviates from the original Signal protocol. Sometimes this is done better, sometimes worse; overall, Session’s deviations are discussed in its whitepapers, but the ongoing protocol evolution is indeed complex.

Doubts About the Blockchain-Based Funding Model
Another point concerns skepticism toward the Oxen blockchain and the “service node” operation through staking. Critics like Soatok emphasize that the project depends on the economic stability of a cryptocurrency, which they consider potentially risky.

The fact is: The Oxen-based funding is intended to promote decentralization by giving node operators an economic incentive. However, if the blockchain were to lose value or experience technical problems, Session could also be affected. This is a known dependency that one should be aware of. Still, it is not necessarily a reason to consider Session insecure; rather, it’s about the sustainability and future viability of the network.

Summary and Assessment of the Allegations

• Some Points Are Valid:
  Soatok highlights issues such as missing Perfect Forward Secrecy, deviations from the original Signal protocol, and the (relatively) young, complex technical architecture. Session itself confirms some of these limitations and is working on corresponding improvements. This criticism is therefore not unfounded and generally aligns with what the developers have publicly acknowledged.
• Exaggerated Conclusions:
  However, concluding from the existing shortcomings (e.g., gaps in PFS, potentially vulnerable onion routing) that Session is “unusable” or “completely insecure” is a very drastic interpretation. Several security audits and practical use in high-risk scenarios indicate that Session still offers a high level of security and privacy—especially compared to mainstream messengers.
• Significance for Users:
  Anyone who uses Session should know that there are certain trade-offs compared to Signal (e.g., perfection vs. anonymity, PFS vs. decentralization). Soatok’s articles make clear that Session (still) is not a “cure-all” for every conceivable threat. At the same time, however, it remains a messenger with significantly stronger metadata protection than most alternatives. Users should therefore consider their own threat model: Do I need Perfect Forward Secrecy at all costs (for instance, if an attacker might later gain access to all my devices)? Or is the decentralized, anonymous structure more important to me?

Soatok’s blog posts certainly contain well-founded criticisms—particularly regarding Session’s approach to Perfect Forward Secrecy and protocol documentation. These concerns are real and are not denied by the Session developers, who are addressing them step by step. Concluding, however, that Session should not be used in general overlooks the added value the project offers in terms of anonymity and freedom from metadata. Ultimately, it is advisable for those interested to weigh the arguments from both sides: Soatok points out existing weaknesses, while the Session developers make it clear which goals they prioritize (e.g., decentralized architecture, no phone numbers) and which compromises they accept to achieve them.
 

9. Conclusion

Session stands out as a modern, secure messenger that goes all-in on anonymity and privacy. We’ve seen that Session differs from conventional services on a technical level: a global network of Service Nodes instead of a central server, onion routing for message transfer, no personal registration data required, and clever mechanisms like proof-of-work to fight spam. End-to-end encryption ensures message content remains private, while the architecture prevents much metadata from being generated at all. In terms of message security, Session is on par with well-established solutions like Signal—both use proven cryptographic methods. Yet Session surpasses most messengers in terms of anonymity, as it leaves virtually no traceable information behind.

Who is Session best suited for? If privacy is more than just a buzzword to you—if you really want control over your communication data—Session is a tool worth trying. Especially if you operate in environments where surveillance is possible (politically, professionally, or personally), Session provides a protective layer beyond the norm. You don’t need to share a phone number or create a user profile—you can send a message as if you were two ghosts on the net, visible only to each other and no one else. That might sound dramatic, but for some people, that’s precisely what’s needed.

On the flip side, no messenger is perfect for every situation. For instance, Signal is widely accepted, making it easier to find and add contacts—and it may be enough for many day-to-day conversations. Session excels in more specialized scenarios, relying on users who consciously value privacy. One could say: Signal is the secure everyday car, while Session is the armored vehicle for special operations. Both get you where you’re going, but their equipment and objectives differ.

Recommendation: Give Session a try (it’s free) https://www.getsession.org The app is readily available (for Android, iOS, Windows, macOS, Linux). You might appreciate the peace of mind that comes from knowing no one is eavesdropping. Many people now use multiple messengers in parallel, depending on context—so why not use Session for your most sensitive messages? In practice, you can even tell your friends: “Let’s use Session for this topic; I’ll show you how.” Often, the fact that no phone number is required is enough to spark interest.

In closing, Session is an impressive leap forward in the evolution of secure messengers. It shows how established cryptography can be combined with innovative infrastructure to address the last bastion of data collection—metadata. Session delivers the highest level of security and anonymity for your messages, sending messages instead of metadata. It’s a clear recommendation for anyone who wants genuinely private communication.
 

Sources

Protectstar Inc.:

• Original text “A comprehensive comparison of secure messaging apps: Signal, Telegram, WhatsApp, and Session”
  https://www.protectstar.com/en/blog/telegram-vs-signal-vs-whatsapp-comparison-differences-between-messaging-apps

Official Session Website:

• https://getsession.org/
• Contains download links, FAQs, and general info about Session.

Signal Messenger (Official Website):

• https://signal.org/
• For more details on the Signal protocol and features.

Session Documentation / Whitepaper:

• https://docs.oxen.io/session/
• Explains the technical architecture (Service Nodes, Swarms, Onion Routing, PoW) and differences from the classic Signal protocol.

Oxen Project / Oxen Privacy Tech Foundation, and Session Technology Foundation:

• https://www.oxen.io/
• https://session.foundation

Quarkslab Security Audit (2021):

• https://quarkslab.com/
• Quarkslab performed Session’s security audit, confirming its solid implementation.

Tor/Onion Routing Basics:

• https://www.torproject.org/
• Session uses a similar principle (multilayer encryption) in a modified form.

Information on Registration Without a Phone Number:

• See Session docs: https://docs.oxen.io/session/account-creation
• Confirms that Session doesn’t ask for a phone number or email.

Details on the Proof-of-Work System:

• https://docs.oxen.io/session/pow-and-spam-protection
• Explains why and how Session uses PoW to reduce spam.

Discussion of Perfect Forward Secrecy (PFS) in Session:

• https://github.com/oxen-io/session-issues/
• Developer and community posts on the current status (PFS, Double Ratchet, etc.).

Open Group Server (for large/public groups):

• https://docs.oxen.io/session/open-groups
• Describes the function of open groups, their server architecture, and access methods.

Blog posts cryptography blogger Soatok:

• https://soatok.blog/2025/01/14/dont-use-session-signal-fork/
  https://soatok.blog/2025/01/20/session-round-2/