Session

What Is Session?

If you want encrypted messaging without handing over a phone number, an email address, or a social graph, mainstream apps make that hard. You either register with an identifier that ties back to you, or you trust a central service that can see a lot of “who talked to who, when” even if it can’t read message content.

Session is built for the opposite priority: minimize the identifying data the service can learn about you while still being usable as a day‑to‑day messenger. Accounts are created without a phone number or email, and message delivery is designed to hide IP addresses using Session’s “onion requests” routing over a decentralized node network.

The distinctive thing here isn’t “it has encryption” (most messengers do). It’s the combination of (1) no phone-number sign-up, (2) onion-routed message transport to reduce network-level metadata exposure, and (3) a network run by many node operators rather than one centralized message-routing server.

Session Features and Performance

Session’s core value proposition is metadata minimization. The app is designed so you can create an account without a phone number or email, and it uses onion routing (“onion requests”) so that no single server should see both where a message came from and where it’s going. In Session’s own FAQ language, onion requests work by splitting knowledge across hops so no single server knows origin and destination.

Under the hood, Session relies on a network of nodes (often discussed as “service nodes” and “swarms”) to route messages and store them temporarily for offline delivery. Oxen’s documentation describes onion requests as building a randomized 3-hop path through the network to obfuscate a client IP address. Oxen’s Session/Lokinet explainer also describes “swarms” used for redundant storage of encrypted messages when recipients are offline.

From a practical-use perspective, this architecture comes with performance trade-offs. Onion routing adds extra network hops, and Session is designed to work without centralized push-by-default assumptions. On mobile, Session’s FAQ explicitly documents two notification modes on Android: a “slow mode” that polls in the background, and a “fast mode” that uses Firebase Cloud Messaging (FCM) and therefore exposes your device IP address and a push token to Google’s push servers. That’s an explicit privacy/latency trade: better notification speed can mean more platform-level exposure.

Session is also open source: Session Docs state that “all of Session’s code is completely open source and available on GitHub,” and the official GitHub organization hosts the Android, iOS, and Desktop clients under GPL-3.0 licenses.

On the network side, your database specs list 2,100 servers across 39 countries, and Session is free. (Those are VPNSpotter-verified figures; they’re consistent with the idea of a multi-operator node network rather than a single region.) Where that matters for users: more geographic distribution generally improves resilience and can reduce single-jurisdiction pressure, but it does not automatically guarantee anonymity (timing and endpoint behavior still matter).

Finally, Session isn’t “magic Tor for everything.” It’s a messenger with a privacy-focused transport. Some features can still expose information to counterparties or platform providers. For example, Session’s FAQ notes that using FCM (fast mode) exposes IP address and a push token to Google-operated push notification infrastructure. And independent reviews have also highlighted that certain real-time features (like calls) can have different metadata properties than store-and-forward messages.

Pricing and Plans

Session is free to use. The Session app is distributed for common platforms (Android, iOS, and desktop builds), and the project documents distribution paths such as GitHub releases and an F-Droid repository for Android users who want to avoid Google Play.

As of Session’s own FAQ, there is discussion of a “Session Token” used for staking to nodes and potential future advanced features within Session, but that is not the same thing as a clearly published consumer subscription plan with prices and refunds. In other words: you can use Session without paying, and any monetization/paid-feature story should be treated as “in progress” unless Session publishes concrete pricing.

Refunds: there is no standard “refund window” to evaluate here because Session does not publish a consumer subscription price list on the official site pages referenced above. If Session introduces paid tiers later, you should reassess based on the purchase channel (App Store/Play Store policies often govern refunds).

Privacy and Security Assessment

Session’s privacy posture is unusually direct in its official documentation: the Session App Privacy Policy states that the app “does not collect or share your information,” and it emphasizes that Session is designed so it doesn’t store identifying device/network data like IP address or user agent. That said, the same privacy policy also acknowledges a real-world exception at first run: the first time you use Session you connect to a seed node run by the Session Technology Foundation to retrieve the server list; the policy says your IP address can be seen by that seed node, but is not recorded, and it suggests using a VPN if you want to shield your real IP. That is the kind of concrete detail we like: it’s a specific place where network privacy depends on operational trust and/or your own network hygiene.

Open-source posture: Session’s own developer documentation and its GitHub organization support that the clients are open source and actively maintained in public repositories. This matters because it enables external review (even if most users won’t do it themselves).

Audit status: Session publicly states it underwent an audit by Quarkslab, and both Session’s blog and Quarkslab’s own resources host materials related to that audit. The Quarkslab report executive summary describes Session as an open-source secure messaging application using decentralized storage servers and an onion routing protocol to send end-to-end encrypted messages with minimal metadata exposure. Session’s blog post about the audit also summarizes issue counts and notes at least one severe Android issue related to TLS verification for retrieving the service node list (as described by Session). The key point: there was third-party scrutiny, and the audit did find issues.

Jurisdiction and governance: the Session Technology Foundation’s GitHub organization describes the foundation as Swiss-based. That’s not automatically “good” or “bad,” but it is relevant for legal pressure and operational control questions. Separately, Session’s Terms of Service frame the Session Technology Foundation as the entity providing the website and app services.

Documented criticisms and research results: in 2026, academic/security community attention intensified. USENIX WOOT 2026 lists a talk/paper titled “Practical Attacks on a Decentralized Secure Messenger Session,” describing an implementation-driven analysis of Session Protocol V1 and demonstrating attacks including impersonation, message timestamp forgery, and message dropping/replay attacks in practical contexts. That doesn’t automatically mean “Session is broken,” but it does mean the protocol and implementation have been studied and found to have practical attack surfaces—exactly the kind of thing a high-risk user should track.

A final, no-BS point: “metadata-free” is a goal, not an absolute. Session’s own FAQ and independent reviews acknowledge situations where third parties can see some data (for example, push notification infrastructure when you opt into fast push on mobile). Session reduces metadata exposure compared to phone-number-based messengers, but it can’t eliminate all metadata created by your device platform, your counterparties, or the basic physics of network timing.

Strengths and Limitations

Strengths

• No phone number or email required. For many users, that single design choice is the difference between “private enough to use” and “instantly linkable.”
• Onion-routed messaging transport (onion requests). Session’s routing design aims to prevent any single relay from learning both source and destination, reducing IP-based linkage.
• Decentralized node network for routing and offline storage. Messages can be stored encrypted across “swarms” of nodes while recipients are offline.
• Open-source clients with public repositories. You can verify what’s shipped, and the project’s development is visible.
• Third-party audit history. Quarkslab performed an audit that’s publicly referenced, and the audit documentation exists outside Session’s own site as well.

Limitations / trade-offs

• Push notifications can trade privacy for speed. Session’s Android FAQ states fast mode uses FCM, exposing your device IP and a push token to Google’s push servers.
• Protocol/implementation research has found practical attacks (V1). WOOT 2026 describes practical attacks including impersonation and message dropping/replay in real environments.
• You still need to manage identifiers carefully. Session uses shareable Account IDs; if you post it publicly, you create your own linkage.
• Not designed for “mainstream convenience first.” The same architecture that reduces metadata can add friction (delivery delays, notification compromises, and general UX rough edges reported by users in community discussions).

Who Should Use Session?

Good fit

1. People who refuse phone-number registration for messaging. If you want a messenger that doesn’t start by collecting a phone number (and doesn’t use address-book discovery by default), Session’s model is built for you.
2. Users who care about IP-address hiding for message transport. Onion requests are explicitly meant to prevent Session from being able to track IP addresses through normal routing.
3. Threat models involving centralized platform pressure. A decentralized node network and minimized account identity can help when you’re worried about a single provider being compelled to map your communications.

Not a great fit

1. People who just want the smoothest, most reliable UX. If your priority is “messages always arrive instantly and notifications always work perfectly,” Session’s privacy trade-offs may frustrate you (especially if you avoid platform push).
2. Users who need the strongest, most-studied protocol guarantees without caveats. Session has audits and ongoing work, but it also has published research demonstrating practical attacks on Session Protocol V1; that’s a sign you should follow updates closely if you’re high risk.
3. Anyone who can’t control endpoint/device risk. Like every messenger, if your phone/desktop is compromised, encryption and routing won’t save you.