WE HAVE MOVED TO SIMPLEX
Anyone that agrees to our Code of Conduct is welcome to join our Simplex Hack Liberty Community Room and our Simplex server, a decentralized, metadata resistant alternative to Matrix! Incognito profiles welcome!
-
Hack Liberty SMP Server
smp://esPsfRFGZd2TRyKijJDorCMo3Ld-QD8Cq8ASx8qrY_Q=@simplex.hackliberty.org,gstc5w42xawazcr4txrcyhitmkhiyu2vkkwy2xhwovbhlapzrccjeyad.onion
-
Hack Liberty XFTP Server
xftp://DfK0yVcc9P5NgfaRR4retNWDDTKFa9g_NqF11maM87Q=@xftp.hackliberty.org,kf25i7slt6skypu47j5kzl4s4nlt3aw3baiocanygf6gprrrbft4dyqd.onion:5233
-
Hack Liberty Community Room
SimpleX Chat - Contact
Why Federation Must Die
The appeal of federation lies in its potential to empower individuals, groups, and communities by enabling the use of open-source software and facilitating decentralized interactions across servers. This model offers a degree of censorship resistance, as the messages or images are replicated across multiple servers, making it difficult for any single entity to censor or control the content.
However, after over two years of administrating public federated services (Matrix, Lemmy), I’ve learned first hand the fundamental problems associated with the design of all federated protocols.
Problems with Matrix (Protocol)
Metadata Leakage
From serpentsec.1337.cx/matrix:
Federated networks are naturally more vulnerable to metadata leaks than P2P or centralized networks. These leaks can be fixed, at the expense of increased complexity of the protocol (thus making it more vulnerable to faulty implementations). Matrix’s failure to prevent these leaks is necessary for proper functioning of the protocol.
Some metadata must be leaked due to features Matrix provides. For example, Matrix’s message verification requires knowing which user and device sent a message (to know which key to verify with). In other cases (such as global profile pictures and nicknames), the information is considered public anyway, and therefore has no need to be encrypted. Matrix’s failure to prevent these leaks is a triviality.
Some metadata leaks are accepted for performance requirements. For example, message reactions and read receipts might not be encrypted because Matrix’s E2EE is slower than normal (non-E2EE) messaging. Encrypting reactions and read receipts could provide a painful user experience (UX). Matrix’s failure to prevent these leaks is a design feature.
Some metadata leaks are simply a matter of the protocol’s failure to consider them. For example, room-specific nicknames, room-specific profile pictures, and message edit events could all be encrypted without breaking the protocol. Matrix’s failure to prevent these leaks is a design flaw.
Matrix’s E2EE does not, however, encrypt everything. The following information is not encrypted:
Message senders
- Message senders are never encrypted
- Due to Matrix’s design, encrypting session/device IDs would break verification
- It’s impossible to prevent timestamps from leaking, since the server can simply note when an event is received anyway
- Join/leave/invite and other room events are never encrypted
- While contents are not leaked, an attacker can know when messages are edited
- Reactions are never encrypted
- Read receipts are never encrypted
- Nicknames are never encrypted
- Profile pictures are never encrypted
To demonstrate some examples of these leaks, I have made some examples available: https://snippets.serpentsec.1337.cx/matrix-metadata-leaks
Admin in the Middle
From What a malicious matrix homeserver admin can do:
Passive information gathering
There’s a lot of passive information gathering a malicious admin can do just by querying the Synapse database and this can happen retroactively. Some of the (meta)data include:
- Chat history of any unencrypted room (duh!)
- Information about the users of their homeserver (duh!), like devices, IPs, etc.
- Reactions to end-to-end-encrypted (e2ee) messages, because reactions aren’t encrypted.
- Room related metadata (even for e2ee rooms), room participants and their avatars/nicks, the room topic, power levels, number of messages people sent and when, etc.
- URL previews of shared links (if enabled on a per room setting)
Active attacks
A malicious admin can perform active attacks against their users and the rooms they participate in if they want. Some of them might be easy to spot from the client’s perspective, others might not.
Messing with rooms
Matrix has the notion of state events which are the events that specify what a room looks like. They specify which users are part of the room, which users are banned, the power levels of users, the name and the topic of the room, etc. These events aren’t e2ee and so, a malicious admin can both read them and send their own events by impersonating a user of their homeserver. This can mainly lead to social engineering attacks. I’ll list a few ways to social engineer and exploit people, as there are multiple ways to do so. I’ll be using @victim:example.com as the account the malicious admin is impersonating.
- React to messages as the user being impersonated. The malicious admin won’t know the content of the message they’re reacting to, but they’ll be able to see others’ reactions to it.
- Set the room topic to an attacker controlled URL. Every participant in the room, regardless of homeserver, will see this as being set by
@victim:example.com, a user they personally trust. A drive-by attack or a leak of the IP address of third party users is possible this way.- Invite accounts into the room. The newly joined account won’t be able to read past e2ee messages, but any messages sent after they joined will be visible given the default settings of most clients.
- Kick and ban people out of the room, which isn’t that bad in itself, but can be disruptive. Similarly, they can increase the power level of other users in the room.
- Send tombstone events, marking the room as being replaced for most clients and prevent further message sending to it.
Messing with the user’s devices
The above attacks can be performed simply by impersonating users without adding any new devices to their account. However, a malicious admin can simply add a new device on a user’s account, thus allowing the sending and receiving of e2ee messages.
In most clients, this will show up as an unverified device, resulting in a red shield icon to be added in the room to showcase the presence of the unverified device. My personal experience is that most people, even privacy minded tech savvy ones, simply ignore this for various reasons. I’m guilty of ignoring this as well. There’s however a per session and per room setting to disable your client from sending messages to unverified devices, if one wants to be completely safe.
In most cases, the attacked user will get a popup in their client that a new unverified device was added. There are ways to circumvent this by not reporting this new device to the user, however I don’t know if encryption will continue working properly for the user in this case.
Protocol Weaknesses
AI Summarized From why not matrix? – Telegraph
Matrix is a complex communication protocol that serves as the foundation for chat applications, functioning as a distributed partially-replicated graph database. A “room” in Matrix is structured as a directed acyclic graph (DAG) composed of events, which can include messages, user states, and bans. The servers in a room aim for eventual consistency, meaning they should replicate enough state for all participants to see a similar view.
To send an event into a room, a participating server appends it to the graph. Each server must verify incoming events based on defined authentication rules, with events cryptographically signed to confirm their origin. However, there are several significant issues and risks associated with using Matrix:
- Append-only Design: Events cannot be deleted, leading to potentially endless history accumulation, which can compromise user deniability.
- Redaction Limitations: Redaction events are advisory; poorly behaving servers may ignore them, retaining the original content.
- Data Leakage: Servers that ignore redactions can inadvertently share supposedly deleted data with new servers joining the room.
- Irreversible Events: Certain events, like membership changes, cannot be deleted as they become part of the room’s auth chain.
- Spam Vulnerability: Bots can be used to spam rooms, complicating the graph and consuming server resources, necessitating room recreation to eliminate spam.
- History Linearization Challenges: Linearizing history is difficult, leading to different servers potentially seeing messages in varying orders.
- Message Forging: It is possible to insert messages into history by crafting plausible events, which may go unnoticed by users.
- Optional Encryption: End-to-end encryption is not mandatory, risking exposure of unencrypted messages in federated rooms.
- Fragile Encryption: Encryption relies on reliable device list updates; failures can lead to broken encryption.
- Device Information Leakage: Device list updates may inadvertently reveal user device information.
- API Interoperability Issues: The lack of a strict definition for canonical JSON can lead to signature mismatches between different server implementations.
- Signature Check Failures: Different programming languages used for homeservers can cause JSON interoperability issues, leading to failed signature checks.
- Arbitrary Signing Key Expiry: Signing keys can expire arbitrarily, causing new servers to reject events from the original server, leading to split-brained rooms.
- Common Split-Brained Rooms: The consensus algorithm for resolving conflicting states is not foolproof, leading to frequent state resets.
- State Reset Chaos: State resets can occur more often with servers written in different languages, causing significant disruptions.
- Loss of Admin Powers: State resets can strip room admins of their powers, making it difficult to manage rooms effectively.
- Room Shutdown Limitations: A room cannot be universally shut down across the federation, which can lead to abuse.
- Moderation Challenges: Effective moderation is hindered by the event auth system’s reliance on accurate state resolution.
- Unauthenticated Media Uploads: Users can upload media without authentication, potentially leading to misuse of the media repository.
- Media Replication Risks: Homeservers can replicate media from other servers, which could lead to denial-of-service issues.
- Unverified Media Uploads: Media uploads are unverified by default, posing risks if harmful content is uploaded.
- Liability for Illegal Media: Homeservers could unknowingly host illegal media due to eager replication from undesirable rooms.
Dubious Encryption Protocols (Megolm)
From: https://nebuchadnezzar-megolm.github.io
We report several practically-exploitable cryptographic vulnerabilities in the end-to-end encryption in Matrix and describe proof-of-concept attacks exploiting these vulnerabilities. When relying on implementation specific behaviour, these attacks target the Matrix standard as implemented by the
matrix-react-sdkandmatrix-js-sdklibraries.1 These libraries provide the basis for the flagship Element client. The vulnerabilities we exploit differ in their nature (insecure by design, protocol confusion, lack of domain separation, implementation bugs) and are distributed broadly across the different subprotocols and libraries that make up the cryptographic core of Matrix.We target the setting where encrypted messaging and verification are enabled, i.e. in the presence of the strongest protections offered by the protocol. Furthermore, all attacks require cooperation of the homeserver. This is a natural threat model to consider, given that end-to-end encryption aims to provide protections against such untrusted third parties. We report the following vulnerabilities and attacks:
- Simple confidentiality break
- Attack against out-of-band verification
- Semi-trusted impersonation
- Trusted impersonation
- Impersonation to confidentiality break
- IND-CCA break
The Megolm protocol, while designed for secure group messaging within the Matrix framework, exhibits several critical weaknesses that can compromise user confidentiality and security.
Resource Consumption
Running a public Matrix server is not cheap. Depending on the number of users, there must be multiple worker containers, effectively requiring that you run between 4 and 12 instances of synapse.
Synapse is hard drive hungry, memory hungry, relatively CPU hungry, and also uses a lot of bandwidth. Don’t expect to run this pile of bloat without throwing money at it.
Problems with Matrix.org (Organization)
Data Collection
From: https://hackea.org/notas/matrix.html:
Summary of the Notes on privacy and data collection of Matrix.org
matrix.org and vector.im receive a lot of private, personal and identifiable data on a regular basis, or metadata that can be used to precisely identify and/or track users/server, their social graph, usage pattern and potential location. This is possible both by the default configuration values in synapse/Riot that do not promote privacy, and by specific choices made by their developers to not disclose, inform users or resolve in a timely manner several known behaviors of the software.
Data sent on a potential regular basis based on a common web/desktop+smartphone usage even with a self-hosted client and Homeserver:
- The Matrix ID of users, usually including their username.
- Email addresses, phone numbers of the user and their contacts.
- Associations of Email, phone numbers with Matrix IDs.
- Usage patterns of the user.
- IP address of the user, which can give more or less precise geographical location information.
- The user’s devices and system information.
- The other servers that users talks to.
- Room IDs, potentially identifying the Direct chat ones and the other user/server.
With default settings, they allow unrestricted, non-obfuscated public access to the following potentially personal data/info:
- Matrix IDs mapped to Email addresses/phone numbers added to a user’s settings.
- Every file, image, video, audio that is uploaded to the Homeserver.
- Profile name and avatar of users.
This time, with such an impressive collection of private data being sent to Matrix central servers, even when you use your own instance, we have to face the facts: Something is seriously wrong.
Read more at: https://gitlab.com/libremonde-org/papers/research/privacy-matrix.org/-/blob/master/part1/README.md
Pedophiles
Matrix is not an adversarial resistant protocol that can and is being abused by many different groups.
From why not matrix? – Telegraph
- speaking of shutting down rooms, you can’t actually force a room to be shut down across the federation. if there are three servers in a room and one of them wants to shut down the room, there’s no way to stop the other two servers from continuing along just as they were. this is good news if you care about internet freedom, sure. this is bad news if people start to abuse instances with unsavory rooms or content. in certain legislations this could present a serious problem.
- pretty much any user on your homeserver can upload media to your server’s media repository at pretty much any time, and media downloads are unauthenticated by default. as a result, you can often just generate a HTTP link to the media. someone might be using your media repository as their personal sharing box at your expense and you may not even realize. NOTE: THIS WAS RECENTLY CHANGED
- you can also ask someone else’s homeserver to replicate media by asking that homeserver to return a copy of it. based on the content ID and the origin server name in the URL, the homeserver will download the media from the origin and likely cache it locally in the process. that could end up being a fun denial-of-service.
- in addition to that, media uploads are unverified by default. if you are running your own matrix instance, there’s a good chance that nothing is scanning that media for unsavory content (like csam or viruses) unless you have also installed a separate content scanner. this is a separate package and is not a core part of the synapse distribution, nor any other homeserver that is available today.
- actually the eager replication of media could end up potentially being quite a massive headache, since all it takes is for one of your users to request media from an undesirable room for your homeserver to also serve up copies of it, at which point you could become liable for hosting copies of illegal media like csam or copyrighted material without necessarily knowing it.
The Matrix.org abuse team is notoriously unresponsive to abuse reports or even taking any steps to prevent the abuse of their servers. Because of this, the platform has turned into a safe haven for tens of thousands of pedophiles to spread illegal child abuse materials without consequence.
Matrix is no place to build a community without being exposed to pedophiles. Even worse, they will often hop to as many servers as possible to replicate as much illegal content as possible and make it harder for a (decentralized) admin response. Every homeserver in the federation is likely hosting child sexual abuse images and videos.
Disgusting, and the Matrix team is completely apathetic about it. Can you imagine that?
Cloudflare Man-in-the-Middle
From Notes on privacy and data collection of Matrix.org · GitHub
[…]
In all cases, we can see the headers
set-cookie,server,cf-rayandexpect-ctwith values set by Cloudflare, which would not be possible if TLS termination was done directly onmatrix.org/vector.imservers.
Removed Tor Browser Support
Tor is built on an over a year old Firefox version which lacks many web features around encryption, i18n and the like. Once Tor updates to the latest Firefox ESR it’ll work once again. Due to lack of funding Tor is not considered a supported browser, there’s also no way for us to run tests against Tor as Playwright does not support it.
t3chguy closed this as not planned Oct 4, 2024
Problems with Lemmy
Data Replication, Moderation, and Abuse
All the data replication and moderation issues from Matrix also apply to Lemmy. This one of the underlying flaws of all federated services. Lemmy admins can be held liable for hosting illegal content that is being replicated over the federation. It also makes Lemmy servers easy targets to be taken down by malicious adversaries.
deFederation
Despite being “de-centralized”, there is censorship in the form of “de-federation”, which effectively removes “wrong-think” servers from the global audience on Lemmy. Even though there is claimed decentralization, a large majority of users congregate on the same few servers.
Censorship is hard, let the community do it!
Any posts that don’t adhere to the Lemmy hive mind are immediately down voted, which is effectively a shadow ban that anyone can do by clicking the down vote button. Post that have any kind of negative score (two down votes) will be removed from the default post feed filters. (Active, Hot). This “shadowban” works to make it so 90% of the Lemmy population doesn’t see your post unless they are filtered specifically for “new” posts.
Reddit and Lemmy are one big Psyop
The entire framework of both Reddit and Lemmy do nothing but help to promote group think and propaganda. Any posts that don’t adhere to group think will be shunned and hidden. Post “scores” are a manipulation tactic used to influence (you) into being biased before you’ve even looked at the post. Manipulating upvotes and downvotes is trivially easy for really anyone, and it’s abused by governments and corporations to create manufactured consensus and trick you into believing that the “herd” thinks a certain way. Of course, having a lot of upvotes appeals to the most pathetic of egos, and the psyop continues with more incentivized group-think posts in a never ending cycle of garbage user generated content.
Why use SimpleX
SimpleX unique approach to privacy and security
Everyone should care about privacy and security of their communications - even ordinary conversations can put you in danger.
Full privacy of your identity, profile, contacts and metadata
Unlike any other existing messaging platform, SimpleX has no identifiers assigned to the users - it does not use phone numbers (like Signal or WhatsApp), domain-based addresses (like email, XMPP or Matrix), usernames (like Telegram), public keys or even random numbers (like all other messengers) to identify its users - we do not even know how many people use SimpleX.
To deliver the messages instead of user identifiers that all other platforms use, SimpleX uses the addresses of unidirectional (simplex) message queues. Using SimpleX is like having a different email address or a phone number for each contact you have, but without the hassle of managing all these addresses. In the near future SimpleX apps will also change the message queues automatically, moving the conversations from one server to another, to provide even better privacy to the users.
This approach protects the privacy of who are you communicating with, hiding it from SimpleX platform servers and from any observers. You can further improve your privacy by configuring your network access to connect to SimpleX servers via some overlay transport network, e.g. Tor.
The best protection against spam and abuse
As you have no identifier on SimpleX platform, you cannot be contacted unless you share a one-time invitation link or an optional temporary user address. Even with the optional user addresses, while they can be used to send spam contact requests, you can change or completely delete it without losing any of your connections.
Complete ownership, control and security of your data
SimpleX stores all user data on client devices, the messages are only held temporarily on SimpleX relay servers until they are received.
We use portable database format that can be used on all supported devices - we will soon add the ability to export the chat database from the mobile app so it can be used on another device.
Unlike servers of federated networks (email, XMPP or Matrix), SimpleX servers do not store user accounts, they simply relay messages to the recipients, protecting the privacy of both parties. There are no identifiers or encrypted messages in common between sent and received traffic of the server, thanks to the additional encryption layer for delivered messages. So if anybody is observing server traffic, they cannot easily determine who is communicating with whom (see SimpleX whitepaper for the known traffic correlation attacks).
Users own SimpleX network
You can use SimpleX with your own servers and still communicate with people using the servers that are pre-configured in the apps or any other SimpleX servers.
SimpleX platform uses an open protocol and provides SDK to create chat bots, allowing implementation of services that users can interact with via SimpleX Chat apps – we are really looking forward to see what SimpleX services can be built.
If you are considering developing with the SimpleX platform, whether for chat bot services for SimpleX app users or to integrate the SimpleX Chat library into your mobile apps, please get in touch for any advice and support.
Comparison with other protocols
| SimpleX chat | Signal, big platforms | XMPP, Matrix | P2P protocols | |
|---|---|---|---|---|
| Requires user identifiers | No = private | Yes1 | Yes2 | Yes3 |
| Possibility of MITM | No = secure | Yes4 | Yes | Yes |
| Dependence on DNS | No = resilient | Yes | Yes | No |
| Single operator or network | No = decentralized | Yes | No | Yes5 |
| Central component or other network-wide attack | No = resilient | Yes | Yes2 | Yes6 |
- Usually based on a phone number, in some cases on usernames.
- DNS based.
- Public key or some other globally unique ID.
- If operator’s servers are compromised.
- While P2P networks and cryptocurrency-based networks are distributed, they are not decentralized - they operate as a single network, with a single namespace of user addresses.
- P2P networks either have a central authority or the whole network can be compromised - see the next section.
Comparison with Matrix
| Feature | SimpleX | Matrix |
|---|---|---|
| Encryption Protocol | End-to-end encryption with additional encryption layers and post-quantum resistant key exchange | Megolm protocol with known weaknesses |
| Message Routing | Private message routing (2-hop onion routing) | Federated architecture with metadata leaks |
| Decentralization | No central component, bootstrap nodes, or global shared state | Central components, bootstrap nodes, and global shared state |
| Media Uploads and Downloads | Local files encryption and manual messaging queue rotations | Unverified by default, with eager replication of media |
| Scalability | Efficient architecture with horizontal scaling | Complex and resource-intensive architecture with limited scalability |
| End-to-End Encryption | Mandatory end-to-end encryption | Optional end-to-end encryption |
| Metadata Protection | Private message routing and metadata protection | Metadata leaks through federated architecture |
| Key Exchange | Post-quantum resistant key exchange | No post-quantum resistant key exchange |
| Tor Support | Tor support with proxy and onion-only routing feature | Removed Tor browser support |
| Cloudflare Integration | No Cloudflare | TLS termination through Cloudflare, introducing man-in-the-middle vulnerability |
Comparison with P2P messaging protocols
There are several P2P chat/messaging protocols and implementations that aim to solve privacy and centralisation problem, but they have their own set of problems that makes them less reliable than the proposed design, more complex to implement and analyse and more vulnerable to attacks.
-
P2P networks use some variant of DHT to route messages/requests through the network. DHT implementations have complex designs that have to balance reliability, delivery guarantee and latency. The proposed design has both better delivery guarantees and lower latency (the message is passed multiple times in parallel, through one node each time, using servers chosen by the recipient, while in P2P networks the message is passed through
O(log N)nodes sequentially, using nodes chosen by the algorithm). -
The proposed design, unlike most P2P networks, has no global user identifiers of any kind, even temporary.
-
P2P itself does not solve MITM attack problem, and most existing solutions do not use out-of-band messages for the initial key exchange. The proposed design uses out-of-band messages or, in some cases, pre-existing secure and trusted connections for the initial key exchange.
-
P2P implementations can be blocked by some Internet providers (like BitTorrent). The proposed design is transport agnostic - it can work over standard web protocols, and the servers can be deployed on the same domains as the websites.
-
All known P2P networks are likely to be vulnerable to Sybil attack, because each node is discoverable, and the network operates as a whole. Known measures to reduce the probability of the Sybil attack either require a centralized component or expensive proof of work. The proposed design, on the opposite, has no server discoverability - servers are not connected, not known to each other and to all clients. The SimpleX network is fragmented and operates as multiple isolated connections. It makes network-wide attacks on SimpleX network impossible - even if some servers are compromised, other parts of the network can operate normally, and affected clients can switch to using other servers without losing contacts or messages.
-
P2P networks are likely to be vulnerable to DRDoS attack. In the proposed design clients only relay traffic from known trusted connection and cannot be used to reflect and amplify the traffic in the whole network.
Simplex Features
- End-to-end encryption using double-ratchet protocol with additional encryption layer
- Post-quantum resistant key exchange in double-ratchet protocol
- Private message routing (2-hop onion routing) to prevent server operators from discovering who connects to whom via network traffic metadata
- Tor support for accessing messaging servers via Tor, providing an additional layer of anonymity and security
- SOCKS proxy support for accessing messaging servers via SOCKS proxy, providing an additional layer of anonymity and security
- TLS 1.2/1.3 support with limited cryptographic algorithms (CHACHA20POLY1305_SHA256, Ed25519/Ed448, Curve25519/Curve448) to ensure secure client-server connections
- tlsunique channel binding as session ID in each client command signed with per-queue ephemeral key to prevent replay attacks
Decentralization and Connection Privacy
- Fully decentralized network with no central component, bootstrap nodes, or global shared state
- No user profile identity, making it harder for attackers to discover who talks to whom
- Private message routing (2-hop onion routing) to prevent server operators from discovering who connects to whom via network traffic metadata
- Flux integration for using pre-configured Flux servers to improve metadata privacy and decentralization
User Experience
- End-to-end encrypted WebRTC audio and video calls
- Private instant notifications for Android and iOS
- Chat database encryption with passphrase
- Local files encryption
- Manual messaging queue rotations to move conversation to another SMP relay
- Sending end-to-end encrypted files using XFTP protocol
- Video messages
- App access passcode
- Optional alternative access password
- Message reactions
- Message editing history
- Reduced battery and traffic usage in large groups
- Message delivery confirmation (with sender opt-out per contact)
Additional Features
- Incognito mode to share a new random name with each contact
- Chat groups in mobile apps
- Connecting to messaging servers via Tor
- Dual server addresses to access messaging servers as v3 hidden services
- Chat server and TypeScript client SDK to develop chat interfaces, integrations, and chat bots
- Haskell chat bot templates
- Terminal (console) client with groups and files support
- One-click SimpleX server deployment on Linode
- Easy to deploy SimpleX server with in-memory message storage, without any dependencies
Roadmap
- Improve stability and reduce battery usage
- Improve experience for new users
- Large groups, communities, and public channels
- Privacy & security slider - a simple way to set all settings at once
- SMP queue redundancy and rotation (manual is supported)
- Include optional message into connection request sent via contact address
- Improved navigation and search in the conversation (expand and scroll to quoted message, scroll to search results, etc.)
- Feeds/broadcasts
- Ephemeral/disappearing/OTR conversations with existing contacts
- Privately share your location
- Web widgets for custom interactivity in the chats
- Programmable chat automations / rules (automatic replies/forward/deletion/sending, reminders, etc.)
- Privacy-preserving identity server for optional DNS-based contact/group addresses to simplify connection and discovery, but not used to deliver messages