Languages, programming environments, and frameworks are all good for different things. When we started Cwtch we evaluated Go as a good candidate for building a system library. In our ongoing research we’ve also identified Rust as having excelent properties for making very safe critical apps. However neither of these langauges come equiped with frameworks for rapidly, easily and seamlessly building crossplatform UIs. If you find yourself in a similar situation starting out, or in a situation where there is a mature solution to a problem in a language that is also not well suited to UI building than you might find this overview of our work combinging a robust Go networking library, Cwtch, with Flutter to build a single UI and codebase for Windows, Android, and Linux.Read More
We envision Cwtch as a platform for providing an authenticated transport layer to higher-level applications. Developers are free to make their own choices about what application layer protocols to use, whether they want bespoke binary message formats or just want to throw an HTTP library on top and call it a day. Cwtch can generate new keypairs for you (which become onion addresses; no need for any DNS registrations!) and you can REST assured (hehe) that any data your application receives from the (anonymous communication) network has been authenticated already.
For our flagship titular Cwtch Messenger app, we wanted an application layer message protocol that is lightweight/compact, and common enough that we can easily re-parse raw messages from a variety of frontends whenever the need arises.Read More
The user interface remains the largest and riskiest part of the Cwtch system. While we can (and do) strictly scope the code involved in the Cwtch protocol, we are at the mercy of large UI frameworks when it comes to displaying and interacting with the protocol in a way that is usable and cross-platform.
We can’t vet every single line of code in UI frameworks, and even if we did these frameworks often produce intermediate code during their compilation (e.g. to generate specific code that will work on Window, Linux, iOS or Android) which in turn invokes dynamic libraries that exist on those systems with their own security concerns and considerations.
Fuzz testing allows us to battle harden Cwtch against possible failure cases in a way that is efficient and scalable, and for that we have Fuzz Bot!Read More
I talked previously on how we had built our automated build and test system and the benefits in quality that gave us. Today I’d like to zoom in to one of my favourite pieces of our quality assurance infrastructure, the Cwtch integration test. This test is important because we’ve written it to hit as much of the Cwtch code base as possible and test it works in one go. It also sits on top of several other crucial components and thus gives them extra coverage and workout too, such as Tapir and our Connectivity package.Read More
In my last post, I discussed porting Cwtch’s user interface from Qt to Flutter (using our common Go backend).
This week, I’m going to give an introduction of our use of flutter testing tools to improve the quality and safety of the new Cwtch UI.
We will take a look at Flutter widget and integration tests, and how we are using them to test everything from our custom textfields to safety critical features like “does blocking actually work?”.Read More
Cwtch is still experimental software, and we have plenty of open questions about turning it into an application that meets our increasingly higher standards for anonymity, privacy and consent. It is no small feat and requires constantly evaluating our assumptions and previous expectations.
As we finally approach a Cwtch Beta, I want to take the opportunity to look back, with hindsight and fresh eyes, in order to understand where we go next.Read More
A Brief History of Open Privacy Automated Build Systems
I’ve had a few experiences with build systems over my career. After joining a small startup, I was horrified to find that their deployment ‘process’ for 6 micro-services, entailed devs logging into each of the two servers they initially had for production, and manually checking out the latest code, rebuilding it, and restarting it. I spent some of my early time there building an automated build system with Jenkins.
Later, I worked at a large tech company which had a pretty decent and robust system that had been developed in-house. Sadly, even in that company, operational excellence levels varied quite wildly from team to team. Some teams had full Continuous Integration (CI), which is a fully automated build pipeline deploying code that passes the tests to production automatically, which speaks highly of the team trusting their tests to catch any and all issues. Meanwhile, many other teams not only had manual approval steps in their build pipelines but many of those approvals were attached to very long documents of required manual testing steps.Read More
Welcome to Discreet Log! A fortnightly technical development blog to provide an in-depth look into the research, projects and tools that we work on at Open Privacy. For our second post Erinn Atwater documents the development of a new Flutter-based UI for Cwtch.
The Cwtch library provides a backend written in Go intended to provide support to a number of other apps we have planned that use Cwtch connections as a (metadata-minimizing, authenticated) transport layer. Sarah has been working on Tapir so the backend has an open path forward in Rust, but today we’re here to chat about the other side!Read More
Welcome to Discreet Log! A fortnightly technical development blog to provide an in-depth look into the research, projects and tools that we work on at Open Privacy. For our first post Sarah Jamie Lewis will take us through her investigations into some new research on “fuzzy message detection” schemes that might hold the key to bandwidth efficient metadata resistant offline messaging in Cwtch…
Anonymous messaging systems (and other privacy-preserving applications) often require a mechanism for one party to learn that another party has messaged them.
Many schemes rely on a bandwidth-intensive “download everything and attempt-decryption” approach. Others rely on a trusted 3rd party, or non-collusion assumptions, to provide a “private” service.
It would be awesome if we could get an untrusted, adversarial server to do some of that work for us without compromising metadata-resistance.Read More