Revealing a secret. Secret Architecture

Any of your thoughts or desires can anonymously spread around the world in less than a second, starting only with you and your friends.

Secret came out only four days ago, and everything that we saw inspires us. Thoughts spreading throughout the country are honest, touching, ridiculous and, contrary to expectations, are rarely obscene. This confirms our belief that anonymity can contribute to positive change in the world.

We have received a few questions about how Secret protects your personal data. We take this very seriously and think that it is important to be open and honest in how our system works in order to build trustful relationships with the community.

Take a look under the hood

Let's focus on two issues. Storage - how and where your information is stored. Delivery - how we deliver secrets to people you know.

Storage

Firstly, your data is stored on Google’s servers, in the same place as Gmail. This means that your secrets are as well protected as mail (this refers to the reliability of writing data to disk, which are located in the same data centers as Gmail). As a former Google engineer with a deep knowledge of the backend, I am confident in this choice.

A few high-level details:

• Secret is hosted on the Google App Engine . It is written almost entirely in Go , but has some components in Java and Python.
• All data transmitted over the wire is encrypted using TLS.
• We use a non-relational database based on Google BigTable .
• All messages are encrypted before being written to the database. The keys are located on a third-party service that supports key rotation.
• Images are stored on Google Cloud Storage and transmitted via TLS.

Contacts. When we look for people you know from your Contacts, we do not send phone numbers or e-mails to our servers in clear text. First, we locally compute the hash (with salt) that the server uses to find matches with other hashes. For example, the number [+15552786005] becomes [a22d75c92a630725f4], and the original phone number never leaves your device. This is a one-way transformation. In other words, we do not know your actual data , unlike other services.

Important note: Although we add “salt” to the hash, it is still possible to compare the hash with the phone number, especially if the attacker has “salt”. We are looking for a way to make this more secure (for example, add user-specific data to the hash or use the Diffie Protocol ). If you have suggestions for improving security, write to security@secret.ly. This area is very interesting to us.

Secrets Secret meta data is stored without reference to the user. Instead, when delivering the secret to the user, we create a unique token for the user and provide access to the secret as a many-to-one relationship. Tokens are in ACLbelonging to a secret, not to the user. Messages (comments and posts) are encrypted on the server and decrypted when a unique token is exchanged for a secret. The server never returns personally-sensitive data along with the secret.

These data structures (users, posts, ASLs) are logically separated in the database. Despite the fact that this abstraction does not provide physical security, it prevents a simple observer from discovering the author of a secret and will allow us to easily separate data in the future.

Identification. There is no way for moderators to find a post created by a specific user. In case we need to access information for debugging or administrative purposes, we use the “Two-Person Rule”. Two people must provide their keys at the same time. In our case, two administrators (now the founders) must log in through a Google account (with two-factor authorization) and request the necessary resource in a certain period of time. This system, known as Red October, is described in more detail on the Cloudflare blog .

Delivery

The Secret delivery system has been designed to meet these criteria:

• Must be safe.
• Must be fast.
• Must learn.

What happens when you post

• The post is first saved and delivered to the author.
• Next, the asynchronous process determines to whom your post can still be delivered (with whom you are connected or to whom it may be of interest). The contacts in your book are just a strong signal for the algorithm.
• Each delivery is unique to the user and can be canceled, which is an important property in the fight against spam (which is not described in this article).

What is not happening

• We do not deliver secrets to people from your Contacts. If a person is in your notebook, this does not necessarily mean that he will receive a secret.

Time. Although our system has high bandwidth, this does not mean that secrets are always delivered instantly. For example, the fewer “friends” a user has, the less we show him. This avoids the trick when you can figure out who wrote the secret.

If the user does not have friends or there are few of them, then he will not see many secrets from those whom he can know. The more friends he adds, the more secrets come from his “circle” (friends and friends of friends). If there are many friends, then we will show whether a particular post came from a friend or friends of a friend. This is crucial for building trust without revealing one’s identity.

Putting it all together

We strive to make technology highly safe and, at the same time, flexible and giving us the opportunity to make our product more humane. Creating great products is possible only when sophisticated technology can be presented in a simple, beautiful and complete form.

Nowadays and our century, security and privacy are more important than ever. This has been important to us at Google and Square and will always be top priority at Secret.

David Byttow
Co-Founder, Secret