Session is a secure messaging app that protects your metadata, encrypts your communications and makes sure your messaging activities leave no digital trail behind.
Conversations in Session are end-to-end encrypted, just as in most private messengers. However, when you use Session, the identities of the people communicating are also protected. Session keeps your communication private, secure and anonymous.
When using Session, your messages are sent to their destinations through a decentralised onion routing network similar to Tor (with a few key differences), using a system we call onion requests. Onion requests protect user privacy by ensuring that no single server ever knows a message's origin and destination. For more on this, check out What is an onion routing network? below. For more technical details, read our blog on onion requests.
Session will be deploying onion requests shortly after launch. At launch, Session clients will be using proxy routing to secure messaging traffic. Proxy routing still offers high levels of privacy, security, and anonymity, but once Session moves to onion requests shortly after launch, we will offer even greater levels of security and anonymity.
Session’s code is open-source and can be independently audited at any time. Session is a project of the Loki Foundation, a not-for-profit organisation whose mission is to provide the world with better access to digital privacy technologies.
Has Session undergone a security audit?
Session is in the process of arranging a full third-party code audit. This audit will provide independent verification of our statements around the security, privacy and anonymity Session provides.
As Session is a project of the Loki Foundation, court orders in situations such as this would be targeted at the Foundation.
The Loki Foundation would comply with lawful orders. However, the Loki Foundation could not reveal user identities simply because the Foundation does not have access to the data required to do so. Session account creation does not use or require email addresses or phone numbers. Session IDs (which are public keys) are recorded, but there is no link between a public key and a person's real identity, and due to Session's decentralised network, there's also no way to link a Session ID to a specific IP address.
The most the Loki Foundation could provide, if compelled to do so, would be tangential information such as access logs for the getsession.org website or statistics collected by the Apple App Store or Google Play Store.
We don't believe it does.
For a more in-depth overview of our perspective on the risks posed by TOLA, read our blog on the issue.
Got questions or comments about the app or the project? Contact the team behind Session at [email protected] or reach out to Session on social media.
Running into an issue? Visit Session's Github page for your platform(s):
We welcome community feedback and feature suggestions! Send your suggestions to [email protected], or hop into the official Session Feedback open group (join the group https://feedback.getsession.org in Session).
You don’t need a mobile number or an email to make an account with Session. Your display name can be your real name, an alias, or anything else you like.
Session does not collect any geolocation data, metadata or any other data about the device or network you are using. At launch, Session is using proxy routing to ensure nobody can see who you’re messaging or the contents of those messages. Shortly after launch, Session will be moving to our onion routing system, which we call onion requests. For more on Session's secure message routing, check out What is an onion routing network? and What is proxy routing?
When you send a message, it is sent to your recipient’s swarm. A swarm is a group of Loki Service Nodes tasked with temporarily storing messages for retrieval by the recipient at a later point.
A swarm is a collection of 5 - 7 Service Nodes which are responsible for the storage of messages for a predefined range of Session ID’s. Swarms ensure that your messages are replicated across multiple servers on the network so that if one Service Node goes offline, your messages are not lost. Swarms make Session’s decentralised network backend much more robust and fault-tolerant.
Session is not a peer-to-peer technology — Session clients do not act as nodes on the network, and do not relay or store messages for the network. Session’s network architecture is closer to a client-server model, where the Session application acts as the client and the Service Node swarm acts as the server.
Session’s client-server architecture allows for easier asynchronous messaging (messaging when one party is offline) and onion routing-based IP address obfuscation, relative to peer-to-peer network architectures.
Session usernames are set locally on your device, and are sent to your contacts whenever you send them a message. There is no global database of usernames, which means two users can share the same username. Your Session ID functions as your truly unique identifier.
In messaging apps, metadata is the information created when you send a message — everything about the message besides the actual contents of the message itself. This can include information like your IP address, the IP addresses of your contacts, who your messages are sent to, and the time and date that messages are sent.
It’s impossible for Session to track users’ IP addresses because the app uses proxy routing (and soon, onion routing) to send messages. Because Session doesn’t use central servers to route messages from person to person, we don’t know when you send messages, or who you send them to. Session lets you send messages — not metadata.
An onion routing network is a network of nodes over which users can send anonymous encrypted messages. Onion networks encrypt messages with multiple layers of encryption, then send them through a number of nodes. Each node ‘unwraps’ (decrypts) a layer of encryption, meaning that no single node ever knows both the destination and origin of the message. Session uses onion routing to ensure that a server which receives a message never knows the IP address of the sender.
Session’s onion routing system, known as onion requests, uses the Loki Project’s network of Loki Service Nodes, which also power the $LOKI cryptocurrency. Check out Loki.network for more information on the tech behind Session’s onion routing.
Proxy routing is an interim routing solution being used while we work to implement onion requests. Instead of connecting directly to a Loki Service Node to send or receive messages, Session clients connect to a service node which then connects to a second service node on behalf of the Session client. The first service node then sends or requests messages from the second node on behalf of the mobile device.
This proxy routing system ensures that the client device’s IP address is never known by the service node which fetches or sends the messages. However, proxy routing does provide weaker privacy than the onion request system we will be implementing shortly after launch. Proxy routing still provides a high level of security for minimising metadata leakage in the interim. The proxy routing system will be replaced by onion requests shortly after launch, and we’ll have more to share on that front very soon.
Your recovery phrase is like the master key to your Session ID — it’s important to store it safely and securely, and to ensure that only you have access to it. Here are a few options for keeping your recovery phrase safe:
Remember — the order of the words in your recovery phrase is crucial. However you store it, ensure that you can reconstruct it in the same order in which it was provided.
The Loki Project is the team behind Session. The Loki Project is supported by the not-for-profit Loki Foundation. Loki provides users with tools to interact online in an anonymous, decentralised, secure and private way. Loki builds and maintains the Loki privacy suite, comprised of a private transaction system, the $LOKI cryptocurrency, and a decentralised network of user-operated service nodes. Session uses this decentralised network to power its proxy routing system — and the onion requests system that will be replacing proxy routing.
Session's "Safety Numbers" feature makes it easy for people in a conversation to verify each other if both parties would like to do so. You can use another channel of communication outside of Session to ask for and verify someone's Session Safety Number, and then check that the Safety Number in the app matches what you've been told. If the Safety Numbers match, you're speaking to the correct person. If they do not, the Session account may be an imposter.
Your IP address is never exposed to the recipient of your messages or the Service Nodes that you publish or retrieve your messages from. Session uses onion requests to ensure the only node that can see your IP address is the first hop in your onion request path (see What is an onion routing network? below).
Session’s Android client does not use push notifications. Instead, the Session application runs in the background and periodically polls its own swarm for new messages. If a message is found, it is presented to the user as a local notification.
On iOS, a user can optionally enable push notifications, but Apple’s stricter handling of background processes necessitates a different approach to that used with the Android client.
On iOS Session will request an APNS token (Apple Push Notification Service) from the device and will then register this token with a server run by the Loki Foundation. This Loki Foundation server then obliviously sends the APNS server a push notification request every 1-3 minutes, and APNS server then sends a notification to the users device. This push notification is received silently on the target device and initiates the Session client to poll their own swarm. If no messages are found, the user never sees the notification. If a message is found, it is presented to the user as a local notification.
Using this system, we can provide relatively quick local notifications while ensuring that neither the Apple nor Loki Foundation servers ever know when a user has received a message or the contents of that message
The short answer: open groups are not as private as person-to-person messages.
The long answer: open groups are large public channels where Session users can congregate and discuss anything they want. Open groups, unlike other services in Session, are self-hosted and thus not fully decentralised. Someone has to run a server which stores the open group's message history. Additionally, because open group servers can serve thousands of users, messages are only encrypted in transit to the server rather than being fully end-to-end encrypted.
For smaller group chats with a higher degree of privacy, users are encouraged to use closed groups. You can find out more about open groups and closed groups here.
Closed groups are fully end-to-end encrypted group chats. Up to 10 people can participate in a private group chat. Closed group messages are stored on Session's decentralised network, with no central servers being used or required.
Session allows users to encrypt their local Session database with a PIN code. With this feature turned on, your messages cannot be accessed without knowing your PIN code.
Session can send files, images and other attachments up to 10MB in both person-to-person messages and group chats. By default, Session uses the Loki File Server for attachment sending and storage. The Loki File Server is an open-source file server run by the Loki Foundation — the creators of Session. When you send an attachment, the file is symmetrically encrypted on the device and then sent to the Loki File Server. To send the attachment to a friend, Session sends them an encrypted message containing the link, plus the decryption key for the file. This ensures that the Loki File Server can never see the contents of files being uploaded to it.
Additionally, Session used proxy routing (soon to be onion routing) to hide users' IP addresses when uploading or downloading attachments from the Loki File Server. In future, you will be able to configure the Session app to use a custom file server, such as a self-hosted server or VPS (Virtual Private Server), if you would prefer not to use a file server hosted by the Loki Foundation.