Confidentiality is key to the work of lawyers but most Internet-delivered services have no encryption other than transport encryption (HTTPS). This issue affects even the largest companies such as the 2020 Twitter account takeovers of Obama, Biden, Musk, and others, Snapchat employees looking at photos, the Canada Revenue Agency, and just about everyone else. The basic problem is that the data isn't encrypted so anyone with the right permissions at the company, or someone who can change permissions, can access all of the data. These sorts of services are the primary way that people interact with lawyers in 2021.

But there's a different way to use the Internet. A way where the user is the only one with access and this method is called end-to-end encryption (E2E) or "local encryption". E2E means that the user encrypts the data locally and then sends only encrypted data to the server, rather than unencrypted data. There are many programs for doing this but because of the complexity of this approach, a worse user experience, and the general drive of companies to want to know what people are doing with their platforms, this is not the default and is rather rare, even though the technology has never been more accessible.

To experiment with what this might look like for lawyers I created a prototype encrypted messaging platform that encrypts in the browser: It works and you can use it but you shouldn't use it for anything important because this is just an experimental version for me to better understand the problem.

The basic idea of my chat program is not new but the implementations of E2E vary, sometimes dramatically. The user who creates the "Spot" (chat room) automatically generates a complicated password that is then shared with the other users who want to join. Each user has a public and private key pair that is used to encrypt messages to one another by generating a per-message "password" that is encrypted and sent to each recipient along with the message.

This particular program was written to run in the browser in a simple way. In the end it ended up being a few thousand lines of code, but it's still relatively simple. You can join a test room using Spot = "BlogTestRoom" and Password = "urban2page8chair4language1". If you join that room you'll be able to message the other participants but you won't be able to see the message history because the previous messages can only be seen by the poeple they were sent to. This is a security feature but obviously one that many users would be surprised by. And that's a big part of why E2E is not widely adopted, it has a different and sometimes challenging user experience and most software developers are under immense pressure to deliver features and an easy user experience, rather than focusing on security or confidentiality.

The model for my chat program is that each encrypted message is stored on the server for a couple weeks and delivered to the users. Other E2E chat programs use this method or they delete the messages after delivery. But "delivery" in this context is tricky because what if a user has multiple devices? Should a message be deleted after delivering to one device? Will the server even know that the person has multiple devices? In my program the server does not know anything about the users. By not having any metadata a service becomes much less valuable to attack for hackers, less likely to be spied upon by other service providers/employees/etc. and it reduces the risk overall for the operator of the service. Snapchat employees can see the photos that their users send and Zoom employees can (usually) see the video chats that their users are conducting, and the risks inherent in that model are obvious.

Most services have metadata about their users because they need it for notifications, payment, user tracking, convenience, and other uses. So the degree of metadata used varies by service and few of them collect none. But a pretty good option for this is Element, a well-developed chat system that has mobile apps.

Why does my system not have a mobile app? A mobile app is a type of compiled program that the user can't inspect. My motivation for ConvoPark was to make a chat system that the user can actually inspect and know what it's doing. Other chat programs like WhatsApp promise that they do encryption but the user can't know that that's true. Will most users be able to read the Javascript code I wrote? No. But experts can, and people can share that information online.

One danger of a web-delivered chat program: what if the server is malicious and delivers Javascript code that does something bad like disabling encryption for specified users? An example of this problem from 2013 happened to the encrypted messaging service used by Edward Snowden: Lavabit. If the government can order a site to be changed, how can users be protected? A service like ConvoPark would likely be offered by law firms directly, so that the page that serves their clients would be served off of their website, like how Wordpress works. That's why I tried to make the server model easy and require only stock Redis and PHP to run it. I think a movement like Wordpress for encrypted chat could be a powerful way to put the power back in the hands of people who want to exercise their right to speak directly to one another privately.

Private conversations are an ancient right of people. Friends should be able to have a conversation, like at a park ("ConvoPark"), where there's no records and it's just a casual conversation. In 2021, that sounds almost seditious, but it's how the majority of humanity wants to talk with their friends. And for lawyers, they'd be able to download a record of the chat messages to store in their client file. The point of E2E isn't to have "no records" but rather to have records that belong only to the participants, which is how legal services should be delivered. But in a world without much face-to-face contact it's difficult to carry on these kinds of conversations, so there's a need for new tools.

There are many considerations that go into developing a chat program and many trade-offs to decide upon. But having reviewed the available tools, and having built a prototype of my own, I feel confident in saying that the current systems are not very suitable for legal use in the same way as having a meeting in a conference room. And part of the reason for this is that law firms (or other organizations) don't control the tools themselves, which they can only do if they can install it on their own servers. Software-as-a-service has brought convenience (and more profit) to the software world, but at the expense of less security of the data that users generate. 15 years ago there was little awareness of this risk but with the increasing number of high level breaches and the disasters of storing all user data in an unencrypted fashion, I think the time is ripe for a new generation of encrypted communication tools for professionals. Try out ConvoPark to get a sense of how this might work, or take a look at some of the open source and commercial options for doing this.

If you're building a solution like this and want to chat about designing E2E software, or what professionals might want out of it, feel free to send me an email. I'll be happy to discuss my research, thoughts, and some of the challenges I encountered while making this prototype to explore the concept.