Architecting a Privacy-Focused Chat Application, Part 1 of 3

Ryan Schumacher
Dec 2, 2019 · 4 min read

I’ve heard it said that Slack is the elephant in the room when it comes to security. From my personal experience, it’s very true. Unless one is very informed on security and takes privacy seriously there are serious security issues that arise from convenience.

When I worked for a digital agency, working across many different client projects, it was very common to get Slack messages with passwords. There are clearly better solutions to password management, but since there are agencies still not using them I thought that this would be a fun idea to run with.

Requesting passwords in Slack is a common and insecure way to share secrets. Photo by JESHOOTS.COM
Requesting passwords in Slack is a common and insecure way to share secrets. Photo by JESHOOTS.COM
Secrets in Slack aren’t secret.

Choosing an Architecture

An important step is determining the architecture with respect to user experience. I want my users to be able to easily encrypt data, their data can only be decrypted by specific individuals, and the owner of the data can quickly add or remove user’s access. Finally, as an application developer, I want a separation of concerns and don’t want to have the burden of maintaining encryption keys or controls.

The Versatility of the Trusted Data Format

The Trusted Data Format (TDF) is an open format to maintain cryptographic protections. Because the Virtru SDK is the easiest way to create and work with TDFs, this allows for data encryption with minimal development and allows my users to control who has access to their messages. These features enable me to develop to my UX needs and protect my user’s data since my application doesn’t have access to their encryption keys.

Since TDF is a file format and not a database the two types of architecture which need consideration are single-document (SDA) or multi-document (MDA).

Single Document Architecture

SDA would mean that the communication log would be stored in a single TDF document. The delivery of this document would be via streaming to all clients. The client would then be able to read and write to the stream.

In this model, the chat log is contained within a TDF that Alice owns and Bob has access. Chet has no access and would have to be given access to the entire chat log or cannot be involved.

As a technical advantage, a single document would mean increased speed, reduced disk space, and reduced bandwidth usage. From a usability perspective, granting or revoking permission to an entire conversation would be a single operation. Additionally, the conversation can be archived and exported without much effort.

Areas of weakness are the need to build in collision handling and ensure that the rendering on the client-side is ordered correctly. Since the encryption and data entry happens on the client-side there will also be concerns about data integrity and ensuring the messages have the correct timestamps, metadata, and user attribute. To build in this kind of data integrity check would likely take substantial effort. Usability is hampered with respect to historical access to messages and fine-grained control of messages. Users would not be able to determine, within the conversation, who has access to individual messages and could not revoke access to a specific message, such as a specific password. Lastly, since the conversation will be owned by a single person they become a bottleneck when new members need to join.

Multi-Document Architecture

MDA means the communication log would be stored in multiple TDF documents. The delivery of these documents could be streamed or delivered as individual payloads.

In this model, all the users have access to the chat log. Alice can read Bob’s message and created two. Bob can read two of Alice’s messages. Chet can read one of Alice’s messages but does not have access to another or Bob’s message.

Areas of technical advantages are that the meta-data, timestamps, and user attributes can be managed outside the TDF document. This allows for a lower overhead on infrastructure and a more familiar environment for developers. In terms of usability, a major advantage is that users could determine on an individual message level how they want their data to be shared.

The areas of technical concern are speed, bandwidth, client-side computing power, and meeting the users’ expectations of timeliness. From a usability perspective, if a new user wants access to previous messages each TDF will need to be updated. The same is true if a user needs to be removed.

Making a Decision

After considering the various architectures I decided to approach this with MDA. It is important to me that users can choose who has access to their specific messages. In the ideal case, some messages or conversations could be encrypted while others were in plaintext.

This brings me back to what spurred on this idea, the convenience of sharing passwords via chat. By using the MDA I could ensure that in the stream of a conversation a password could securely be shared and access management of a single message would allow users to share the password quickly with another trusted user.

Real World Use Cases

The usefulness of this architecture goes beyond convenience and slight improvements to security. This architecture would be extremely useful in any real-time communication where the parties need data privacy and control.

For instance, this could be used to power a real-time communication between a patient and their doctor while maintaining HIPAA compliance. Additionally, a specialist could be added for a time to give their opinion while limiting their access to only the necessary data and removed when their involvement is complete.

Coming up next…

In part 2 of this blog series, I am going to show the development of the chat application and how to integrate the basic Virtru’s SDK encrypt/decrypt methods and the sharing control. In part 3, I’ll show how to add additional controls and auditing so users can manage their data.

Don’t forget to follow Virtru for the next blog post in this series!

Virtru Technology Blog

Building developer tools in the interest of data protection…

Ryan Schumacher

Written by

Sr Software Engineer at Virtru, open source hobbyist, with a love for mycology 🍄, and father of two awesome boys.

Virtru Technology Blog

Building developer tools in the interest of data protection and sharing.

Ryan Schumacher

Written by

Sr Software Engineer at Virtru, open source hobbyist, with a love for mycology 🍄, and father of two awesome boys.

Virtru Technology Blog

Building developer tools in the interest of data protection and sharing.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store