A peek into the fox hole
A simple thought or your innermost desire can anonymously spread around the world in less than a second, starting with only you and your friends.
Secret only launched four days ago, and what we’ve seen has been nothing short of inspiring. Thoughts have been shared across the country that are honest, moving, hilarious, and contrary to expectations, rarely inappropriate. This reaffirms our belief that anonymity can foster positive change in the world.
We’ve received several questions about how Secret protects your identity. We take privacy and security very seriously and feel it’s important to be direct, open and honest about how our system works in order to build trust with you, our community.
Taking a look under the hood
Let’s focus on two components. Storage — how and where we store your data. Delivery — how we deliver secrets to people you know.
First, your data is stored on Google servers — essentially the same servers as Gmail. This means your secrets are as safe as your email (edit: to be crystal clear, this refers to the physical safety of your data on disk, which are hosted in the same data centers as Gmail.) Having been a Google engineer with intimate knowledge of the backend services, I’m confident in this decision.
A few high-level details:
- Secret is hosted on Google App Engine. It’s written almost entirely in Go, but has various components in Java and Python.
- All transmission sent over the wire is encrypted with TLS.
- We use a highly-available, non-relational datastore built on top of Google’s BigTable. There is no relational datastore.
- All message data is encrypted before being written to the datastore. Keys are stored in an off-site keystore service that rotates keys.
- Images are stored privately and securely in Google’s Cloud Storage datastore and served over TLS from Google’s image frontend service.
Contacts. When we connect you with people you know from your Contacts, we don’t send raw phone numbers or email addresses to our servers. Instead, we locally hash the contact details first (with shared salt), which the server then uses to compare against other hashed values. Therefore, [+15552786005] becomes [a22d75c92a630725f4] and the original number never leaves your phone. This is a one-way transformation. In other words, we actually don’t know their information, unlike various other services.
Important note: Although we salt the data, it is possible to match a phone number to a hash, especially if the salt is known to an attacker. We’re looking at ways to make this even more secure (e.g., by joining client-specific data pre-hash or Diffie-Hellman key exchange). If you have a suggestion, please let us know at email@example.com as this is an active area of research for us.
Secrets. Secret metadata are stored without referencing users. Instead, when delivering a secret to a user, we create a unique token for that user and grant it access to the secret, as a many-to-one relationship. The token resource resides in an ACL owned by the secret, not the user. Message data (comments and posts) are encrypted on the server and decrypted when the unique token is exchanged for the secret. The server never returns personally identifiable data alongside secrets.
These data structures (users, posts and ACLs) are logically separated in our datastore. While this abstraction provides no physical security, it does prevent a simple observer from identifying secret authors and affords us the ability to easily decouple the data in the future.
Identity. There is no way for moderators to find posts created by a specific user. In the event that we need to access or modify information for administrative or debugging purposes, we employ a two-man rule. Essentially, two people with access must turn their keys at the same time. That is, two admins (currently the two founders) must both be logged in with their Google accounts (which are protected by two-factor authentication) and request the same resource in a given time frame. For further reading, a similar system is described in this blogpost by Cloudflare, known as Red October.
Secret’s delivery system was designed to meet the following requirements:
- It must be secure.
- It should be fast.
- It should learn.
What happens when you post
- The post is first stored and delivered to the author.
- An asynchronous job runs and determines who the secret should be delivered to, which are people that we believe are connected to you, or you otherwise might find relevant. Contacts are simply a strong signal in the algorithm.
- Each delivery is unique per-user, and can be taken back, which is a very important property to our spam and abuse prevention tools (not described in this document).
What doesn’t happen
- We do not deliver secrets to people in your address book. Just because you have someone in your contacts, it doesn’t necessarily mean they will see your secrets.
Timing. Although our delivery pipeline has high delivery throughput, it doesn’t always release secrets immediately. For example, the fewer “friends” a user has on the system, the less we show them. This is to avoid simple tricks to isolate individuals and their secrets.
As a user with few or no friends, many secrets from people you may know are not visible. Once you have enough friends, we show you a little more, such as the fact that a particular secret comes from within “Your circle,” which is defined as “Friend” or “Friend of friend.” Then, after quite a few more, we show you whether or not a particular post came from a friend or not. This is critical to establishing a connection without knowing someone’s identity.
Bringing it all together
We are committed to building technology in a way that is highly secure, but still provides us the flexibility to make our product feel human. Making great products is only possible when complex technology can be presented in a simple, beautiful and complete form.
In this day and age, privacy and security are more important than ever. It was important to us at Google and Square, and will always be a top priority at Secret.
You should follow us on Twitter, @getsecret.
Want to work with us? Email firstname.lastname@example.org, we’re hiring engineers.