Demystifying Secret
A peek into the fox hole
Update (10/10/2014): We plan to migrate our backend services to AWS by early 2015.
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.
Let’s focus on two components. Storage — how and where we store your data. Delivery — how we deliver secrets to people you know.
Storage
Secret data is stored on Google servers that are located in the same data centers as Gmail. This means your secrets benefit from Google’s physical security and are essentially as safe from physical misuse as your Gmail. Having been a Google engineer with intimate knowledge of the backend services, I made this choice so that Secret users would benefit from Google’s robust physical security.
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 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. For example, [+15552786005] might become[a22d75c92a630725f4] and the original phone number never leaves your phone. This is a one-way transformation. In other words, we don’t know the phone number or email address that corresponds to the hash value.
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 security@secret.ly 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. As a result, personally identifiable data does not need to presented 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. Moderators are not able to access or modify posts created by a specific user. In the event that we need to access or modify information for administrative, debugging or other 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.
Delivery
Secret’s delivery system was designed to meet the following requirements:
- It should 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 rebersed. This helps our efforts to identify and reduce spam and other unwanted activity on Secret.
What doesn’t happen
- We do not deliver all your secrets to all the people in your address book. Just because you have someone in your contacts, it doesn’t necessarily mean they will see each of 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 helps 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.
David Byttow
Co-founder, Secret
You should follow us on Twitter, @secretly.
Want to work with us? Email work@secret.ly, we’re hiring engineers.