SimpleX network: large groups and privacy-preserving content moderation

Published: Jan 14, 2025

Many people believe that it is impossible to moderate and prevent abuse in end-to-end encrypted conversations. This belief is incorrect — there is a way to prevent abuse and distribution of illegal content without any compromises to users' privacy and security of end-to-end encryption.

Anti-privacy lobbyists use this incorrect belief to advocate for scanning of private communications, which not only would fail to prevent abuse, but would make it worse — because our private data will become available to criminals.

So it's very important to understand how privacy preserving content moderation works, and educate the politicians who you voted for, and who is currently in the office, that we do not need to compromise privacy and security in any way to substantially reduce online crime and abuse.

This post answers these questions:

• Why large groups on SimpleX network don't work well?
• How do we plan to make them scale?
• How do group owners prevent abuse when people participate anonymously?
• How do server operators prevent abuse of their servers and how these measures will evolve without any compromises to privacy and end-to-end encryption?
• Which privacy and security improvements we plan this year?

Large groups on SimpleX network

When we designed groups, we expected them to be used primarily for small groups where people know each other, with not more than 100 or so members.

But we learnt that people want to participate in public discussions remaining anonymous — it protects their freedom of speech. As an experiment, we are curating a small directory of groups that currently has almost 400 public groups, with the largest ones having thousands of members. You can connect to this experimental directory via SimpleX chat address.

Can large groups scale?

Currently the groups are fully decentralized, and every time you send the message to some group your client has to send it to each group member, which is very costly for traffic and battery in large groups.

We are currently working on the new group architecture when dedicated group members that run their clients on the server or on desktop with good internet connection will re-broadcast messages to all members — these members are "super-peers".

We will be offering pre-configured super-peers via the app, and you will be able to use your own super-peers, in case you are hosting a large private group, and to have a better control and ownership of the group — e.g., if we decide to remove our super peer from the group, it will continue to function thanks to your super-peer re-broadcasting messages.

This new design improves both privacy of group participation and censorship resistance of the groups, and also makes abusing the group harder.

Preventing abuse with anonymous participation

All public discussions are abused by spammers and trolls, whether anonymous or not. We have been evolving ability of group owners to moderate conversations by allowing to remove inappropriate and off-topic messages, to block members who send spam, and to make all new members who join their group unable to send messages until approved.

As support for large groups improves, we expect that the attempts to abuse may increase too, unless we add better moderation capabilities in advance.

v6.3 will add ability of the group members to send reports to the group owners and administrators — the beta version we just released adds ability to manage these reports, so group admins won't miss reports when members start sending them.

Other features that we plan to add this year to improve both usability and safety of the groups:

• message comments — some groups may choose to allow only comments, when ability to send messages is restricted to group owners or admins.
• ability to limit the maximum number of messages the members can send per day.
• ability to pre-moderate messages before they can be seen by all members.
• "knocking" — approving new members before they can join the group.
• sub-groups — smaller conversations with the same members.

Preventing server abuse without compromising e2e encryption

Some categories of content may be prohibited by servers operators. An extreme case would be child sexual abuse materials (CSAM).

Many people believe that when conversation is end-to-end encrypted, the problem is unsolvable. This incorrect belief is used by unscrupulous lobbyists and politicians who attempt to mandate various types of content scanning under the guise of preventing CSAM distribution.

We wrote before about how such measures not only would fail to solve the problem, but would make it worse. If our private photos become available to service providers, they will eventually become available to criminals too, and will be used to abuse and exploit the users and their children.

An absolute majority of CSAM distributed online is publicly accessible. Many large tech companies failed to act on it and to remove CSAM from their services before it became an epidemic. We see it as a very important objective to eliminate the possibility to distribute CSAM from publicly accessible groups, even if it hurts network growth.

When we receive a user complaint about CSAM shared in any group, we remove the files and, in some cases, the links to join the group from our servers. Our approach to moderation preserves user privacy and security of end-to-end encryption.

How does it work? Let's go over the process step by step.

1. A user discovered the link to join the group that distributes CSAM and sent a complaint to our support email address or via the app to SimpleX Chat team contact.

2. Once we received the link to join the group, we instruct our automated bot to join it. If the complaint is confirmed as valid, the bot sends the information about the files sent in this group to the servers that store these files.

3. Once the servers receive the file identifiers from the bot, they block the files.

File servers cannot look inside end-to-end encrypted files, and they don't even know file sizes — they are securely locked, and sent in chunks, across multiple servers. But if the bot that joined the group provides the address of the particular file, the server can delete this file. It doesn't allow the servers to access any other files.

In this way, the moderation is possible without any content scanning, and it preserves privacy and security of end-to-end encryption.

Privacy-preserving content moderation

Right now, when we act on user complaints, we delete uploaded files or the links to join the groups from our servers, and to the users it looks as if something stopped working.

We are currently rolling out the change to the servers that would mark these files and group links as blocked, so that users who try to download them or to join blocked groups can see that they were blocked for violating server operator conditions of use. This will improve transparency of moderation and reliability of the network.

Later this year we plan to do more than that — client-side restrictions on the clients that violated conditions of use by uploading prohibited content.

How would it work? When the client discovers that the uploaded file was blocked, it may, optionally, depending on the information in the blocking record, disable further uploads from the app to the servers of the operator that blocked the file. Also, when the client that tried to receive the file sees that the file is blocked, it may also refuse to receive further files from the same group member via the same servers.

In this way, the servers can restrict the future actions of the users who violate the conditions of use, while preserving privacy and security of the users and content – even of those users who violated the conditions.

We discussed this plan with the users, and we really appreciate their feedback. The current plan is quite different from our initial ideas, the users had a real impact. Users asked the questions below.

Can't users modify their clients code to circumvent these restrictions?

Yes, they can, but for this to work both sender and recipient would have to modify their clients. It's technically complex, so most users won't do it, and it is also hard to coordinate between users who don't know and don't trust each other.

So these measures would be effective, even though they can be in theory circumvented, as any restrictions can be.

Other services that identify users reduce abuse by blocking the user account. It is even easier to circumvent than changing the client code, and yet these measures reduce abuse.

Can't users use other servers?

Yes, they can. But in the same way as web browser is not responsible for the content you can access, SimpleX app should not restrict your communications with other servers based on blocking action from just one server.

That approach allows different server operators to have different content policies, depending on their jurisdiction and other factors. It also prevents the possibility of abuse by server operators.

Wouldn't these measures be abused?

With the proposed changes, server operators will only be able to prevent uploads to their own servers, which prevents any impact on other communications.

In the future we plan to increase the resilience to any server malfunction or abuse by using multiple different servers with each contact.

If servers were to apply any upload restrictions unreasonably, the users would simply stop using them.

At the same time, server operators need to have technical means to protect their servers from users' abuse, and the proposed client-side restrictions achieve it.

What additional measures are considered?

We published other technical ideas that could be used to prevent distribution of illegal content in this document. None of these measures compromise users' privacy or end-to-end encryption, and they can (and should) only be applied to publicly accessible content that other users complained about.

We technically cannot, and we won't scan all content. We actively campaign against any content-scanning proposals, because it violates our right to privacy, and it would result in huge increase of online crime.

The belief that it is impossible to moderate conversations when they are e2e encrypted is incorrect. It is possible when users themselves share conversation contents with server operators, in which case the operators can identify and, if necessary, remove this content. It is also possible to moderate conversations that users made publicly accessible.

Send us comments and questions

Let us know any comments and feedback to the proposed measures. This is still an evolving design, and it won't be implemented until later this year.

Your comments will help to find the right balance between users' and server operators' requirements.

Privacy and security improvements we plan this year

To increase privacy and security we plan to add this year:

• quantum-resistant e2e encryption in small groups.
• receiving proxy for files, to protect users IP addresses and other transport metadata from file senders' servers.

We see privacy and security as necessary for online safety, and prevention of abuse. If you don't already use SimpleX network, try it now, and let us know what you need to make it better.

Oppose digital IDs – they break the law and lead to mass scale surveillance

Published: Dec 18, 2024

Starting next year, the UK government plans to introduce digital ID cards for the young people to prove their age when visiting pubs. While officials claim this system will remain optional, it's part of a broader government initiative to move more state functions online so that people can prove their identity for everything from paying taxes to opening a bank account using the government-backed app. This will be a step toward a society where every pub visit, purchase, and social interaction becomes a permanent digital record linked to a government-issued ID – a step to normalizing mass surveillance at scale.

Digital IDs are promoted as a way to fight law violations, and some politicians support them as a way to tackle illegal immigration. But digital IDs themselves break the law. Article 8 of the European Convention of Human Rights says: “Everyone has the right to respect for his private and family life”. It means that not only our right to privacy is enshrined in the law, but the right to have our privacy respected is also part of the law. Asking to present a digital ID when visiting a pub, even if it is optional, disrespects our privacy, and is therefore illegal.

Digital IDs would not stop people who decide to break laws. Pubs already can refuse to serve alcohol to young people and require the ID in case the age is in doubt. And illegal immigration can also be reduced without any digital IDs. But introducing digital IDs and collecting our actions, names and locations in one government-controlled database will result in making this information easier to access for criminals, and being exploited for financial and identity crimes.

What starts as a "convenient option" is likely to end as a mandatory requirement. The digital ID systems being pushed by governments and corporations aren't about making our lives easier. They're about tracking, monitoring, and controlling every move we make. And we can see where this road leads in China, when IDs and social scores created for convenience are used to prevent access to basic services and bank accounts as a punishment for legal social media posts that the government disagrees with. What started as a convenience, is now trialed to track the duration of public toilet visits.

The United Kingdom is a democratic country, and the law protects our right to privacy and freedom of speech. If we accept digital IDs as something required for simple things, like buying a drink, it leaves the door wide open to a range of privacy violations.

We call on everyone to oppose the digital ID systems. Do not use them. Do not install these systems in your pub, for as long as it is not legally required. Support local businesses that don’t use them. Protect your privacy and freedom by using software that respects them. Demand that your privacy is respected, as required by law.

To make your voice heard, email your MP expressing your rejection of digital IDs as a violation of European Convention of Human Rights in three simple steps:

1. Copy the text below or click this link to copy it into email app:

Dear …,

I object to the introduction of digital IDs in pubs or any other public places for these reasons:

1. It violates the European Convention of Human Rights, article 8: “Everyone has the right to respect for his private and family life” (https://fra.europa.eu/en/law-reference/european-convention-human-rights-article-8-0).
   Asking to present digital IDs when proof of identity is not legally required, even if it is optional, disrespects our privacy, and is therefore illegal.
2. It will not be an effective measure in reducing the violations of the law. People who want to circumvent it, will find a way.
3. It will increase crime, because combining a large amount of private information in a single system increases the risks of this information becoming available to criminals, who will exploit it for financial crimes and identity theft.

I kindly ask you to oppose this plan, both publicly and during any discussions in the UK Parliament.

Sincerely yours,
…

2. Find the email address of your MP and copy it to the email.

3. Fill in the blanks, edit the text if needed, and send it!

Public opposition changed government decisions in many cases.

It is your opportunity to tell the government which country you want to live in — please use it!

SimpleX network: preset servers operated by Flux, business chats and more with v6.2 of the apps

Published: Dec 10, 2024

What's new in v6.2:

• SimpleX Chat and Flux improve metadata privacy in SimpleX network.
• Business chats to provide support from your business to users of SimpleX network.
• Better user experience: open on the first unread, jump to quoted messages, see who reacted.
• Improving notifications in iOS app.

What's new in v6.2

SimpleX Chat and Flux improve metadata privacy in SimpleX network

SimpleX Chat and Flux (Influx Technology Limited) made an agreement to include messaging and file servers operated by Flux into the app.

SimpleX network is decentralized by design, but in the users of the previous app versions had to find other servers online or host servers themselves to use any other servers than operated by us.

Now all users can choose between servers of two companies, use both of them, and continue using any other servers they host or available online.

To use Flux servers enable them when the app offers it, or at any point later via Network & servers settings in the app.

When both SimpleX Chat and Flux servers are enabled, the app will use servers of both operators in each connection to receive messages and for private message routing, increasing metadata privacy for all users.

Read more about why SimpleX network benefits from multiple operators in our previous post.

You can also read about our plan how network operators will make money, while continuing to protect users privacy, based on network design rather than on trust to operators, and without any cryptocurrency emission.

Business chats

We use SimpleX Chat to provide support to SimpleX Chat users, and we also see some other companies offering SimpleX Chat as a support channel.

One of the problem of providing support via general purpose messengers is that the customers don't see who they talk to, as they can in all dedicated support systems.

It is not possible in most messengers, including SimpleX Chat prior to v6.2 - every new customer joins a one-to-one conversation, where the customers see that they talk to a company, not knowing who they talk to, and if it's a bot or a human.

The new business chats in SimpleX Chat solve this problem: to use them enable the toggle under the contact address in your chat profile. It is safe to do, and you can always toggle it off, if needed - the address itself does not change.

Once you do it, the app will be creating a new business chat with each connecting customer where multiple people can participate. Business chat is a hybrid of one-to-one and group conversation. In the list of chats you will see customer names and avatars, and the customer will see your business name and avatar, like with one-to-one conversations. But inside it works as a group, allowing customer to see who sent the message, and allowing you to add other participants from the business side, for delegation and escalation of customer questions.

This can be done manually, or you can automate these conversations using bots that can answer some customer questions and then add a human to the conversation when appropriate or requested by the customer. We will be offering more bot-related features to the app and a simpler way to program bots very soon - watch our announcements.

Better user experience

Chat navigation

This has been a long-standing complaint from the users: why does the app opens conversations on the last message, and not on the first unread message?

Android and desktop apps now open the chat on the first unread message. It will soon be done in the iOS app too.

Also, the app can scroll to the replied message anywhere in the conversation (when you tap it), even if it was sent a very long time ago.

See who reacted!

This is a small but important change - you can now see who reacted to your messages!

Improving notifications in iOS app

iOS notifications in a decentralized network is a complex problem. We support iOS notifications from early versions of the app, focussing on preserving privacy as much as possible. But the reliability of notifications was not good enough.

We solved several problems of notification delivery in this release:

• messaging servers no longer lose notifications while notification servers are restarted.
• Apple can drop notifications while your device is offline - about 15-20% of notifications are dropped because of it. The servers and the new version of the app work around this problem by delivering several last notifications, to show notifications correctly even when Apple drops them.

With these changes the iOS notifications remained as private and secure as before. The notifications only contain metadata, without the actual messages, and even the metadata is end-to-end encrypted between SimpleX notification servers and the client device, inaccessible to Apple push notification servers.

There are two remaining problems we will solve soon:

• iOS only allows to use 25mb of device memory when processing notifications in the background. This limit didn't change for many years, and it is challenging for decentralized design. If the app uses more memory, iOS kills it and the notification is not shown – approximately 10% of notifications can be lost because of that.
• for notifications to work, the app communicates with the notification server. If the user puts the app in background too quickly, the app may fail to enable notification for the new contacts. We plan to change clients and servers to delegate this task to messaging servers, to remove the need for this additional communication entirely, without any impact on privacy and security. This will happen early next year.

SimpleX network

Some links to answer the most common questions:

How can SimpleX deliver messages without user identifiers.

What are the risks to have identifiers assigned to the users.

Technical details and limitations.

Frequently asked questions.

Please also see our website.

Please support us with your donations

Huge thank you to everybody who donated to SimpleX Chat!

Prioritizing users privacy and security, and also raising the investment, would have been impossible without your support and donations.

Also, funding the work to transition the protocols to non-profit governance model would not have been possible without the donations we received from the users.

Our pledge to our users is that SimpleX protocols are and will remain open, and in public domain, so anybody can build the future implementations of the clients and the servers. We are building SimpleX platform based on the same principles as email and web, but much more private and secure.

Your donations help us raise more funds — any amount, even the price of the cup of coffee, makes a big difference for us.

See this section for the ways to donate.

Thank you,

Evgeny

SimpleX Chat founder

Servers operated by Flux — true privacy and decentralization for all users

Published: Nov 25, 2024

• Welcome, Flux — the new servers in v6.2-beta.1!
• What's the problem?
• Using two operators improves connection privacy.
• SimpleX decentralization compared with Matrix, Session and Tor.
• What's next for SimpleX network decentralization?

Welcome, Flux – the new servers in v6.2-beta.1!

Flux is a decentralized cloud infrastructure that consists of user-operated nodes [1]. With this beta release all SimpleX Chat users can use pre-configured Flux servers to improve metadata privacy and decentralization.

We are very grateful to Daniel Keller, CEO and co-founder of Flux, for supporting SimpleX network, and betting on our vision of extreme decentralization of communication. Flux investing their infrastructure in our vision is a game changer for us and our users.

Download new mobile and desktop SimpleX apps from TestFlight (iOS), Play Store, our F-Droid repo or GitHub.

Read on to learn why it is important and how using several operators improves metadata privacy.

What's the problem?

SimpleX network is fully decentralized, without any central component or bootstrap nodes — you could use your own servers from day one. While there is no full list of SimpleX network servers, we see many hundreds of servers in public groups.

But a large number of SimpleX app users use the servers pre-configured in the app. Even though the app randomly chooses 4 servers in each connection to improve privacy and security, prior to v6.2 for these users the servers were operated by the same company — ourselves.

Our open-source code that we are legally bound to use doesn't provide any metadata that could be used to learn who connects to whom. But the privacy of users' connections still depends on us honouring our promises and privacy policy. Flux servers in the app improve that.

Using two operators improves connection privacy

To ensure that the users' metadata from different servers cannot be combined to discover who talks to whom, the servers in each connection have to be operated by different independent organizations.

Before this version the app was choosing servers randomly. Now, when both SimpleX Chat and Flux servers are enabled it will always choose servers of different operators in each connection to receive messages and for private message routing, increasing metadata privacy for all users.

Flux servers are configured as opt-in, and the privacy policy and conditions of use that apply to Flux servers are the same as for SimpleX Chat servers, to make it simple for the users.

To improve connection privacy by using Flux servers all you have to do is to enable Flux once the app offers it, or later, via Network & servers settings, and accept that the same conditions apply.

By default, if both Flux and SimpleX servers are enabled in this version, you will be using SimpleX Chat servers to receive messages, Flux servers to forward messages to SimpleX Chat servers, and the servers of both to forward messages to unknown servers. We will enable Flux to receive messages by default a bit later, or you can change it now via settings.

Any additional servers you add to app configuration are treated as belonging to another operator, so they will also be used to improve connection privacy, together with pre-configured servers, unless you disable them.

SimpleX decentralization compared with Matrix, Session and Tor

SimpleX network decentralization model is different from other decentralized networks in several important aspects.

Communication network	SimpleX	Matrix	Session	Tor-based
Full decentralization	✅	-	-	-
No user profile identity	✅	-	-	-
Connection privacy	✅	-	✅	✅
Server operator transparency	✅	✅	-	-

Full decentralization

Fully decentralized networks do not have a central component, bootstrap nodes or any global shared state, like in cryptocurrency/blockchain-based communication networks. The presence of any central component or shared state introduces an attack vector that undermines privacy and security of the network.

No user profile identity

User profile identities, even if it is only a random number or a long-term key, undermine privacy of users connections, because in some cases they may allow network operators, observers and users to find out who talks to whom.

Most communication networks rely on fixed user profile identities. It includes Matrix and communication networks with onion routing.

SimpleX network design avoids the need for profile identities or keys, while still allowing optional long-term addresses for users and groups for convenience. It protects users from being discovered and approached by malicious parties, and many family users chose to use SimpleX with children because of it.

Connection privacy

SimpleX network has private message routing (2-hop onion routing) — it prevents server operators from discovering who connects to whom via network traffic metadata. Onion routing used in Tor-based messengers and in Session also hides it. But because neither Tor nor Session users have knowledge about who operates servers, in some cases the clients may connect via the servers controlled by one entity, that may learn the IP addresses of both parties.

Statistically, if traffic metadata from 2% of onion network servers is available to an attacker, and the client chooses servers randomly, after about 1750 of such choices the probability of choosing attacker's servers as both entry and exit nodes, and connection privacy being compromised becomes over 50% [2].

Matrix network does not provide connection privacy, as not only user identity exists, it is tied to a specific server that knows all user connections and a part of user's contacts connections. What is worse, Element — the most widely used Matrix app — offers the servers of only one organization to create an account, resulting in some degree of network centralization.

Server operator transparency

Operator transparency means that network users know who operates the servers they use.

You may argue that when the operators are known, the servers data can be requested by the authorities. But such requests, in particular when multiple operators are used by all users, will follow a due legal process, and will not result in compromising the privacy of all users.

With Tor and Session networks such legal process becomes impossible, and some users may see it as advantage. But nothing prevents the attackers, both criminal and corporate- or state-funded, to compromise the privacy of Tor or Session users by running many servers, or by purchasing traffic metadata from the existing server owners — there are no legal conditions that prohibit server owners of these networks to share or sell traffic data.

Because of that, we see operator transparency in SimpleX network as a better trade-off for privacy of most users than operator anonymity provided by Session and Tor. You can see privacy of network participants as a zero sum game — for the end users to have it, server operators should be known.

What's next for SimpleX network decentralization

SimpleX network is designed for extreme decentralization — not only users are distributed across network operators, as happens with federated networks, but each conversation will be relying on servers of 4-6 independent operators, and these operators will be regularly and automatically changed in the near future.

We believe that the only viable commercial model is freemium — a small share of paying users, who have better service quality and additional features, sponsors free users. This model doesn't have downsides of exploitative "provide service, sell data" approaches, that technology monopolies practice, and it also doesn't have problems of cryptocurrency blockchains, that have shared and immutable state, and also have regulatory problems.

To provide this extreme decentralization with freemium model we will create the system of payments allowing server operators to receive money for infrastructure certificates that will be used with any other participating network operators without compromising privacy of the paying users. You can read about this model here. We will be writing more about it as this development progresses.

SimpleX network

Some links to answer the most common questions:

How can SimpleX deliver messages without user identifiers.

What are the risks to have identifiers assigned to the users.

Technical details and limitations.

Frequently asked questions.

Please also see our website.

Please support us with your donations

Huge thank you to everybody who donated to SimpleX Chat!

Prioritizing users privacy and security, and also raising the investment, would have been impossible without your support and donations.

Also, funding the work to transition the protocols to non-profit governance model would not have been possible without the donations we received from the users.

Our pledge to our users is that SimpleX protocols are and will remain open, and in public domain, so anybody can build the future implementations of the clients and the servers. We are building SimpleX platform based on the same principles as email and web, but much more private and secure.

Your donations help us raise more funds — any amount, even the price of the cup of coffee, makes a big difference for us.

See this section for the ways to donate.

Thank you,

Evgeny

SimpleX Chat founder

[1] You can also to self-host your own SimpleX servers on Flux decentralized cloud.

[2] The probability of connection being de-anonymized and the number of random server choices follow this equation: (1 - s ^ 2) ^ n = 1 - p, where s is the share of attacker-controlled servers in the network, n is the number of random choices of entry and exit nodes for the circuit, and p is the probability of both entry and exit nodes, and the connection privacy being compromised. Substituting 0.02 (2%) for s, 0.5 (50%) for p, and solving this equation for n we obtain that 1733 random circuits have 50% probability of privacy being compromised.

Also see this presentation about Tor, specifically the approximate calculations on page 76, and also Tor project post about the changes that made attack on hidden service anonymity harder, but still viable in case the it is used for a long time.

Wired’s Attack on Privacy

Published: Oct 16, 2024

The Wired article by David Gilbert focusing on neo-Nazis moving to SimpleX Chat following the Telegram's changes in privacy policy is biased and misleading. By cherry-picking information from the report by the Institute for Strategic Dialogue (ISD), Wired fails to mention that SimpleX network design prioritizes privacy in order to protect human rights defenders, journalists, and everyday users who value their privacy — many people feel safer using SimpleX than non-private apps, being protected from strangers contacting them.

Yes, privacy-focused SimpleX network offers encryption and anonymity — that’s the point. To paint this as problematic solely because of who may use such apps misses the broader, critical context.

SimpleX’s true strength lies in protection of users' metadata, which can reveal sensitive information about who is communicating, when, and how often. SimpleX protocols are designed to minimize metadata collection. For countless people, especially vulnerable groups, these features can be life-saving. Wired article ignores these essential protections, and overlooks the positive aspects of having such a unique design, as noted in the publication which they link to:

“SimpleX also has a significant advantage when it comes to protecting metadata — the information that can reveal who you’re talking to, when, and how often. SimpleX is designed with privacy at its core, minimizing the amount of metadata collected and ensuring that any temporary data necessary for functionality is not retained or linked to identifiable users.”

Both publications referenced by Wired also explore how SimpleX design actually hinders extremist groups from spreading propaganda or building large networks. SimpleX design restricts message visibility and file retention, making it far from ideal for those looking to coordinate large networks. Yet these important qualities are ignored by Wired in favor of fear-mongering about encryption — an argument we've seen before when apps like Signal faced similar treatment. Ironically, Wired just a month earlier encouraged its readers to adopt encrypted messaging apps, making its current stance even more contradictory.

The vilification of apps that offer critically important privacy, anonymity, and encryption must stop. That a small share of users may abuse these tools doesn’t justify broad criticism. Additionally, the lobbying for client-side scanning, which Wired’s article seems to indirectly endorse, is not only dangerous but goes against fundamental principles of free speech and personal security. We strongly oppose the use of private communications for any kind of monitoring, including AI training, which would undermine the very trust encryption is designed to build.

It’s alarming to see Wired not only criticize SimpleX for its strong privacy protections but also subtly blame the European Court of Human Rights for upholding basic human rights by rejecting laws that would force encrypted apps to scan and hand over private messages before encryption. Wired writes:

…European Court of Human Rights decision in February of this year ruled that forcing encrypted messaging apps to provide a backdoor to law enforcement was illegal. This decision undermined the EU’s controversial proposal that would potentially force encrypted messaging apps to scan all user content for identifiers of child sexual abuse material.

This commentary is both inappropriate and misguided — it plays into the hands of anti-privacy lobbyists attempting to criminalize access to private communications. Framing privacy and anonymity as tools for criminals ignores the reality that these protections are essential for millions of legitimate users, from activists to journalists, to ordinary citizens. Client-side scanning can't have any meaningful effect on reducing CSAM distribution, instead resulting in increase of crime and abuse when criminals get access to this data.

We need to correct this narrative. The real danger lies not in protecting communication, but in failing to do so. Privacy apps like SimpleX are crucial, not just for those resisting mass surveillance, but for everyone who values the right to communicate without fear of their conversations being monitored or misused. This is a right we must defend and incorporate into law, as we wrote before.

Wired could have stood on the right side of this battle and helped normalize the demand for privacy, genuinely protecting people from criminals and from the exploitation of the increasingly AI-enabled mass surveillance. Instead they chose the path of spreading fear and uncertainty of encrypted messaging and tools that enable privacy and anonymity.

Spreading misinformation about privacy and security undermines trust in the tools that protect us, making it easier to justify more invasive surveillance measures that chip away at our civil liberties.

Wired did not respond to our request for comment.

SimpleX network: security review of protocols design by Trail of Bits, v6.1 released with better calls and user experience.

Published: Oct 14, 2024

New security audit:

• review findings, our comments and improvements.
• next: security audit in early 2025.

What's new in v6.1:

• better calls.
• better iOS notifications.
• better user experience.

SimpleX cryptographic design review by Trail of Bits

It's been almost two years since Trail of Bits did the first security assessment of SimpleX Chat.

Since then SimpleX Chat grew a lot, both in the number of users and in its functionality. We added XFTP — a protocol for sending files, — and XRCP — the protocol for using a mobile app profile from a desktop app. Messaging protocols also evolved a lot, adding private message routing and quantum resistant encryption.

Trail of Bits reviewed the design of protocols used in SimpleX network and applications in July 2024. Even though there are no critical issues, we made some security improvements based on this report.

Trail of Bits is a US based security and technology consultancy whose clients include big tech companies, governmental agencies and major blockchain projects. Its engineers reviewed the cryptographic design of the protocols used in SimpleX network and applications over a week:

• SimpleX Messaging Protocol (SMP), including a formal verification of currently used message queue negotiation protocol,
• the SMP agent protocol,
• the push notification system,
• the file transfer protocol (XFTP),
• the remote control protocol (XRCP),
• and the chat protocol.

There are 3 medium and 1 low severity findings, all of which require a high difficulty attack to exploit — the attacker would need to have a privileged access to the system, may need to know complex technical details, or must discover other weaknesses to exploit them. Additionally, there are 3 informational findings.

3 of these issues are improved in v6.1, and the remaining issues are accepted. Below we are commenting on these findings in detail, and also on the released improvements.

The full cryptographic design review is available here.

We are very thankful to Trail of Bits and their engineers for their work identifying these issues and helping us make SimpleX Chat more secure.

Review findings, our comments and improvements

Protocols specifications (informational)

The review finding #1 is that the protocols specification is informal. We addressed reported inconsistencies, and we accept that we need to improve specification beyond verbose descriptions and ABNF syntax specification, and add algebraic notations and sequence diagrams. Having said that, the current specification correctly describes the implemented protocol, without any contradictions.

User-correlating attacks via introduced latency or via GET command of messaging protocol (medium and low severity)

These two findings #7 and #2 of the report relate to the attacks confirming that two known users communicate via observing their internet traffic.

The first attack is possible for a party that can introduce the latency in the network traffic. This attacker has to control some network node that passes the traffic of the sender — for example, it could be the sender's ISP, VPN provider, Tor entry node operator, the operator of the forwarding SMP server or a server hosting provider, etc. Such attacker can correlate delays in sender's traffic and the suspected recipient's traffic to confirm that they communicate.

The second attack relates to GET command used by iOS clients receiving notifications — depending on whether the server has the message, there will be a different number of packets sent, allowing the observer to determine if there was the message. While this comment is correct, in practice iOS clients only send GET commands when they receive notification, which also happens only when there is a message on the server, so in absolute majority of cases the number of packets will be the same.

These are not new findings — this type of attacks is covered in threat model: a passive adversary able to monitor a set of senders and recipients can perform traffic correlation attacks against senders and recipients and correlate senders and recipients within the monitored set, frustrated by the number of users on the servers.

As threat model states, this attack is more likely to be successful with the less busy servers, and also for the users with few connections.

The recommendation of the review is to add optional randomized latency to message delivery that would reduce the opportunities for traffic correlation attacks — we consider adding it in the future.

A compromised transport protocol allows more efficient correlation attacks (medium severity)

The finding #3 is about the incorrect statement in threat model for SMP and XFTP protocols: a passive adversary, able to monitor a set of senders and recipients, cannot, even in case of a compromised transport protocol perform traffic correlation attacks with any increase in efficiency over a non-compromised transport protocol.

For protocols prior to v6.1 it is only partially correct, as responses to the commands that create a messaging queue or a file chunk include the identifiers both for senders and for the recipients, so if any observers were to compromise transport protocol (TLS) and record these identifiers, then they were able to correlate message senders with the recipients (and file recipients with the file senders).

The solution to make this correlation impossible even in case of compromised TLS is to encrypt these identifiers, as proposed in the review, or, better, encrypt the whole transmission inside TLS.

However unlikely is TLS being compromised, we added additional transport encryption layer in SMP protocol, where it can be more important, and we are going to add the same layer of encryption in XFTP protocol later, where we amended the threat model.

XRCP protocol recommendations (informational)

XRCP protocol is used for connecting desktop and mobile. There are two findings in the review:

• SHA256 was used as a KDF in XRCP (#4).
• there was no forward secrecy or break-in recovery between sessions (#5).

SHA256 is now replaced with SHA3-256, as was recommended by the internet draft about hybrid key agreement that XRCP uses.

Even though XRCP sessions are short lived, and usually the connection happens over local network, we added forward secrecy to XRCP sessions here and here — each request from desktop app to mobile app is now encrypted with a new key derived from chain ratchets. This improves security of this connection.

We believe that it is unnecessary to have in-session break-in recovery in XRCP protocol, as there is break-in recovery between the sessions.

Device compromise can be hidden in some scenarios (medium)

The finding #6 in the report is about an attacker who was not only able to break into the device and get a copy of the database, which would be mitigated by break-in recovery in double ratchet protocol, but also was able to modify the state of the app database and to substitute the addresses and cryptographic keys of the messaging queues used with some contact with other message queues that the attacker controls.

Even though this is a very hard attack, if successful, it would allow the attacker intercepting all messages with this contact.

Effectively, it is a man-in-the-middle attack, where an intermediary is inserted via the app database modification. Such attack can be mitigated by periodic verification of security codes. Although, the attacker who was able to modify the state of the device, could have also modified the app itself, making it show the same security code as the compromised contact has, thus avoiding detection.

We accept that such an attack is possible, and we don't believe there is any viable defense against the attacker who can modify the device state. We may consider adding the measures to validate the database integrity, but they may be ineffective in case the app and/or operating system are compromised.

Next: security audit in 2025

We are planning the implementation security assessment with Trail of Bits in the beginning of 2025. It will be a twice bigger assessment than we did in 2022 — it will cover both the core of the app and the handling of cryptographic secrets in the mobile applications.

What's new in v6.1

This release has many user experience and stability improvements.

Better calls

This release improves reliability and usability of the calls. Now you can enable the camera and share the screen from the desktop app even if the call started as a voice call. We've also fixed several issues that prevented calls from connecting.

This is a substantial change, and some issues may have been introduced - please report them.

We will be further improving the calls interface in the app in the next versions.

Better iOS notifications

iOS notifications were added more than 2 years ago, based on this system design. Until recently we made almost no improvements to them. As the number of iOS users is growing, their reliability is insufficient. In addition to that, once we started the work on improving them, we have found several important issues, one of which was introduced recently, when we improved the speed of creating new connections.

This release fixes many important issues with iOS notifications delivery in iOS app, improves app performance and reduces traffic required to manage notifications.

We also fixed several notification server issues, made change that almost completely prevents losing notifications when notification servers are restarted, and added real-time monitoring to diagnose any issues with iOS notifications delivery.

This work is not over – iOS notifications in a decentralized network are complex and require more work. We will be further improving both client apps and servers to make their delivery stable.

Better user experience

New conversation layout and customizable messages

Messages are now grouped when they are sent sequentially, with less than 60 seconds between them. We also made message shapes configurable, and separated the messages in different days. When you scroll conversation quickly, there will be a floating date indication, allowing to find messages faster.

Improved switching between user profiles

Another improvement relates to switching between chat profiles. Previously, when you added multiple chat profiles to the app, there were two problems:

• you had to tap twice to get to some important functions in the app,
• anybody who could see your screen, could also see all your chat profiles.

We changed this design by making important functions available after tapping profile image once, and by only showing the previously used profile image to switch to it quickly, while switching to other profiles now requires scrolling to them or opening Your chat profiles screen.

You also can switch chat profile when creating a one-time invitation link.

Faster deletion, moderation and forwarding of messages

You now can forward multiple messages at once - up to 20. If you are forwarding messages with files or media, and they were not received, the app will offer you to download them, and it will also allow forwarding messages without files. These messages will be "packed" into the smallest number of sent messages as possible. If there are no images and messages are not too large, it will be just one sent message containing all forwarded messages.

The previous version allowed deleting and moderating multiple messages. As most users now upgraded the app, we increased the maximum number of messages that can be deleted or moderated to 200 messages - in most cases all these deletions will be packed into one sent message.

SimpleX network

Some links to answer the most common questions:

How can SimpleX deliver messages without user identifiers.

What are the risks to have identifiers assigned to the users.

Technical details and limitations.

Frequently asked questions.

Please also see our website.

Please support us with your donations

Huge thank you to everybody who donated to SimpleX Chat!

Prioritizing users privacy and security, and also raising the investment, would have been impossible without your support and donations.

Also, funding the work to transition the protocols to non-profit governance model would not have been possible without the donations we received from the users.

Our pledge to our users is that SimpleX protocols are and will remain open, and in public domain, so anybody can build the future implementations of the clients and the servers. We are building SimpleX platform based on the same principles as email and web, but much more private and secure.

Your donations help us raise more funds — any amount, even the price of the cup of coffee, makes a big difference for us.

See this section for the ways to donate.

Thank you,

Evgeny

SimpleX Chat founder