Anysphere Messaging Post-Mortem

A few days ago, we stopped building Anysphere Messaging, our metadata-private communication system. We want to explain why, in the hope that the explanation will be useful to whoever next attempts to increase privacy in communication systems.

First, some resources for our eventual successor: our code is open source, our technical approach is described in our whitepaper, and we recently published a hopefully widely applicable security definition, including a full proof of our protocol.

So why did we stop building metadata privacy? Because we did not see a path to actually achieve real-world metadata privacy with our current product. Here's why:

1. To achieve real metadata privacy, you need a large anonymity set (that is, many people using the platform indistinguishably). With only a small user base, people reveal metadata simply by using the platform.
2. To get a large anonymity set, people who don't really care about metadata privacy must be willing to use the platform.
3. To make your platform attractive for such people, there must be a use case for them. Their experience with your platform must be at least as good as their best alternative.
4. We could not find such a use case.

Let us elaborate on the fourth point.

In all current research, metadata privacy comes with trade-offs: messages sent on Anysphere usually take around 5 minutes to arrive. While this can hopefully be reduced in the future, limiting message bandwidth is fundamental in order to achieve perfect metadata privacy (because otherwise your bandwidth usage will be correlated with your message pattern).

Most people use two types of electronic communication today: instant messaging and email. The limited bandwidth rules out instant messaging for us. Integrating with email would require the vast majority of messages (all that go to another email provider) to be unencrypted, which sort of defeats our purpose. Instead we tried to sit in-between email and instant messaging: email-style user experience, with the contacts you usually communicate with on instant messaging platforms. Unfortunately, after talking to potential customers, this does not seem to be something people actually want. Especially not to the extent that they would pay for it, which is necessary given the high server costs that our protocol requires.

We would love to see metadata privacy happen at scale, but we believe that there are a number of hard problems that need to be solved before that can happen. To our eventual successor, we recommend the following.

1. Think about how to make privacy tunable. Can regular users opt for lower privacy guarantees in exchange for lower latency, while still contributing to the anonymity set that the privacy-conscious users need?
2. Consider privacy attacks by both the server and a user's contacts. The CF attack paper and our security definition describes several potential attacks by a user’s contacts. For people who are actively targeted, leaking metadata to contacts may be a more serious threat than leaking it to the server, because in most cases it is easier for an attacker to compromise a contact than to compromise the central server.
3. Build a privacy-preserving and trustless public-key infrastructure (PKI). Without memorable user identifiers, the system will not gain widespread adoption.
4. Figure out a sustainable way to fund the server costs. We found this to be hard since people expect communication on the internet to be free. You can reduce cost by developing better PIR algorithms. A good funding model such as freemium for-profit funding or donation-based non-profit funding (e.g. Tor and Signal) might also work.

We still believe that metadata privacy is important, although not as fervently as we did six months ago.¹ While it is time for us to try to improve the world in another way, please reach out at hello@anysphere.co if you want to talk about metadata privacy anytime — we'd love to chat!