Tor vs Session - Comparing Anonymous Communication Approaches

Session is a fork of Signal that removes the phone number registration requirement and replaces Signal's centralized server infrastructure with the Oxen service node network for message routing. Each message is onion-routed through three service nodes before reaching the recipient. Service nodes store encrypted messages temporarily until the recipient retrieves them, enabling asynchronous communication without exposing sender or recipient IP to each other.

Session uses its own routing protocol built on top of the Oxen service node network, separate from Tor's relay network. The anonymity properties are different from Tor: Session optimizes for messaging with asynchronous delivery guarantees, while Tor optimizes for general TCP connection anonymization. Session's routing goes through fewer hops (three) than a typical Tor circuit but the hops are specifically selected service nodes with financial stake rather than random volunteer relays.

Account identity in Session is a cryptographic key pair. Users share their Session ID (derived from their public key) to receive messages. There is no phone number, no email, and no username that needs to be verified by a central authority. This makes Session one of the most frictionless anonymous messaging tools in terms of account creation.

Tor can be used for anonymous communication through several mechanisms: anonymous email services accessible via .onion addresses, XMPP servers with OMEMO encryption accessible as hidden services, and applications that route their traffic through Tor's SOCKS5 proxy. These approaches use Tor for the transport layer and rely on application-level protocols for the communication features.

Session handles the full communication stack: transport anonymization, end-to-end encryption, message storage, and delivery all within the Session system. This integration simplifies setup for non-technical users - download the app, create an account, share your Session ID. No separate Tor browser, no .onion address, no manual application-to-Tor proxy configuration.

The trade-off is control. Session users trust the Oxen service node network and the Session protocol implementation. Tor users who implement their own communication stack over Tor hidden services control all components and can audit or replace any layer independently. For users who want maximum control and are willing to manage more complex infrastructure, Tor-based communication provides more flexibility. For users who want strong privacy with minimal configuration, Session is significantly more accessible.

Session supports group messaging with end-to-end encryption, voice notes, and media sharing. Groups are routed through the same service node network as direct messages. Large groups use a different routing mechanism to handle the scale of delivering messages to many recipients efficiently.

Media in Session is encrypted client-side before transmission and stored on file servers operated by the Session infrastructure. This is conceptually similar to how Signal handles media but without using Signal's (or any other major company's) infrastructure. The media storage is less distributed than message routing, creating a different trust model for media content versus text messages.

Tor-based group communication through .onion services can be implemented with self-hosted chat solutions (Matrix, XMPP) that bind to localhost and are accessible only through Tor. This approach provides maximum control over the infrastructure but requires significantly more setup and is inaccessible to users who have not configured their client to access the specific .onion address.