Open Privacy believes in empowering users in ways that enable consent to and control over the movement of their data. The ebb and flow of current communication technologies has created a situation in which users are forced to either relinquish control over their personal information to dozens of unknown companies and government agencies, or sit on the sidelines and refrain from participating in culture and public society. Worse, many tools collect information on us that can be used against us in ways that are difficult to understand or predict. Nowhere is this impact felt harder than in the marginalized communities which Open Privacy exists to serve. We see only one solution to this problem: taking our data back into our own hands, and removing the ability of service providers to see our data at all. Today we announce the first step on this long journey: Cwtch.

Cwtch (a Welsh word roughly translating to “a hug that creates a safe place”) is a decentralized, privacy-preserving, asynchronous multi-party messaging protocol that can be used to build metadata resistant applications.

The Metadata Problem

Many messaging apps (such as Signal, Wire, and WhatsApp) have taken great strides toward making end-to-end encryption pervasive, hiding the contents of our communications from prying eyes. However, most of these tools still collect (or are able to collect) metadata: information about who is speaking, who they are speaking to, when, how often, from where, and more. This information can be used to construct our social graph, track down the people we talk to, and in some instances even infer what we are saying. Law enforcement under oppressive regimes uses these patterns on a daily basis to locate, detain, surveil, and harm our partners, our families, our friends, our comrades. In the words of former NSA director Michael Hayden, “we kill people based on metadata.”

Cwtch’s goal is to minimize – and, wherever possible, outright eliminate – the metadata exposed by the tools we use. Tools like Ricochet and Briar have begun to tackle this problem, and we hope to contribute to advancing these important ideas and technologies.

Cwtch

What exactly does all this mean? Cwtch is:

• Decentralized: There is no “Cwtch service” or “Cwtch network”. Participants in Cwtch can host their own safe spaces, or lend their infrastructure to others seeking a safe space.
• Privacy Preserving: All communication in Cwtch is end-to-end encrypted and takes place over Tor onion services. While long-lived infrastructure is used to provide many features like offline messaging, it is untrusted and never has access to any information about the peers or the groups that are using them.
• Asynchronous & Multi Party: Cwtch is inspired by and based on Ricochet, a peer-to-peer instant messaging system also built on Tor onion services. However, Ricochet only supports online two-party messaging. Cwtch extends and enhances the protocol to support multi-party messaging and offline messaging.
• Metadata Resistant: Cwtch has been designed such that no information is exchanged or available to anyone without their explicit consent, including on-the-wire messages and protocol metadata.

All of this combined means that unlike most messaging systems, Cwtch not only encrypts the contents of a communication; it also protects the context of the communication. Being built on Tor gives us strong censorship circumvention properties. End-to-end encryption protects what we’re saying, and metadata resistance prevents server operators from learning who we are speaking to and when.

Privacy Preserving Infrastructure

Cwtch works through the use of untrusted, discardable, privacy-preserving infrastructure that we call Cwtch Servers. Anyone can run a Cwtch Server. By distributing its address, people and groups can use the server to facilitate group messaging and other applications.

Everyone deserves access to the strongest privacy controls possible, which is why our goal for Cwtch is not just to offer another stand alone application. We deliberately wrote Cwtch as a library that can be used to build all manner of metadata resistant applications.

Because Cwtch Servers have no knowledge about what peers are using the server for, there is no need to rely on particular servers for features. Application-layer functionality exists in the protocol messages being sent between peers in a group.

What Now?

Cwtch is an experimental concept and prototype. We do not recommend you use Cwtch today if you require secure communication. At least, not yet. We are releasing the Cwtch paper and software so that fellow researchers and volunteers can evaluate it and report security issues and bugs, as well as suggest improvements to help make it better.

The only way to build secure software is to attack it from every angle. There are a number of limitations and problems with Cwtch, both as designed and as implemented in our prototype. We are working on many of these, but would like to invite researchers to work with us on new solutions, as well as identify new problems. Here are the problems we know about:

• The user experience of metadata resistance tools: Environments that offer metadata resistance are plagued with issues that impact usability, such as higher latencies than seen with centralized, metadata-driven systems and dropped connections resulting from unstable anonymization networks. Additional research is needed to understand how users experience these kinds of failures, and how apps should handle and/or communicate them to users. Furthermore, Tor onion service addresses are not user friendly, and v3 onion service addresses make identifiers much longer. Ideally, users would be able to provide friends and associates with a more friendly handle, or their friends and associates would be able to discover them in a consistent, reliable way.
• Scalability: Heavily utilized Cwtch servers increase message latency and the resources a client requires to process messages. While Cwtch servers are designed to be cheap and easy to set up, and Cwtch peers are encouraged to move around, there is a clear balance to be found between increasing the anonymity set of a given Cwtch server (to prevent targeted disruptions), and the decentralization of Cwtch groups.
• The (online) first contact problem: Cwtch requires that any two peers are online at the same time before a key exchange / group setup is possible. One potential way to overcome this is through encoding an additional public key and a Cwtch server address into a Cwtch peer identifier - this would allow peers to send encrypted messages to an offline Cwtch peer via a known server, with the same guarantees as a Cwtch group message. We discuss some of the issues with this approach in our paper and would love to see other approaches to fixing this problem and eventually incorporate one of them into Cwtch.
• Reliability: In Cwtch, servers have full control over the number of messages they store and for how long. This has an unfortunate impact on the reliability of group messages: if groups choose an unreliable server, they might find their messages have been dropped. While we provide a mechanism for detecting dropped/missing messages, we don’t currently provide a way to recover from such failures. There are many possible strategies to addressing this, from asking peers to resend messages to moving to a different server, each with positives and downsides. A full evaluation of approaches should be conducted to determine the most practical solution.
• Discoverability of servers: Much of the strength of Cwtch rests on the assumption that peers and groups can change groups at any time, and that servers are untrusted and discardable. However, our paper does not introduce any mechanism for finding new servers to use to host groups. We believe that such an advertising mechanism could be built over Cwtch itself.

Open Privacy is incredibly excited to be developing Cwtch in partnership with the communities we serve. The specification and implementation are ongoing work, and we hope you’ll help us to make them better. Send comments to the cwtch-dev mailing list, follow us on Twitter, donate, or support our Patreon.