Type: Decentralized end-to-end encrypted messenger
Access: Android, iOS, Windows, Mac, Linux
Account required: No personal info — Session ID only
Phone number required: No
Email required: No
Decentralized: Yes — no central server
Open source: Yes
Jurisdiction: Australia — Oxen Privacy Tech Foundation
Last verified: March 2026
What Is Session?
Session is a decentralized end-to-end encrypted messaging application developed by the Oxen Privacy Tech Foundation in Australia. It is designed from the ground up to collect as little metadata as possible — no phone number, no email address and no personal information is required to create an account. Instead, Session generates a random cryptographic Session ID that serves as your identity within the network.
Its decentralized architecture eliminates the central server that most messaging apps depend on — and that represents a single point of failure for both security and availability. Messages are routed through the Oxen Service Node Network — a distributed network of nodes operated by independent parties — rather than through servers controlled by Session’s developers.
How to Install Session
- Download Session from getsession.org — available for Android, iOS, Windows, Mac and Linux
- Open Session — no registration form, no fields to fill
- Click Create Session ID
- Session generates a random ID — a long alphanumeric string that is your unique identity
- Set a display name — this is visible to contacts but has no account link. Use a pseudonym
- Write down your recovery phrase — 13 words that allow you to restore your account on a new device
- Store the recovery phrase securely — losing it means losing your Session ID permanently
Android note: Download from getsession.org directly or from F-Droid rather than Google Play for maximum independence from Google’s infrastructure. The APK from the official site is the most current version.
Session’s Architecture — Why It Matters
Most encrypted messengers — including Signal — depend on central servers operated by the app developer. This creates several vulnerabilities: the servers can be seized, the developer can be compelled to hand over metadata and server outages affect all users simultaneously.
Session’s decentralized approach addresses these vulnerabilities through the Oxen Service Node Network:
| Feature | Session | Signal | |
|---|---|---|---|
| Phone number required | ❌ No | ✅ Yes | ✅ Yes |
| Central server | ❌ Decentralized | ✅ Yes | ✅ Yes — Meta |
| End-to-end encryption | ✅ Yes | ✅ Yes | ✅ Yes |
| Metadata collection | ✅ Minimal | ⚠️ Some | ✅ Extensive |
| IP address exposed to server | ⚠️ To nodes — not dev | ✅ To Signal servers | ✅ To Meta servers |
| Open source | ✅ Yes | ✅ Yes | ❌ No |
| Desktop client | ✅ Yes — standalone | ✅ Yes | ✅ Yes |
What Session Collects — and What It Doesn’t
Session’s minimal data collection is its defining privacy characteristic. Understanding exactly what is and isn’t collected helps set accurate expectations:
| Data Type | Collected? |
|---|---|
| Phone number | ❌ Not required or collected |
| Email address | ❌ Not required or collected |
| Message content | ❌ E2EE — not readable by Session |
| IP address | ⚠️ Visible to service nodes — not to Oxen Foundation |
| Contact list | ❌ Not uploaded to servers |
| Message timestamps | ⚠️ Limited metadata |
| Device information | ⚠️ Minimal — for routing |
IP address note: Session’s service nodes can see your IP address when you connect. The Oxen Foundation — Session’s developer — does not control these nodes and cannot see your IP. However, individual node operators can observe connection metadata. For users who need to hide their IP from service nodes as well, use Session over Tor or a VPN.
Session Over Tor
Session can be used over Tor for additional IP anonymity — routing Session’s traffic through Tor hides your real IP from service nodes. This combination provides the strongest available privacy posture for Session use:
- On desktop: Route Session through Tor Browser’s SOCKS proxy — configure Session’s network settings to use 127.0.0.1:9150 as a SOCKS5 proxy while Tor Browser is running
- On Android: Use Orbot — enable Tor for Session specifically through Orbot’s per-app VPN mode
- On iOS: Onion Browser + manual proxy configuration — more complex, check current Session iOS documentation
Session over Tor adds latency — expect slower message delivery than on a direct connection. For most use cases the additional latency is acceptable. For real-time communication where speed matters, use Session on a direct connection and accept the node-visible IP trade-off.
Session’s Features
| Feature | Available? |
|---|---|
| One-on-one messaging | ✅ Yes |
| Group messaging | ✅ Yes — up to 100 members |
| Open groups / communities | ✅ Yes — larger public groups |
| Voice messages | ✅ Yes |
| File sharing | ✅ Yes — size limited |
| Disappearing messages | ✅ Yes — configurable timer |
| Voice and video calls | ✅ Yes |
| Multi-device sync | ✅ Yes — via recovery phrase |
| Read receipts | ✅ Yes — can be disabled |
Sharing Your Session ID
Your Session ID is a long alphanumeric string — not human-readable like a phone number or username. Sharing it requires one of several methods:
QR code. Session generates a QR code for your ID — the easiest method for in-person contact exchange. The other party scans it with their Session app.
Copy-paste. Copy your full Session ID from the app and send it through another channel — email, a forum post, a dark web message board. Anyone who has your Session ID can initiate contact.
Session username. Session introduced optional human-readable usernames in addition to the random ID — check the current app version for availability. A username makes your ID easier to share but creates a searchable identifier.
Australian Jurisdiction
Session is developed by the Oxen Privacy Tech Foundation in Australia. Australia is a Five Eyes member — part of the intelligence-sharing agreement between the US, UK, Canada, Australia and New Zealand. This raises a flag for users in high-risk environments.
The practical mitigation is Session’s architecture: because messages are end-to-end encrypted and the service nodes holding message data are operated by independent parties globally — not by the Oxen Foundation — an Australian legal order against the Oxen Foundation yields minimal useful data. The Foundation does not control the service nodes, does not hold message content and does not have user IP addresses.
For users whose threat model specifically includes Five Eyes intelligence collection, Cwtch — which has stronger metadata protection and is developed in Canada — is an alternative worth evaluating.
Frequently Asked Questions
Is Session more private than Signal?
For metadata privacy specifically — yes. Signal requires a phone number, which links your account to your real identity unless you use a burner number. Session requires nothing. Signal’s central servers have access to metadata about who communicates with whom and when — Session’s decentralized architecture limits this. For message content security, both are strong — Signal’s encryption protocol is more thoroughly audited than Session’s. The choice depends on whether phone number privacy or content security is the higher priority.
What happens if I lose my recovery phrase?
Your Session ID is permanently lost — there is no account recovery mechanism without the recovery phrase. Store the 13-word recovery phrase in an encrypted password manager or write it down and store it physically in a secure location. Treat it with the same security as a cryptocurrency seed phrase — losing it means losing everything associated with that Session ID.
Can Session be used for group communication with many people?
Yes — Session supports closed groups up to 100 members with full E2EE, and open communities for larger groups. Open communities sacrifice some privacy compared to closed groups — they are moderated by community admins and messages are stored on community servers rather than routed through the service node network. For sensitive group communication, use closed groups rather than open communities.
Does Session work in countries where messaging apps are blocked?
Session’s decentralized architecture makes it harder to block than centralized apps — blocking Session requires blocking the entire Oxen Service Node Network rather than a single domain or IP range. In practice, determined national censors can still disrupt Session through deep packet inspection. Using Session over Tor via Orbot on Android provides the most censorship-resistant configuration.
Is Session suitable for communicating with journalists or whistleblowing?
Session is appropriate for secure ongoing communication with journalists or other contacts after initial contact has been established. For initial anonymous contact — particularly for whistleblowing where the source’s identity must be protected from the very first message — SecureDrop is the more appropriate tool. SecureDrop is specifically designed for anonymous source protection with an institutional recipient. Session is better suited for ongoing communication once both parties have established contact.