# Remove Session from Instant Messaging **URL:** https://discuss.privacyguides.net/t/remove-session-from-instant-messaging/18852 **Category:** Tool Suggestions **Tags:** completed **Created:** 2024-06-12T15:16:19Z **Posts:** 48 ## Post 1 by @iamnotamonk — 2024-06-12T15:16:19Z ### Why should this tool be removed? Now that [SimpleX has IP protection,](https://simplex.chat/blog/20240604-simplex-chat-v5.8-private-message-routing-chat-themes.html) Session isn’t needed anymore, (is there a use case where it could be useful?) Even Signal could be removed, but since SimpleX is VC Funded (Signal is not) and many people use Signal (hard to get them to switch), it might be a while to wait. --- ## Post 2 by @anon48875053 — 2024-06-12T15:23:17Z Session meets PG criteria, removing it would require changing it. --- ## Post 3 by @bullring888 — 2024-06-12T15:53:14Z Most people just need their conversations encrypted. You don’t need to be anonymous to your co-workers/friends/family. --- ## Post 4 by @iamnotamonk — 2024-06-12T16:07:26Z Threema meets PG criteria. It isn’t added because PG prefers quality over quantity and dont want to “divide” user base more than it already is. --- ## Post 5 by @jonah — 2024-06-12T16:16:03Z > [@iamnotamonk](#): > > is there a use case where it could be useful? Large group chats? (to be honest I _personally_ wouldn’t really have a problem with adding Threema _nowadays_ too, but that’s a [separate discussion](https://discuss.privacyguides.net/t/threema-instant-messenger/1679/17)) --- ## Post 6 by @anon48875053 — 2024-06-12T16:18:08Z Threema is centralized, the servers aren’t open-source, it doesn’t offer anything that current recommendations don’t offer, and it also costs money. --- ## Post 7 by @iamnotamonk — 2024-06-12T16:20:42Z It offers various things other messenger apps don’t offer (clear business model, option to make polls, etc.) But as @jonah said, this is not the place to discuss it. --- ## Post 8 by @anon48875053 — 2024-06-12T16:20:53Z > [@jonah](#): > > Large group chats? SimpleX is currently working on large groups, communities and public channels: [https://github.com/simplex-chat/simplex-chat#roadmap](https://github.com/simplex-chat/simplex-chat#roadmap) --- ## Post 9 by @iamnotamonk — 2024-06-12T16:24:55Z SimpleX is also working right now in “Improve experience for the new users” (according to their GitHub page, the link you shared) --- ## Post 10 by @mentalfoss — 2024-06-12T20:18:12Z Session shouldn’t have been there from the first place, very sketchy background. I am glad that SimpleX is improving, very good news for the privacy community. --- ## Post 11 by @anon66791365 — 2024-06-12T21:29:11Z There’s an argument to be made specifically for messengers that because not everyone uses every messenger, it might be beneficial to list more messengers and not just the absolute best one. Also wouldn’t be opposed to guides on very popular ones like WhatsApp since they can be configured to be more private than they are ootb. --- ## Post 12 by @iamnotamonk — 2024-06-12T21:39:10Z Session’s CTO responded here to someone asking about it. He makes good points. [https://x.com/securely4024/status/1800712434820514040](https://x.com/securely4024/status/1800712434820514040) --- ## Post 13 by @anon48875053 — 2024-06-12T21:53:51Z Could you just post a reply here? Many of us don’t want to create an account on that garbage platform just to read a post or a reply. --- ## Post 14 by @iamnotamonk — 2024-06-12T22:04:14Z Sure! --- ## Post 15 by @iamnotamonk — 2024-06-12T22:14:55Z **User:** Now that SimpleX offers IP protection (its main criticism), is there any case where it is still better to use @ Session, @ JefferysKee? Is there anything Session still has?Does [sic] Session have any advantages over simplex in any respect? **Session CTO (Kee Jefferys):** Depends on what percent of SimpleX Chat users are using self hosted relays? I assume a very small percent. For the majority of users this “Private routing” adds very little privacy, since both servers in your route will likely be run by SimpleX Chat LTD. In this case it would be fairly simple to correlate the routes? Compared to Session where there’s a network of 2000+ community operated nodes which participate in 3 hop Onion Routing for all users. Maybe I’m wrong about the details? **User:** I don’t think it would be easy to correlate (see picture). Don’t you think is a matter of time SimpleX users start operating nodes in a similar quantity as your’s? Is cheaper than running a Session node. And people will run them even if they don’t get rewarded, altruistically. [Quote from SimpleX blog announcement:] “At the same time, the relays chosen by the sending clients to forward the messages cannot observe to which connections (messaging queues) the messages are sent, because of the additional layer of end-to-end encryption between the sender and the destination relay, similar to how onion routing works in Tor network, and also thanks to the protocol design that avoids any repeated or non-random identifiers associated with the messages, that would otherwise allow correlating the messages sent to different connections as sent by the same user. Each message forwarded to the destination relay is additionally encrypted with one-time ephemeral key, to be independent of messages sent to different connections.” An [sic] from SimpleX FAQ: There will also be a revenue-sharing model from customers to network operators, to provide an incentive for them to continue running nodes, which will increase decentralization and reliability of the network. **CTO:** If relay A knows the exact packets it will send to relay B, then all relay B needs to do is listen for those exact packets and the path is correlated, assuming A and B are run by the same operator. Seems to be a very trivial deanonimisation technique. Above protections dont help? Most people won’t run relays, look at any public access network like Tor, or federated protocols like Matrix, 99% of users use someone else’s server. I don’t see this changing dramatically in the future [Answering SimpleX FAQ]: Making relays pay for use without clever monetization can make things worse, centralizing use around free servers. There’s very few successful paid only messengers. --- ## Post 16 by @anon66791365 — 2024-06-12T22:26:05Z I thought if you wanted onion routing on simplex then you would just put your traffic through tor. They even seem to have an option for that in the official client? --- ## Post 17 by @iamnotamonk — 2024-06-12T23:06:29Z Yeah there’s an option to route through proxy SOCKS and activate only .onion hosts. --- ## Post 18 by @iamnotamonk — 2024-06-12T23:07:48Z According to this, maybe we should wait until there are more servers hosted, or at least until the code is audited. What do you think, @jonah? --- ## Post 19 by @Snoring0415 — 2024-06-13T00:29:08Z To be fair at least in the main chat correlation attacks discussed very vaguely. Especially the certificate forging for fake relay points. My opinion is that this is a naiscant project but it really has a few issues to solve, main one being it’s completely centralized no external relays are allowed. Also usability and battery drain on devices is getting better but you cannot use it as an instant messager yet. --- ## Post 20 by @exaCORE — 2024-06-13T00:50:50Z > [@iamnotamonk](#): > > option to make polls Polls are an option in Element iirc --- ## Post 21 by @iamnotamonk — 2024-06-14T22:39:43Z “Also usability and battery drain on devices is getting better but you cannot use it as an instant messager yet.” I have had no issues with battery tbh. Meta chat apps consume more battery tbh --- ## Post 22 by @hxn — 2024-06-15T02:53:26Z What’s sketchy about the background? Out of all the messengers, I would trust Briar and Session the most. One uses Tor and the other uses something like Tor. Other messengers like Signal are a huge target. I think services that are somewhat well known but aren’t super popular are the most secure, simply because when a service gets bigger, the chances of it becoming shit increase exponentially. This is just my intuition of course, not basing this on any evidence. --- ## Post 23 by @yes — 2024-06-15T05:45:49Z What you’re saying is theoretically true, but also more popular projects are more likely to be reviewed/auidted and more likely for the community to find bugs, etc. --- ## Post 24 by @hxn — 2024-06-15T05:55:48Z True, which is why I think it needs to be of a certain level of popularity, enough that it gets the attention of researchers and experts, but still below the radar. The perfect example is Tuta. They’re overshadowed by Proton. [Tuta’s](https://tuta.com/blog/transparency-report) transparency report in contrast with [Proton’s](https://proton.me/legal/transparency) shows exactly what I mean. You can probably apply [Price’s law](https://nielsbohrmann.com/prices-law/) here. --- ## Post 25 by @mentalfoss — 2024-06-16T09:38:34Z > [@hxn](#): > > What’s sketchy about the background? Session when it started was a project of Loki Network. Loki Network back then was accused, based on many presentations, of being run by extreme right people or group. Don’t know the situation now cause i just stopped following the project when all this fuzz happened. EDIT: Here some sources i was able to dig, for anyone curious: [https://archive.is/5HF6q](https://archive.is/5HF6q) EDIT2: Same more recent discussion on mastodon: [https://infosec.exchange/@WPalant/104489144670580454](https://infosec.exchange/@WPalant/104489144670580454) --- ## Post 26 by @ph00lt0 — 2024-06-16T11:48:04Z Sure but just goes back to the part of supporting forward secrecy. Something that session removed cuz they believe it is not necessary. I don’t think there is a need for these additional options any more. --- ## Post 27 by @beantaco — 2024-06-17T01:25:05Z Almost a year ago, Oxen [announced](https://github.com/oxen-io/oxen-improvement-proposals/issues/36) a transition from OXEN (their privacy token) to an Ethereum-based token named SENT, citing OXEN’s branding and inflation issues, isolation from and lack of interoperability with web3, issues with OXEN being a privacy coin, etc. To my knowledge, OXEN has been funding the anonymity network, and it is also used for purchasing of memorable Session names. I don’t know the current status of the transition, nor if the token change itself has/would directly harm Session’s protection of its users, but no doubt the annuncement would have triggered some people to abandon Session, and I don’t think most OXEN holders would want to migrate to SENT. If the token change degrades Session’s userbase or anonymity network, that would be a concern for the safety of Session users. However, how does Session’s safety and effectiveness compare to that of other messaging software? > [@ph00lt0](#): > > Sure but just goes back to the part of supporting forward secrecy. Something that session removed cuz they believe it is not necessary. I had a read of their protocol [explainer](https://getsession.org/session-protocol-explained) and [technical details](https://getsession.org/blog/session-protocol-technical-information) for references to forward secrecy. On the surface I see merit to their adoption of simpler key management in the context of a decentralised network and multiple devices, but this unfortunately came with abandonment of forward secrecy and deniability, and I’m not convinced that’s acceptable or unavoidable. Before the Session Protocol was deployed, messages managed over multiple devices went out of sync. In their Session Protocol, Oxen opted to simplify key management, citing impracticality of implementing complex key exchange processes over a decentralised network and multiple devices. Further, Oxen assumed that the only method that long-term keys are compromised is by “full physical device access” therefore so would all messages. They also claim (probably truthfully) the disappearing messages feature is rarely used. However, I don’t think the key compromise assumption is true when side-channel attacks, coercion etc are also possible. Abandoning forward secrecy based on their assumptions is a mistake. Oxen cited unlimited account creation as an alternative to forward secrecy. However, this puts all the burden on the users to create a fresh Session account and share their Session ID to all their contacts on a frequent basis. Most people will not do this. Forward secrecy is not the only casualty. This change also affects message deniability. My understanding is prior to the Session Protocol, like the Signal Protocol maybe, messages were verified with a MAC (message authentication code) that doesn’t act as a cryptographic proof that a message was signed by someone. Anyone who could verify a message’s MAC could also have created the message. With the Session Protocol, seems like all messages are irrevocably signed by the sender. However, putting things in perspective, Oxen claimed that courts have upheld messages submitted as evidence even when there is no cryptographic proof. Oxen proposed adding the ability for users to edit messages that are stored on their own devices as a replacement for loss of cryptographic deniability, and additionally this would provide plausible deniability beyond just erasure of cryptographic proof. However, it has been almost 4 years since they proposed it but to my knowledge they have not yet implemented it. Overall, I think it’s ok to keep listing Session for now, but warn the user about its issues, and remove Session if the migration to SENT compromises Session. --- ## Post 28 by @ph00lt0 — 2024-06-17T12:03:53Z > [@beantaco](#): > > but warn the user about its issues We already do so. Unfortunately it isn’t available anymore as Elon Musk kicked me of Twitter lol but I had lengthy discussions about this all with the CTO of session a few years back. We came to the conclusion of agreeing to disagree that their measurements are to be trusted to be sufficient for lacking forward secrecy. I do not agree that the network (largely controlled by them) removes this need. The fact that they first had forwarded secrecy and then just removed it is beyond me and unacceptable. --- ## Post 29 by @anon48875053 — 2024-06-17T12:15:56Z We have Cwtch, Briar, SimpleX and Signal. I think PFS should be a minimum requirement. --- ## Post 30 by @iamnotamonk — 2024-06-17T14:51:42Z Isn’t it on X or you cannot access it? If the later i can try to find those conversations, do you remember any detail? --- ## Post 31 by @ph00lt0 — 2024-06-17T16:19:04Z I was banned from Twitter so no you can’t find it. --- ## Post 32 by @jerm — 2024-06-21T12:27:18Z Session breaks post-compromise security, forward secrecy and repudiation. --- ## Post 34 by @beantaco — 2024-06-29T03:18:08Z > [@anon48875053](#): > > We have Cwtch, Briar, SimpleX and Signal. I think PFS should be a minimum requirement. I agree PFS is desirable. However, putting things in perspective, metadata resistance is also not minimum requirement. Signal and Matrix are in the list of recommendations but don’t provide adequately protect metadata against network surveillance. Matrix isn’t E2EE by default, though it’s exempt because it’s quite different to other instant messsaging. There are some features that instant messaging tools are widely considered essential, like E2EE. Beyond that, people have different preferences, different threat models and different operating systems and devices; and a strict set of minimum requirements would cause exclusion of some suitable tools. Some people need PFS more than metadata resistance, other people need metadata resistance more than PFS. If there are enough tools that satisfy both then it makes sense to require both. I like the idea of SimpleX, but I’m not yet convinced of its metadata resistance. Their website compares SimpleX to Signal, XMPP, Matrix and P2P but not Cwtch or Session :thinking:, so I can’t even compare at a glance. I’ll have to look into it deeper. --- ## Post 35 by @iamnotamonk — 2024-06-29T19:54:37Z Cwtch seems to have better metadata protection than SimpleX, search for Cwtch on Privacy guides discussions, and see my last post there --- ## Post 36 by @anon48875053 — 2024-06-29T19:56:49Z Are you referring to that thread where Cwtch was talking about SimpleX? It’s just her word against his. They just need to sit down and talk it out. --- ## Post 37 by @iamnotamonk — 2024-06-29T19:58:05Z I don’t think they are completely random statements without reasons. Cwtch seems to make some arguments, although they are not in such depth --- ## Post 38 by @jerm — 2024-07-13T19:01:07Z You can’t protect your recovery phrase (seeds phrase) with a PIN or password. --- ## Post 39 by @fria — 2025-03-10T08:10:02Z Compiling reasons here: - no PFS - No PQ encryption - SimpleX Chat has private message routing and tor integration to cover the onion routing - SimpleX Chat seems to handle large groups fine now - [https://oxen.directory/exitnodes/](https://oxen.directory/exitnodes/) lokinet is seemingly lacking in exit nodes, making the onion routing aspect questionably effective --- ## Post 40 by @fria — 2025-03-10T08:18:22Z > [@beantaco](#): > > I agree PFS is desirable. However, putting things in perspective, metadata resistance is also not minimum requirement. Session is the one holding it back from being a requirement quite frankly. --- ## Post 41 by @anon42475305 — 2025-03-10T09:17:08Z Element/Matrix also lacks true PFS no? I would be in favour of Session being removed and PFS becoming a minimum requirement. --- ## Post 42 by @fria — 2025-03-10T09:19:42Z It doesn’t lack E2EE in the actual protocol at least. I’ll be honest though I don’t think matrix belongs there, it’s basically just decentralized discord but with optional E2EE. In fact E2EE by default should be a requirement as well. --- ## Post 43 by @dngray — 2025-03-10T10:41:15Z Element has forward secrecy, it’s just that technically with a backup passphrase you’re able to restore your session keys. If you chose to use no backup and you chose not to export your session keys I don’t see how that would be different. [Olm](https://gitlab.matrix.org/matrix-org/olm/-/blob/master/docs/olm.md) is actually very similar to the Signal Protocol. > [@fria](#): > > In fact E2EE by default should be a requirement as well. I wouldn’t do that [until MLS](https://github.com/matrix-org/matrix-spec-proposals/pull/4256) is more mainstream because for large rooms in any messenger you’re always going to have issues with E2EE. We do have that requirement for 1:1 or “private” chats as it is assumed if something is private it’s meant to be private from anyone as opposed to public rooms that anyone can join. One of the main concerns I have with session is actual general activity within the project. It does seem things have dropped off > **[Contributors to oxen-io/session-android](https://github.com/oxen-io/session-android/graphs/contributors?from=3%2F9%2F2024)** > > Session Android - Onion routing based messenger [DEPRECATED SEE README] - Contributors to oxen-io/session-android Then of course a while ago there was [this article](https://soatok.blog/2025/01/14/dont-use-session-signal-fork/) which brought up some questionable points about the cryptography in general. As far as Loki (and dVPNs) go [I’ve never been a fan of these networks](https://discuss.privacyguides.net/t/decentralized-vpns-and-routing-networks/11818), they normally never have enough nodes to actually be seriously anonymous. --- ## Post 44 by @ph00lt0 — 2025-03-10T20:22:49Z Basically because of the reasons I never supported the inclusion… --- ## Post 45 by @jonah — 2025-03-11T02:22:45Z > [@dngray](#): > > I don’t see how that would be different. It doesn’t rotate keys per message, it’s per X messages. I don’t remember what X is, maybe 100? --- ## Post 46 by @dngray — 2025-03-13T12:26:57Z > [@jonah](#): > > ![](https://forum-cdn.privacyguides.net/user_avatar/discuss.privacyguides.net/dngray/48/21_2.png) dngray: > > > don’t see how that would be different. > > It doesn’t rotate keys per message, it’s per X messages. I don’t remember what X is, maybe 100? It’s the megaolm key and it’s [100, as well as every 7 days](https://blog.neko.dev/posts/unable-to-decrypt-matrix.html). > **Message events in a room are encrypted using Megolm** , which is a combination of AES with a ratchet (state events are unencrypted). The ratchet is like a zip tie. It ticks forward by one step every time you encrypt a message with it. If you send someone a Megolm key at a specific ratchet position, they can decrypt all future messages with it. They can’t decrypt older messages with it. This makes encryption pretty efficient, since you only need to send the encryption key once to all people and they can decrypt future messages with it too. Now obviously if someone leaves the room, you don’t want them to be able to decrypt messages anymore, so in that case you create a new key. Similarly if 7 days passed or you used the key for 100 messages already, clients will also generate a new Megolm key. This means an attacker can’t just read all messages by compromising a single key. --- ## Post 47 by @gravel — 2025-03-16T12:39:51Z Some clarification: > [@fria](#): > > SimpleX Chat has private message routing and tor integration to cover the onion routing It can still be argued that SimpleX’s Tor integration is ineffective, as it is not enabled by default (“privacy by default”). In fact, it requires downloading Orbot. Of course, SimpleX’s Tor integration is more of a courtesy compared to their Private Message Routing, which is enabled by default when sending to unknown relay servers. There have of course been arguments between the “no identifiers” and “devolved mixnet” camps about the possibilities of traffic correlation when using PMR. But in the least, PMR is more of a “feature” than the Tor integration; the latter cannot be a point of comparison as long as Session has **baked-in** onion routing capabilities, to say nothing of comparing PMR and Session. > [@fria](#): > > lokinet is seemingly lacking in exit nodes, making the onion routing aspect questionably effective You don’t need an exit node to use Session (that’s not what these exit nodes are for). The topic of Session vs. Lokinet vs. Tor is too long to cover here. But the lack of free Lokinet exit nodes means one thing only: that Lokinet is not widely used as a Tor alternative. It does not say anything about the effectiveness of the 2000+ service nodes currently powering Session & Lokinet. Session’s nodes connect the Session clients with message storage swarms, file servers and Session Community servers without requiring a translation layer. This is thanks to the fact that all these services speak the Session onion routing protocol. --- ## Post 48 by @redoomed1 — 2025-05-10T13:12:46Z > > > List of changes proposed in this PR: > > - With the [migration of Element from th…e Real-Time Communication page to the Social Networks page](https://github.com/privacyguides/privacyguides.org/pull/3013) as discussed in [FORUM-26077](https://discuss.privacyguides.net/t/list-element-under-social-networks-im-rtc-page-changes/26077), move the criterion for Perfect Forward Secrecy support from best-case to minimum requirement > - Relevant discussion: https://discuss.privacyguides.net/t/im-rtc-perfect-forward-secrecy-requirement/11840 > - Remove Session as a result of the new criteria > - Relevant discussion: https://discuss.privacyguides.net/t/remove-session-from-instant-messaging/18852 > - Remove "Additional Options" and "Encrypted Messengers" headers since there is currently no need for this distinction anymore > - Adjust header levels as a result of the above change > - Format criteria for RTC recommendations using these writing guidelines: https://discuss.privacyguides.net/t/writing-style/27321#p-92745-use-must-for-requirements-11 > - Embed link to paper on future secrecy and post-compromise security in the second footnote, which is also cited in Signal audit in 2016 For context, see > [@List Element under Social Networks + IM/RTC Page Changes](https://discuss.privacyguides.net/t/list-element-under-social-networks-im-rtc-page-changes/26077): > > In addition to recommending [https://discuss.privacyguides.net/t/mastodon-social-networking-software/26076](https://discuss.privacyguides.net/t/mastodon-social-networking-software/26076) I wish to move Element from the Real-Time Communications page to a new Social Networks page. I would consider public Discord servers to be far more akin to social networks than instant messaging, and I think we largely recommend Element to replace Discord for this specific use-case. After making this change, we would also: Fully require PFS for instant messengers. [Previously](https://discuss.privacyguides.net/t/im-rtc-perfect-forward-secrecy-requirement/11840) we downranke… --- ## Post 49 by @redoomed1 — 2025-05-10T13:13:12Z --- ## Post 50 by @redoomed1 — 2025-05-17T00:29:42Z In Progress → Done --- ## Post 51 by @redoomed1 — 2025-05-17T00:29:45Z