Encryption, Error451, Surveillance, Technology, Transcribed, United States

Signal Contingency Plan (Delta Chat with Fanny and Mary)

Delta Chat logo featuring a lower case Greek delta in a speech bubble
Download The Episode

This week, an interview we did with a couple of smart friends about the question: what would those of us who rely on Signal encrypted messaging do if that service were disabled in the US. First up, all participants in this discussion agree that Signal is amazing and always getting better, so this is not a take down of that app or it’s developers. But the buds do think that the weakest point for Signal is the centralization of infrastructure with US-based companies. My friends did some thinking and research and put it into a website called Signal-Contingency-Plan.Info and made a zine discussing it and what they consider the best alternative for their needs an app called Delta Chat.

  • Transcript
  • PDF (Unimposed) – pending
  • Zine (Imposed PDF) – pending

So, for this discussion, they’ll talk about how encrypted apps work, what works so great about Signal, some ups and downs of other available encrypted chat apps and how folks might rebound if Signal got choked out in this manner. As a reminder, at the end of 2024 large parts of the region I’m in lost cellular and internet service and it came back in starts and staggers over a number of months, similar for running and potable water, roads and other infrastructure we rely on. Our hope in sharing this conversation is that people will consider threat modeling to develop social plans for contingency and alternatives for the infrastructures they rely on.

Delta Chat & having a backup for Signal:

Some reporting mentioned:

. … . ..

Featured Track:

  • Creep (Instrumental) by TLC
  • Sad React by Emperor X from Sad React _ United Earth League of Quarantine Aerobatics

. … . ..

Transcription

TFSR: Could you please introduce yourselves however you’d like and say a little bit about your background with technology?

Fanny: Yeah, sure thing. I’m Fanny. It started with graphing calculator programming in middle school for me, which is pretty classic for people my age. I got into Linux and open source software in college. I got into running community tech infrastructure a little later, through helping a local project with their website. I ended up going into a career in tech doing infrastructure, and I eventually decided to leave corporate tech forever—hopefully—during this current AI era. I’ve continued to do community tech infrastructure since then.

Mary: I’m Mary. I’m more of a Luddite who got into programming through spreadsheets, which naturally led to the LISP family of languages and open source software. I’ve done software development in corporate tech as well and also left in the AI era. I’ve been doing community tech infrastructure and cosplaying as a sysadmin since then.

TFSR: Sounds like really fun cosplaying.

Mary: Yeah, it is.

TFSR: So we’re here to speak about the website Signal Contingency Plan. First things first, what is your problem with Signal encrypted messenger?

Fanny: We don’t have a problem with Signal. Sorry. Mary?

Mary: Yeah, Signal is great. Everyone should use it if you’re not using it. The encryption is good. We’re already on Signal. Thank you for the leading question.

TFSR: (Laughs)

Mary: But you know, Signal is a messaging tool. Like most tools, there are strengths and drawbacks. Some of the drawbacks of Signal are its centralization, which in this case means that it’s easier for a state actor to block access to Signal. In addition to that, the Signal Foundation is a legal entity based in the US jurisdiction. And it runs on infrastructure that is owned by US companies, most of which have a track record of complicity with the current nascent fascist project. So no problem with Signal, but we are considering a kind of disaster-preparedness framework for “What if Signal is blocked?”

Fanny: Yeah.

TFSR: Okay, good. Because I saw this article in The Guardian that says the FBI spied on a Signal group chat of immigration activists, as records reveal for this court watch group. But my understanding is that the issue wasn’t that Signal was compromised. It was that an FBI agent got added to the group chat.

Fanny: This is pretty much always the situation whenever there’s a news article about like, “so-and-so spies on Signal users!” It’s that a fed was in the group chat. Signal can’t really protect against that.

TFSR: If there was a patch that got rid of feds, maybe we would be able to move beyond this problem.

Fanny: Yes, that’d be a great patch.

TFSR: You mentioned it getting blocked in the US. How could that happen? And why would it be? Hasn’t there been media coverage of Signal security being so good that even government employees use it while they decry the public’s ability to encrypt messages and then have them disappear?

Fanny: Yeah, totally. I’m going to talk about the blocking mechanisms in the US and then I think Mary might maybe expand a little bit more on that usage of Signal by the US government. But first, I want to say we wrote a zine about this. There’s a link to the zine on the website, signal-contingency-plan.info. You should definitely check that out.

At a high level, Signal could get blocked in the US by the US government forcing Signal’s providers to turn it off. This is different than what has happened with previous blocks by other states in the past. So in the past, typically when Signal has been blocked, it’s been by a state that physically controls the internet. Two good examples are Iran and China, where I think that Signal is still blocked today. In both of these countries, outgoing internet connections… anyone sending or trying to connect to something outside of that country, their network connection must go through hardware that the government physically controls. So they can just turn off connections to Signal themselves. They don’t have to ask an intermediary to do it. They have unilateral ability to censor in that way.

This is really different than the situation in the US. The US government can’t just unilaterally turn off individual people’s network connections as they leave the country. They just don’t have that physical control of the medium of the internet. What we explore more in the zine is how could or would it look for Signal to get blocked in the US? Because it would be through legal means. Signal, like pretty much all like world-scale apps, (especially apps that like have real-time communication as part of what people use them for,) uses Google Cloud and Amazon Cloud and Microsoft Cloud to run its servers. This is because those tech giants are really the only companies that have enough compute power to be able to run an app that is the scale of the entire world. Not only, like Mary said previously, is the Signal Foundation itself based in the US, and this means that, you know… the USDOJ could just come after the Signal Foundation directly. But also, all of the companies that own the computers that Signal runs on are based in the US. The USDOJ can come after them.

Signal also relies on CloudFlare, another tech giant that’s a little bit lesser known by people outside of tech. Signal relies on Cloudflare for doing DNS resolution, for making Signal.org work, and Cloudflare runs the .gov TLD. Cloudflare is super embedded with the US government. The US government could just ask them to turn off Signal.org. The vulnerability that Signal has to getting blocked in the US is about the US government coming after the US-based companies that Signal relies on to run its infrastructure. Or coming after the Signal Foundation itself. Sorry, that was kind of a lot. If you have any follow-up questions, please chime in.

TFSR: No, that makes sense. These are a lot of the same tech giants that have been attending fundraisers for the destruction and rebuilding of the East Wing into a ballroom. And attending the Trump administration… taking the knee to the current administration in a lot of instances, right?

Mary: Literally.

TFSR: Or throwing money at it. Even if there wasn’t an ax over them saying, “you need to shut this off,” they might just do it on their own?

Fanny: That’s interesting. We’ve really tried not to speculate too much, but it feels to me like that is possible. We sat down and we were basically like, “can Signal get blocked? We don’t actually know. Let’s try to figure out whether or not it’s possible.” And our conclusion was, yes, it definitely is. How likely is it? No idea. The question of how likely it is feels like a much more squishy political question. We are technologists. That’s not our specialization. We just wanted to answer the question of like, “it’s been blocked in China, could it happen in the US?” We concluded yes, but through very different means. Don’t know how likely it is, but I mean, feels possible to me.

Mary: It’s worth saying for completeness that Signal does have strategies that it uses in places where it is blocked. Folks might be familiar with Signal proxies, which are servers that people like antifascist technologists can run to help get around some of the ways that Signal is blocked in other places. It’s hard to know exactly how Signal might be blocked. We simply know that it is the case. Even if we could reestablish connection to Signal’s network, there would be some lag time depending on how that block occurred, or which lever the admin used.

TFSR: Mary, do you want to talk about how, well, “Doesn’t the government use this resource? Would it be in their interest to do such a thing?”

Mary: Absolutely. There’s some good news and bad news here. I do think this points against a proactive block by some of Signal’s service providers, because members of the US government do use Signal. The US security state does recommend Signal for both government employees and private citizens, for many different specific use cases. As an aside, this has been the source of some kind of bad-faith criticism of Signal, as this is a project that’s received the feds’ stamp of approval or what have you. But I think some of the reporting that we saw around the summer can provide some insight into what’s going on here.

Listeners might remember something that was called the Signal clone being hacked after a reporter got a photo of a member of the Trump admins unlocked phone. I love 404 Media’s reporting, but I think that terminology of Signal clone is a little bit misleading. What was being used and what is used by many members of the government is actually a clone of the front-end application. Signal’s back-end servers are still being used by government employees. But there is this company called TeleMessage that runs a copy of Signal’s front-end app, which is open source. They add additional code that takes unencrypted messages on the device of the government employee and sends those unencrypted messages to a server controlled by TeleMessage. This only works because they’re using Signal’s front-end code. If you’re familiar with the concept of “a man in the middle,” this is kind of like man in the middle as a service. The reason they do this is to comply with public records legislation.

Even though they’re government members who are using Signal, they have to circumvent Signal’s encryption in some way when they choose to abide by that public records legislation. Of course, when they don’t want that, when they want to hide their communications from scrutiny, they simply use the normal Signal front-end app and invite random editors from The Atlantic into their group chats.

TFSR: As you do.

Mary: Yeah, as you do. Whomst among us?

The lesson here is that Signal is valuable for members of the US government, but when they are incentivized to evade scrutiny, they can use other tools. They can use Signal’s front-end app without that TeleMessage, man-in-the-middle thing going on, or they can use other encrypted apps. Signal is in the place that it is partly on the strength of its encryption, but also partly on its feature set and its familiarity. Just as we can choose to use other encrypted tools to evade repression, state actors can use other encrypted tools to evade scrutiny.

TFSR: So then it’s not that the US government is operating or having a company, on their behalf, running a fork of Signal back-end or the full stack. It’s just this front-end archiving process, and then it gets sent through the encrypted messaging at the back-end so it gets the public records, right? If Signal did go down, they wouldn’t have access to that back-end. Am I understanding that right?

Fanny: Exactly. We kind of had to dig a little bit to figure out exactly what was going on with this “Signal clone” that was so widely reported at the time. But the version of it that they were using, if the Signal back-end went down, then it wouldn’t work anymore.

TFSR: I understand that there’s a lot of infrastructure in, as you put it, running the back-end of it. This is why it has to be spread across these huge tech-giant companies. Since it is an app that gets audited frequently, or it has been audited, the code for it is out there. Some iterations of the code are out there. Could someone—if they had the infrastructure—actually host a fork of Signal, as far as you understand?

Fanny; Yeah, so we looked into this some too. The answer is, theoretically yes. Like, literally yes, that is possible. Practically, I could not find anyone who has written online publicly in the last five or more years about successfully running the Signal back-end infrastructure themselves—with maybe the exception of running it locally on their personal development machine to run tests against it. The open source code for both the client and the server has tests and so. Unlike something like Delta Chat or something like an XMPP server, Signal the organization does not release a clear guide for how to run the Signal back-end “in production.” So like, running your own alternative Signal instance is not something that has been done. It’s theoretically possible. Notably, I think that if the US government decided that they wanted to do that for themselves, they could figure it out. Because they have the time and resources. We, just regular technologists, do not have the time and resources to figure out how to do that, especially when other stuff that works right now exists.

TFSR: What is this contingency plan that I’ve heard so much about?

Fanny: I originally came up with the term “contingency plan.” It was just what I named this website when I originally wanted to start promoting the idea of having everyone prepare for a Signal block. I kind of regret the choice of ‘contingency plan’. Maybe I’ve just seen the phrase so much now that it doesn’t mean anything to me anymore. But point being, the contingency plan that we are promoting is: get set up on Delta Chat, which is an encrypted chat alternative to Signal. Get set up on it beforehand, get connected with friends right now and continue using Signal. Delta Chat is the contingency.

TFSR: What is Delta Chat?

Mary: Delta Chat is an application that uses the ChatMail protocol to send encrypted messages via email as a transport layer. The choice of email is really interesting, and we’ll get into some of the details about that. But from the user perspective, it’s worth kind of putting that to the side for the moment. Because the way most email works is really not applicable to the way that Delta Chat is built on top of this ChatMail protocol.

TFSR: Obviously, email has been out there for a while. It’s been said that the proposal here is not for everyone to jump ship on Signal. But why do you consider Delta Chat to be a nice alternative, or a nice backup plan?

Mary: As we’ve explored other means of communication for a possible Signal block, all of the contingency chat apps we’ve looked at we’ve decided have to have some properties. Some of them are really concrete and easy to say yes or no on. Encryption must be provably secure. It must be audited, and it must not break. And as kind of a corollary to that it must be audited and it must be open source too, so that audits can occur that are public.

The app must be resilient to the types of repression that Signal is vulnerable to. So we’re thinking about, you know, what if Signal gets blocked? If the same strategy that’s used to block Signal can be used to block our contingency application, then our contingency application is not a great contingency, because it can go down very quickly immediately after Signal does. That one’s a little bit squishier.

Then we get to things like being able to onboard people who are already comfortable using Signal and having a really simple user experience. These things are a little bit harder to determine, but Fanny and I have run some of these applications. We’re kind of using our own experience to guide some of our judgment there. So the short answer, I guess, is Delta Chat has provable, audited encryption, it’s open source, and it’s decentralized in a way that Signal is not. And it’s really easy to use.

TFSR: Yeah, so we talked about that weak point of Signal as one example of an encrypted communications platform. The centralization could be a weak point to it. My understanding, too, is that that’s been… we know at least Moxie, or probably the [Signal] Foundation afterwards, were against the idea that… Maybe this is getting into weeds that we don’t need to and maybe kind of a side conversation, but like, you couldn’t go into F-Droid and download an APK of Signal. They wanted to keep it on the app store, specifically in order to have that certification stamp that “This comes from us. This is trackable.” Like there’s—

Mary: Chain of custody, yeah.

TFSR: You mentioned that Delta Chat has a decentralized nature. Can you talk a little bit about that? Like, what it takes to host it, what sort of infrastructure there is, and what trust there is around a self-hosted instance—I guess if I can call it that—actually being trustworthy?

Fanny: Yeah, totally. I can talk about that some, and then Mary, please feel free to chime in at any point.

We have hosted a Delta Chat backend server before. This is where I think talking about email… The fact that Delta Chat uses email to send messages, despite the fact that those emails are transparent to you, it literally just feels like WhatsApp when you’re using Delta Chat. You don’t have to think about the email part in the same way that you don’t have to think about the encryption. But the fact that it uses email is key to how the decentralization works. Because think about if Person A has a Gmail address, and Person B has a Yahoo email address, and Person C has a has an Outlook email address, and they’re all in an email chain together. The way that those emails are going around is like Google’s mail servers and Yahoo’s mail servers and Microsoft’s mail servers are all speaking with standardized email protocol to each other. It is decentralized.

So Delta Chat was like, “Okay, everyone wants to have a decentralized chat app. Doing decentralization is hard. What if we actually just chose an already existing, super-established thing that was decentralized, like email—which is like, arguably one of the biggest, most widely used decentralized things—and we just used that to send our messages around? Then we wouldn’t have to spend all this engineering effort of our own to figure out how to do decentralization, because the thing we’ve chosen to send messages already is built to do decentralization effectively.” That is one way that email is important.

So your question was specifically about how does decentralization work? And also some about running a server and knowing that servers are trustworthy. Anyone who’s a Linux person—or like a Linux sysadmin type person—knows that if you’re running a Linux server, it’s really, really trivial to install an email server on it and make it send emails. On the other hand, it’s really hard to make other email servers accept those emails. But that’s a separate conversation about the email mafia that we won’t get into. So it’s trivial to put an email server on your Linux server. What Delta Chat is really—what the Delta Chat back-end servers are really—is a large set of scripts that take a regular Linux server and install a bunch of regular email tools on it. Plus a pretty small amount of like ChatMail, Delta Chat specific tools that do the encryption and stuff like that, account management. They turn what is otherwise a regular Linux email server into a—ChatMail is the name of the back-end server. I’m sorry, this probably pretty confusing for someone who isn’t thinking about the differentiation between the client, Delta Chat, and the back-end server, ChatMail.

Those groups just turn a regular Linux email server into a Delta Chat specific email server that encrypts everything. It can’t send out messages that are unencrypted and is configured specifically to send and receive messages as fast as possible, so that there’s not lag when you’re texting someone. In terms of, how do we know to trust a given back-end server? The short answer is, you can’t. But the longer answer is, this is why end-to-end encryption is table stakes for secure communication. Even if you have downloaded the Delta Chat app on your phone from a trustworthy source (which is very easy to do) then even if you have accidentally created an account on a malicious back-end server, that malicious back-end server can’t do anything with the contents of your messages because they’re encrypted and the server can’t decrypt them. The hostile entity running the malicious server can’t decrypt them.

I mean, this is kind of true for Signal also, right? So the Signal front-end app is built such that it is possible for people to extract the APK or the app that’s installed on their phone, take that app and run it through code that Signal has written and prove that the app they have been given from the app store is the same app that is there, published on GitHub. You can verify that yourself. This makes it so that we don’t have to care whether or not Signal has been “backdoored” on the back-end servers. Because if it were, you know that you’re running an app that is not releasing any data that it shouldn’t be. Even to a malicious back-end server.

TFSR: I mean, is email secure? Long time listeners to the show might remember that we’ve done conversations in the past with people that were trying to create and promote easier implementations of PGP, which is an encryption algorithm, I guess, or application for email. Pretty Good Protection. That’s been around for a while.

But I have a couple questions about email as a safe communication method. My understanding is that at the beginning of an email message, it includes information, metadata basically, headers that say, “Okay, here’s who’s sending this. Here’s who it’s intended for. Here’s the time that it’s been sent. Here’s the subject of it. Here’s the size of the message.” This sort of information. Is that a problem with Delta Chat? If they’re just using email as the method for this communication between the apps. I guess if you could talk about PGP a little bit, and if this application of PGP, if that’s what’s running under Delta Chat, could possibly fall to the EFAIL situation.

Mary: I love this. I love talking about this. First things first. I guess email in general is not secure. Even encrypted email applications are subject to a lot of failures because of the plain text transport nature of email. So I’m not going to recommend sending anything in a normal email app, even an encrypted Proton or Tuta, or using those for sensitive communications. Even a lot of security researchers and cryptographers would recommend against using PGP in general, just because it is such a large protocol that tries to do a lot of things. In the case of Delta Chat, there’s a pretty strict subset of PGP that is being run inside of Delta Chat, and so you as a user—you don’t think about it, you don’t touch it. This subset has been audited independently, and the encryption stands up. It’s the kinds of user failures—things like GPG, which is one of the implementations of the PGP protocol —the kinds of user failures that we see leaking information don’t really apply to this strict subset of PGP. Hopefully that answers that part.

The metadata question… I’ve got a lot to say about this. I think it’s really important to talk about. So please interrupt me at any moment, but there is absolutely unencrypted, just plain-text metadata that gets sent as part of usage of Delta Chat. I want to be really clear about that and talk about what that means, so that we can threat model around it. Because we still recommend using Delta Chat. The plain text information that gets sent with every message are the email addresses of the message sender and receiver, as well as the time sent. These are unencrypted in transit and also at rest on the back-end server of the recipient.

So let’s talk about the email addresses. I guess, to begin with, they’re not chosen by users. When you sign up for a new Delta Chat profile, your email address is automatically generated on the back-end server that you create that profile on. It is entirely possible to use Delta Chat and have no idea what your email address is. It’s a random string of characters. So the threat model we want to think about in terms of this plain-text email address situation is that of a state actor or other malicious actor being able to obtain a social graph of users that are communicating with a particular user or a particular back-end server—which is theoretically possible through constant monitoring of network traffic or the seizure of a server. A state actor would still need to access an unlocked device in order to start associating real identities with anyone in that social graph.

One of the tools we have to mitigate this social graph risk—that is not unique to Delta Chat, it’s present in some of the other applications we’ve considered—is the easy creation of additional profiles and a design that makes the experience of managing multiple profiles very painless. In the zine we wrote, we have instructions for how to best do this to avoid connecting your profiles together. As far as the plain-text metadata existing on a server—when someone runs a ChatMail back-end server, that metadata is available to the person running it or anyone who has seized it. But there are some great defaults that kind of help mitigate this. If you have a single device profile, the back-end server is instructed to delete messages once they’ve been received by your device. So if someone seizes that back-end server, they can only see the metadata of messages that your device has not yet received.

Multi-device profiles are a little different, because the back-end server doesn’t store anything about the devices that are associated with an account. So it’s just waiting. It’s storing that message for twenty days. Anytime a device authenticates to that back-end server, they request all of the undelivered messages, and they’re sent. Once that twenty-day period elapses, those messages are deleted. There is a little bit of risk here with some of that metadata existing for that period of time.

TFSR: Just to clarify again. When you’re referring to multi-device, it’s like the difference between… if you have only one device connected to a Delta Chat and you’re communicating, once those are received by that one device, the server knows to delete those off the server immediately. But if you’ve got it installed on, say, one phone and four computers, or something like that—then it holds it for 20 days. After 20 days is up then it deletes those, whether or not all the devices have downloaded the contents of those undelivered messages, right?

Mary: That’s right. That multi-device thing, from the perspective of this back-end server, that’s just a yes or no, basically. Because that back-end server, like I said, has no information associated with the device IDs or anything related to someone’s phone or computer or anything. It’s just a flag that gets set. If it’s a single device account, the flag says: once something has requested these messages, delete them.

TFSR: Just to go back, with the PGP discussion, one thing that I caught was a reference to user error. As I understand, that’s a lot of the possibility for failure with PGP—user error or implementation. Sorry if you said this already, there’s a lot of information in there. But how does Delta Chat deal with that possibility of user error with the PGP or the app itself not implementing that correctly?

Mary: Yeah, thanks. The encryption that’s used by Delta Chat is a subset of PGP that is running. Fanny mentioned all of the scripting. This whole project is a bunch of standard tools that are used by various Linux servers. It is a subset of PGP that is running inside of Delta Chat that does not offer any ability for the user to change how that encryption is being handled. All of the public key exchange is happening via QR codes or links that are similar to magic links. So there’s really nowhere for a user to mess with those defaults. And this subset of PGP that has been implemented here, it has also been audited independently and survived multiple audits.

Fanny: And if you don’t mind, Mary, maybe I’ll expand a little bit on the meta around this. This choice to use PGP but remove all user input from the use of PGP is reflective of… I want to be clear, I’m speaking not as a cryptographer here. I am not a cryptographer. I am trying to make a best effort to summarize what has happened within cryptography with regard to this specific question. The difference between this version of PGP, the subset of PGP that Delta Chat uses, and the version of GPG that some of us have used to manually encrypt our own emails in the past reflects this change in cryptographers’ attitudes about how to do cryptography safely. GPG is like a Swiss army knife that lets you choose your keys and make different kinds of keys. Oh, I want to make it weaker, so I’m going to do this, or, oh, I want to make it stronger, so I’m going to give it this flag. Fast forward to today, because that program is pretty old and started a long time ago. Cryptographers now are like, you got to get rid of the user input. Users make mistakes. You need to have these really trim encryption tools that only have secure defaults, and there is, there is no way to tell it to behave in an insecure way. So this subset of PGP—I want to be clear, it is not GPG. It is a different program. I’m pretty sure it’s written in Rust—that only does the specific part of PGP that Delta Chat needs. It just generates keys and it does encryption. It does not accept user input to do that. That is reflective of this change in cryptographers’ understandings of how to implement cryptography securely in the actual tools that users touch.

Mary: It is implemented in Rust. I don’t know if we need to talk too much about that, though.

TFSR: Okay, so what if the government blocks Port 465?

Fanny: Googling. No, I’m not googling! I’m not googling! I’m doing an internet search on Port 465.

Mary: The Internet breaks.

Fanny: Yeah, yeah.

TFSR: I think I was expecting an answer like the one that she just gave.

Fanny: You can’t block Port 465 because exactly as Mary said, the Internet breaks. This is part of what’s really cool about Delta Chat choosing to use email as a transport protocol—which, it wasn’t designed to be a transport protocol, or a transport layer I mean. Like, you can’t block Delta Chat on a whole network without blocking all email on a network. You can block individual Delta Chat back-end servers, but you can’t simply block all of Delta Chat. Because it’s indistinguishable from regular email. And as soon as regular email stops working, every corporation falls apart, the government stops working. This is how everyone talks to each other, especially in these sort of corporate and government contexts, so that particular mode of blocking is just really not available.

TFSR: Cool, it sounds like a neat app, but there’s a lot of encrypted apps. There’s an acronym that I have not fully integrated into my vocabulary at this point. That’s PACE—around communication contingencies or backups.

Mary: Primary, alternate, contingency, emergency.

TFSR: Yeah, that is it. Why Delta Chat, an obscure and a not really well-known app as an alternative? When you’ve got so many things like Telegram and WhatsApp or Cwtch or Wire? There’s a lot of different options out there. Element. And what about Snikket? Why not some of those? If you want to talk about some specific examples that come up for you as to why not those?

Fanny: Yeah. We made an effort to sit down and actually write down some of our thoughts about basically every alternative we can think of. Just to test our belief that Delta Chat is this good contingency for Signal in this specific use case. Our assessment of Delta Chat stood after doing this. So some of the most popular things that people discuss as backups or alternatives to Signal… They are close, but they didn’t meet one or multiple of our specific stipulations for an app that will function as a good contingency in the specific scenario where Signal has been blocked by the US government.

Let me talk about some. A lot of people know Element, also called Matrix. Element is just the most popular client for it. Element is great, but in our opinion, it is too hard to onboard, and the UX is too confusing for a lot of users. It also is more like Slack or Discord than Signal, and that means that it can do a lot of things that Signal can’t do, and we’re looking for a Signal replacement. Replacing with something more complicated is not ideal. Ton of people know Telegram. Telegram is like a non-starter for us, the back-end is closed source. Also, not all Telegram chats are encrypted. It is possible to encrypt chats, but they are not necessarily encrypted. That’s unacceptable. That’s a non-starter for us.

We did some research about something called SimpleX, which I had heard of before, but had never really tried. SimpleX is probably a different good Signal backup. We ultimately think that Delta Chat is better because Delta Chats infrastructure is simpler. It is simpler to run our own servers in a scenario where hostile actors are blocking back-end servers across the network. Also just some vibes… I think the political culture around SimpleX is not my favorite. The one around Delta Chat is much more aligned with what I want to see around a secure chat app. Yeah, those are the big ones for me. Mary, you want to pick it up?

Mary: In kind of a similar vein, WhatsApp is an app that actually uses the Signal protocol, which is great. I’m sure that many of us will be using it in the event of a Signal outage. It is still centralized. It is closed source, and it does leak more metadata than Signal. Some of that metadata is personally identifiable information, namely phone numbers. So while we do expect that people will likely use WhatsApp in an emergency, we didn’t want to recommend it because it has some of the same centralization weaknesses that Signal does, in addition to others. There’s also XMPP servers with different kinds of encryption, including off-the-record or OTR, which doesn’t support group chats, or with OMIMO, which does. There is a new project called Snikket, a relatively new project that I think we’re both excited about. It currently doesn’t allow for open sign up and occasionally suffers from broken encryption in group chats—which just effectively bricks a group chat. You can no longer send messages. It’s pretty catastrophic. I don’t know. Session seems to be pretty feature complete and with decent encryption but is so focused on blockchain that it feels like a Web 3.0 project with an encrypted chat app bolted onto it.

Oh, there’s also Briar, which is one I think that you asked directly about, which is cool and has a proven history of definitely evading blocks by India—possibly other blocks, but that’s the only one I know of. But unfortunately, it doesn’t have an iOS app. We do think that having an app for the major mobile platforms is pretty important. I think that’s the majority of the ones that are real serious contenders.

TFSR: Also, there’s a history of the owners of or the main person behind Telegram handing over information to certain states, I believe Iran and Russia being two. WhatsApp is owned by Meta, so that’s a pretty untrustworthy chat application there for that reason. Mentioning Briar… Briar is one that I was pretty excited about at one point. There was a cool discussion on From Embers podcast—which is a Channel Zero Network member—about different chat apps that would be of interest to anarchists. A few years ago, they mentioned Briar. Briar has this cool opportunity or option to be able to act like a mesh relay setup, using Bluetooth and WiFi—I mean, Bluetooth runs off WiFi anyway—so that if communications grids are not safe or go down, then you could communicate messages between devices without cell or WiFi being available. That’s too bad that they haven’t had the opportunity to release something on iOS. Your point is taken. I think that Bitchat is one that is an app that recently Jack Dorsey, one of the founders of Twitter, has been backing. They also have that sort of lateral communications technology built into it. I don’t know if that’s a thing that’s interesting, or if you have any critiques of that.

Fanny; Yeah, all the chat apps that use Bluetooth or local WiFi to do local message transmission are so cool. I want to live in a world where we’re all using an end-to-end encrypted chat app where that’s how messages get around. I totally believe it’s possible, but the current state of those apps that is available is such that Mary and I don’t think that any of them are appropriate for this specific Signal contingency use case. Briar seems really cool. I haven’t used it. Cwtch also seems really cool. I haven’t used it, but Cwtch also doesn’t have an iOS app. I think that’s the deal with it.

Mary: Yeah, that’s correct.

Fanny: And then, Bitchat. I actually hadn’t heard of Bitchat, but I might’ve read about it. It potentially seems really cool. The technical issue that I have with Bitchat is that there’s a giant warning on the main Bitchat page that says “Private messages have not received external security review. Don’t use for sensitive use cases.” So that’s a pretty clear disqualifying for this specific use case, but I could imagine a future where it’s cool.

Ok, now my non-technical issue with Bitchat is that Bitchat has two modes. One of them is local Bluetooth (maybe WiFi also) but local message transmission without the internet as an intermediary. The other mode is the internet is an intermediary. In that mode, it uses a decentralized protocol called Nostr—I may not be saying that right—to transmit messages. There is a really big social media platform built on Nostr which I think is also called Nostr, but I’m not 100% sure. This is my non-technical issue: that social media platform is a Nazi bar. Obviously this is not a thing that the protocol did, but it is not my favorite. But I could imagine a world where Bitchat has gotten past the lack of private message security review, and it actually becomes a contender for something like this.

TFSR: With what I said about WhatsApp and Telegram and the ownership structure—or what they’ve done in terms of state actors and keeping the data safe of their users in the past. Do you have any similar concerns about the developers behind Delta Chat? Are they known quantities? What sort of trust should we have in those folks? I mean, they’re not venture capitalists, I imagine.

Fanny: No, they’re not. Yeah, they are known. For me, this is one of the comfiest elements of the whole Delta Chat package. I mean, Delta Chat obviously accepts contributions from people outside of the core group, but the core group is an explicitly leftist group. They have been participants in German DIY hackerspace-type communities. Think CCC, think just the historical free software community in Germany. They’ve been in those spaces and participating in those spaces for years. In particular, the person who’s more or less at the head of Delta Chat.

So they’re known by many, trusted by many. They give presentations. They’re highly available. They respond to your questions in the forum. They will answer questions you ask them on Mastodon. They’re part of our trusted community of people. They don’t have any unique ability to hand over user data that any other server operator doesn’t have the ability to do. They do run the default Delta Chat backend server. And so just by the sheer fact of that being the default server, it has more user data on it than other servers.

I guess in that sense, they have an uneven ability to potentially be forced to hand over user data. But that server is based in Germany. I think the capacity for the US state to force them to do things is lower than it would be if they were based here.

Mary: It’s worth saying also that Delta Chat is obscure in the US context. But it’s not quite as obscure in the EU context, where all of the development happens, and where Signal usage is not as ubiquitous. So there are a lot of people like relying on Delta Chat on a day-to-day basis as well.

Fanny: So the US, or at least our context, it’s… you can buy as many SIM cards as you want to, and they don’t have to be registered to someone’s legal name or address or anything like that. That being the fixed point for identities for Signal makes it difficult for people living in places where you do have to register your SIM cards to be able to have them get activated. It makes it a little less pretty for people to be using Signal for privacy reasons, or for disconnecting your legal identity from the identity that you’re chatting with over these apps. Just a note for parts of the audience that may not have thought of that.

Fanny: Yeah, definitely. That’s a major benefit of Delta Chat, in terms of trivially making more accounts and using them for different purposes. Both just to have a separation of concerns for yourself, but also to mitigate some of the increased metadata that’s available as a part of the Delta Chat protocol. And also, just for context, you can actually look at a metrics endpoint of any Delta Chat back-end server and see how many active accounts there are on it. On the default Delta Chat back-end server, right now, there are 345,015 active accounts. We know—just from following them—that server is a physical server in Germany. It’s a big server, but it’s not, like, an unbelievably big server. It’s able to have almost 350,000 accounts on it without really breaking a sweat. That is just a testament to the scalability of this specific piece of chat software, but also to how widely used it is. That’s 345,000 users.

TFSR: So because this is a contingency plan, right? If people don’t agree that this is the best app for them and for their community… That being a core element of “What is a good contingency plan?” seems to be like, what works for your community? What works for your safety needs?

I like the zine. I was excited to have this discussion in part because, yeah, Delta Chat seems cool. I’d like for more people to learn about it. But also for people to be having these conversations about what might alternatives be. Can you talk about the importance of having this conversation and having plans and being prepared for what would happen if something like Signal wasn’t available anymore?

Fanny: Totally. I can start off and then Mary, if you want to expand or respond on your own, please do. Our goal here isn’t to go out and get people to use Delta Chat. We have no connection to Delta Chat individually. We’re not contributors. We’re not part of the organization. Our goal is to facilitate preparedness for something that many people may not have considered, which is Signal getting blocked, because we’re used to using a really resilient Signal. We’re used to a different political context in the US. This is like a new type of fear. Most people don’t have the time or the tools to go out and assess what may or may not work best for them. We’re just trying to be two people who are saying, hey, here’s what we think is a good backup plan for this specific scenario.

Everyone has to use the same app if they want to talk to each other. So there’s just this practical concern of how do you get everyone to agree? There’s often just a scarcity of reliable information—or coherent information—about why everyone should or shouldn’t agree with a given alternative. We’re just trying to simplify that a little bit, because what matters is that we’re able to keep talking to each other and strategizing and surviving if Signal gets blocked.

TFSR: How do you find people that you already have affinity with on this platform? Because it doesn’t have the social media element, and you can’t search someone by phone number like you could—unless you’ve got that disabled on Signal, right?

Fanny: Right. Signal has this really convenient feature where if you have someone’s phone number in your phone, then there’s a really decent chance that you can just find them on Signal effortlessly. And Delta Chat doesn’t have this at all. Part of why we want to put this information out now, and advocate for getting connected on a contingency app with your close people now, is because using Signal to exchange that connection information with each other is essential. If you’re trying to do it after Signal has been blocked, then you’re going to have to use insecure communication mediums like email or plain SMS to plan to meet up and exchange information. There’s just a practical consideration there.

It’s interesting. I mean, I think connecting with people on Delta Chat has felt pretty normal to me but my day-to-day life feels very, like, in physical community. So doing the ritual of QR code scanning feels pretty normal. Also I have the opportunity to do it regularly because I’m in the same place as the people that I’m close to regularly. But you do not have to meet physically with someone in order to connect with them on Delta Chat. It’s a little bit harder to copy the link and send it over Signal, but you can do it. And I will say that I did recently have the experience of convincing a super app-hating friend who hates all devices to get onto Delta Chat. I just sent them a link to the app or something like that and I was like, “Yeah, we can scan QR codes next time we meet up.” Instead, just like, four minutes later, they had sent me the link on Signal. I didn’t ask them about that, but they figured out how to do that without any instruction. And that was really… I feel good about that, because I was not sure how easy that would be for someone.

TFSR: It’s even good for Luddites like Mary. Mary?

Mary: Yeah. I think there’s a piece of this also where… in hacker community—or places where the strengths of various encryption protocols are being discussed more regularly—just like you hinted at, there are so many different encrypted chat applications that are available to use with all of these different feature sets and different strengths and weaknesses. But I think outside of that context, it’s not something that I see being discussed as much as I would like—this kind of emergency preparedness aspect of evaluating our encrypted communications. I think we are seeing this happen in the radio nerd space, with low-raw protocols like Meshtastic and Reticulum, and that’s really exciting. We want to see more of this happening with our encrypted chats that we mostly do on our phones.

TFSR: I think we got, necessarily—and this is where I wanted to go—a little bit into weeds that I am… well, far from being an expert and not considering myself any sort of technologist, I’ve been thinking about encryption technologies for a while. I’m not a cryptologist or cryptographer or cryptogrite or whatever.

Fanny: I liked cryptologist. That was great.

TFSR: Thank you. Yeah, my astrology and cryptology go hand in hand. I’m a cryptoid.

I would love if you think of any or if you want to shout out any resources that are nice, introductory… Things that people—now that they’ve come through the conversation and are like, “The hell were they talking about?”—might access to approach some of the topics that we’ve been talking about and do their own research so to speak. I’d love to hear them. I know I didn’t prompt for that beforehand, but we can also include some. I’ll put a warning at the beginning of this chat, just saying that we’re going to get kind of technical about stuff and to check the show notes for links to stuff that that you can read up on… in terms of understanding how encrypted apps work and some of the terminology that we’ve been using. Do you have any shout-outs that just occur off the top of your head for if somebody’s interested in learning more, but they maybe don’t have familiarity with the terminology?

Fanny:Yeah, I’ll shout-out one. I really love sending people to the Delta Chat FAQ. Delta Chat’s website is delta.chat. They have an FAQ on there and it’s gigantic. In the same way that Delta Chat has put a ton of work into making a clean UX and also specifically working with people who specialize in UX design to make it an easy user experience for people who don’t care about the details. I think they’ve also put a good amount of work into explaining how the encryption in Delta Chat works for a wide range of readers. It’s delta.chat/en/help. But if you just go to the website delta.chat, you’ll be able to find it pretty easily. They really cover a lot of ground there. That’s specific to Delta Chat. But you know, there’s terms in there that you can branch off of and go do other internet searches about.

TFSR: I guess another element, probably of reasons to support or not support a project…like, I had made that whole list that I didn’t end up reading through of other chat apps. Is that it is consistently updated with new patches and that it’s being worked on by people. Is that an upside to any of the projects that you’ve suggested? Like, I went to the Briar page, and I saw that the last beta desktop version was from 2023. Then I checked their code site, and I mean, they’re still putting out updates. But that had me thinking, like, oh, there’s some cool ideas that people have had, but if they’re not getting updated, then… Like Cwtch, for instance, I don’t know if they’re still updating it. They had stopped for a while.

Mary: That’s a really great point. I love when software is done as a Luddite. But that should not be the case for your encryption software at all.

TFSR: Cool. Well, I’ve kept you on both for a long time now. I really appreciate this chat and all the work that you’ve put into this. You mentioned the FAQ for the Delta Chat site, and you mentioned also that you are not involved in developing Delta Chat. But if people wanted to get involved with Delta Chat and learn more, can you point them again towards some resources or sites?

Mary: Delta.chat has a link to contributing, whether that be monetarily or through development or even running servers yourself.

Fanny: Delta Chat also has a forum that’s really active. It’s support.delta.chat. But again, it’s linked on the website. There’s a lot of people posting on there. Whether you’re just like an application or like a Delta Chat client user who has questions about it, or if you’re someone who’s trying to run a backend server yourself, you can post there. I think that their only social media is on Mastodon, but they’re super active and super responsive. So it’s sort of the traditional open-source modes of getting involved, which is often GitHub issues, social media—decentralized social media, specifically—and a forum, but they’re very available in those pathways.

TFSR: Cool. I’ve heard both of you in conversation before mention the community around the development and the running of these servers. You had some things to say about how involved people were and how communicative and supportive the general community was. I know that within the free and open-source world, this frequently can be a hallmark of it. It can also be like lots of short, snide comments and whatever else. But I’d love if you could… I don’t know if you want to say a few things to shout-out the culture around the development of Delta Chat.

Fanny: Yes, definitely. I can mostly speak to the experience of running a back-end server. Part of the design of the Delta Chat back-end servers is that it is possible, but not easy, to run a back-end server that is private. For the most part, if you’re running a Delta Chat back-end server, it’s open to the entire world. This kind of gatekeeps running back-end servers. But on the flip side, it also means that, in general, when someone’s running a Delta Chat back-end server, they are growing the wider network of Delta Chat’s resilience through decentralized back-end servers.

Inevitably, when you’re setting up that back-end server, you have some kind of question about, “Hey, I’m having trouble with this one specific piece of configuration,” and you post in the forum about it. What my experience was that, I did that. Then someone from the team was like, “Hey, are you making a public server?” And I was like, yes, I am. They were like, “Great. Let’s add you to this group chat of all the other people running public servers.” Then there you are in this group chat of a bunch of people who are admins of public Delta Chat servers helping each other. Letting each other know about problems they’re having, giving each other updates about new server-side software updates, and asking questions in a context that is private which is really useful for asking questions that you’re afraid might be stupid, basically.

But it’s really important to facilitate a context where the people who are responsible for the decentralized network have a place to ask those questions. Because the goal is: run the network effectively. The goal is not: look smart on the internet. What Delta Chat has done is created this well-segmented set of social contexts for facilitating all the different parts of making Delta Chat happen effectively. And it was a really good experience. It showed me that Delta Chats really thinking about the social aspect of running a decentralized network, which I think is honestly one of the hardest parts of it.

TFSR: One shortcoming that I’ve heard about how Delta Chat operates right now is around group chats and the size of group chats, if you want to address that.

Mary: Fanny, do you remember the ceiling off the top of your head?

Fanny: Yeah, the current public docs put the ceiling at 50-100 so it’s kind of a range.

TFSR: It’s just because of the exchange of keys that at a certain point, it just gets clunky and starts operating a little off, I guess? Not that data is necessarily leaking, right? But it just makes the interoperability of all these people exchanging info difficult.

Fanny: Yeah, definitely. The fact that Delta Chat does not by default have video and calling… this is a downside, but it was not part of our requirements for a Signal alternative in the event that Signal gets blocked. This is probably the biggest texting-related downside of Delta Chat as an alternative is that you can’t make as giant of group chats. It will let you make them, but the nature of email is such that the experience will degrade somewhere around 50 to 100 users.

And yet, there’s no vulnerabilities associated with that. There’s no extra metadata leakage or anything like that. It’s not going to crash the server. My understanding is that the main issue is too many messages will start coming out of order to different people, and so everything gets kind of chaotic.

TFSR: So if you’re into living that asynchronous life, go for it. If people want to yell at you, the website says they can reach you at signal-contingency-plan@riseup.net. Any other things you want to throw in for contact and further reading right now?

Fanny: I don’t think so. Yeah, that’s how you should get in contact with us. Definitely if you’re feeling really upset, please read the whole website or the whole zine first. But otherwise, yeah, I mean, we definitely want to hear from people about this.

Mary: And if you’ve got an alternative suggestion, send us your zine too. We’d love to read it.

Fanny: Yeah, yeah.

TFSR: Fanny and Mary, thank you so much for having this conversation and for this work. I really appreciate it.

Fanny: Thank you. It was great.

Mary: Yeah. Thank you.