Session is a private 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’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.
Session uses a slightly modified version of the Signal protocol. The Signal protocol is a cryptographic protocol which is widely used to provide end-to-end encryption for instant message conversations.
We have not changed the fundamental operations of the Signal protocol, but we did make some small modifications to avoid using central servers.
A technical description of these changes made can be found under section 4.8 (Modifications to the Signal Protocol) of the Session whitepaper.
Session is in the process of arranging a full third-party code audit. This audit will provide independent verification around Session’s security, privacy and anonymity. Session is fully open-source, so if you’re interested and have the technical know-how, we encourage you to take a look at our codebase for your own peace of mind; however, we don’t recommend using Session in cases where proven and independently verified security is required.
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 court orders. However, the Loki Foundation could not reveal user identities; the Foundation simply does not have access to the data required to do so. Session ID 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.
Although the Loki Foundation is domiciled in Australia, many members of the Loki team reside outside of Australia; it is unclear if, or to what extent, the TOLA legislation applies to them.
For a more in-depth overview of our perspective on the risks posed by TOLA, read our blog on the issue.
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.
Because Session doesn’t have a central server storing information about your identity, restoring your account using the traditional username and password method is not possible. Your recovery phrase is a mnemonic seed which can be used to restore your existing Session ID to a new device.
Make sure you store it in a safe place!
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.
At the startup screen, click Sign In and then Restore From Recovery Phrase.
Enter your recovery phrase into the text box, and select a new display name.
Your Session ID is recovered.
At the startup screen, tap Continue your Session.
Enter your recovery phrase into the text box.
Enter a new display name and tap Continue.
Select your preferred push notification setting and tap Continue.
Your Session ID is recovered.
Your recovery phrase is not currently able to restore your contacts or messages. For your security, your contacts and messages are stored locally, so they cannot be retrieved once you have deleted them.
Although backups are a planned feature of Session, they have not been implemented yet.
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 used proxy routing to ensure nobody can see who you’re messaging or the contents of those messages. Shortly after launch, Session moved to our onion routing system, which we call onion requests, for additional privacy protection. For more on Session's secure message routing, check out What is an onion routing network? and What is proxy routing?
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).
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 onion requests 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.
Session’s Android client has two options for notifications: background polling, and Firebase Cloud Messaging.
If you choose the background polling method, the Session application runs in the background and periodically polls its swarm for new messages. If a new message is found, it is presented to the user as a local notification.
If you choose Firebase Cloud Messaging (FCM), Session will use Google’s FCM push notification service to deliver push notifications. Your device IP and device ID are exposed to Google and the Loki push notification server. The Loki push notification server also knows your Session ID. However, this doesn’t mean much, because Google already knows your device IP and ID, and as long as you keep your Session ID private, the Loki push notification server can’t do much with that information. Neither Google nor Loki can see the contents of your messages, who you’re talking to, or exactly when messages are received.
On iOS, the user also has two options, similar to Android: background polling, and Apple Push Notification Service (APNs). Both options make use of APNs, but with slightly different privacy implications.
If the background polling option is selected, Session will request an APNs token 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.
If the APNs option is selected, Session will use Apple’s APNs service to deliver push notifications. Your device IP and device ID are exposed to Apple and the Loki push notification server. The Loki push notification server also knows your Session ID. However, this doesn’t mean much, because Apple already knows your device IP and ID, and as long as you keep your Session ID private, the Loki push notification server can’t do much with that information. Neither Apple nor Loki can see the contents of your messages, who you’re talking to, or exactly when messages are received.
We are definitely planning to list on F-Droid — we’re actively working on listing Session on new app repositories wherever possible. Lots of people have requested F-Droid because of its excellent reputation in both the privacy and open-source communities. We'll have Session up on F-Droid as soon as possible!
On Android or iOS, tap the green plus button at the bottom of the main Messages screen, then tap the chat bubble icon that appears above the plus button. Paste or type your contact’s Session ID into the Session ID field, tap Next, then send your contact a message. Once they accept the contact request, you’ll be able to start chatting.
On desktop platforms, click New Session on the main Messages screen, paste or type your contact’s Session ID into the Session ID field, click Next, then send your contact a message. Once they accept the contact request, you’ll be able to start chatting.
Note: on desktop, you can also add a contact by clicking Add Contact in the Contacts section of the app.
One challenge with truly anonymous communications systems like Session is that sometimes you do need to verify the identity of the person you’re talking to! In cases like these, it’s best to use a secure secondary channel of communication to confirm with the other person that you’re both who you say you are.
On mobile, you can delete a contact by swiping left on the contact in the conversation list, and then pressing Delete.
On desktop, you can delete a contact by right clicking on the contact in the conversation list, and then clicking Delete Contact.
Service Nodes are the community operated nodes which make up the Loki Network. There are currently over 1,000 nodes in the network. These Service Nodes are responsible for storing and routing your Session messages. You can read more about Service Nodes in the Loki documentation.
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.
No, your messages are not stored on a blockchain. Messages are stored by swarms, and are deleted after a fixed amount of time (called the “time-to-live”, or TTL).
All of your messages are encrypted, and can only be decrypted using the private key which is stored locally on your device.
Session usernames are permanent alphanumeric names that will be able to be purchased using the anonymous Loki cryptocurrency and attached to a Session ID. Once usernames launch, if you have a Session username attached to your Session ID, others will be able to add you on Session using that name, instead of having to use your full Session ID. Usernames make adding contacts quick and convenient.
Session ID usernames are permanent names which can be purchased and attached to a Session ID. Once purchased and linked, you can give others your Session ID username and they can add you on Session using that name — much more convenient than dealing with a long, complicated Session ID.
Session nicknames are the names you can set for yourself in Session when you create a Session ID. Nicknames can be changed at any time, but you can’t use a nickname to add someone on Session.
Session can send files, images and other attachments up to 10MB in both person-to-person conversations 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.
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.
At the moment, Session uses onion requests. However, this solution only supports something called TCP (Transmission Control Protocol) traffic. TCP is a highly reliable protocol, but it’s also high-latency, meaning that video and voice chat is not viable.
Once Lokinet is implemented (see What is Lokinet? below), it will be possible to implement video and voice chat. Lokinet supports both TCP and UDP (User Datagram Protocol) traffic. UDP is a lightweight and connectionless protocol, making it ideal for broadcasting things like voice and video.
Session’s multi-device implementation led to a large number of bugs which negatively impacted user experience. In order to resolve these issues, we will be temporarily removing multi-device support (including device linking and sync).
This removal occurred in two stages:
Initially, we released a Session client update for all platforms which will disable the device linking interface. No new devices were able to be linked, and users with existing multi-device configurations saw a warning informing them about the upcoming second stage.
Shortly afterwards, all secondary clients in existing multi-device configurations were erased. Primary clients (clients on which a Session ID was first created) were unaffected, and can still be used normally.
Although removing multi-device might sound like a step backwards, it will allow us to make significant improvements to Session’s user experience. These improvements include:
Make no mistake, multi-device is absolutely a feature we want to support. However, we will need to reassess how to implement it without compromising on stability, reliability, or other aspects of the user experience.
Over the next two months, the Session team will spend most of our time working on UX improvements. After that work is finished up, we’ll be taking another swing at multi-device. Whichever implementation we decide on, we will test it extensively before re-adding it, to ensure we can deliver a secure, private multi-device experience with no compromises.
Closed groups are fully end-to-end encrypted group chats. Up to 10 people can participate in a closed group chat. Closed group messages are stored on Session's decentralised network, without using any central server(s).
The short answer: open groups are not as private as person-to-person messages or closed groups.
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.
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 was an interim routing solution which Session used at launch while we worked to implement onion requests. When proxy routing was in use, nstead of connecting directly to a Loki Service Node to send or receive messages, Session clients connected 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 ensured that the client device’s IP address was never known by the service node which fetches or sends the messages. However, proxy routing does provide weaker privacy than the onion request system Session is now moving to. Proxy routing still provides a high level of security for minimising metadata leakage in the interim. The proxy routing system is in the process of being replaced by onion requests; onion requests are now used for all message sending and receiving, but Session still uses proxy requests for communication with the Loki File Server (used for attachments). Session will be fully switched over to onion requests in the first two weeks of June, 2020.
Lokinet is the Loki Project’s onion router. Lokinet is a powerful onion router that is fast enough to handle real-time voice communications, making it a crucial part of our plan to add real-time end-to-end encrypted voice calls to Session without relying on central servers.
The Session team is hard at work fixing bugs and shoring up core messaging functionality, but once the app is working reliably, we’ll be moving on to Lokinet integration to bring voice calling functionality to Session. We’ll keep the community updated on our progress, so be sure to follow our Twitter to stay up to date!
Yes! There is no reason that Session shouldn’t work when you are using a VPN. The only difference is that your VPN provider would contact the Service Node network instead of your client connecting directly.
Got questions, running into an issue, or just want to say hello? You can contact us at [email protected], or hop into the official Session Feedback open group (join the group https://feedback.getsession.org in Session).
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).
Bad encrypted message and Bad encrypted media
This means that your Session app could not decrypt the message you were sent. There are a lot of reasons this might happen, but you should be able to fix it by re-syncing your session.
Session out of Sync
The Session out of Sync error means that something went wrong with the encrypted Signal protocol session between you and the recipient. You can fix this using the Re-sync Session option.
Re-sync session will begin a new encryption session under the hood. This means that if there was something wrong with the ratcheting or pre-key bundles in your session, this should be fixed and you should be able to send messages again.
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,
The Loki Foundation is Australia’s first privacy tech not-for-profit. The Foundation organises and supports a number of privacy tech initiatives around the world and right here in Australia. The Loki Project is the Loki Foundation’s development initiative, building and maintaining privacy tools for individuals and organisations. The Loki Network is the network of infrastructure that supports our privacy tools: Loki Service Nodes, the Loki blockchain, and all the accompanying tools and software.