A Legalese Free Explanation of the Decisions We've Made
Our goal is to know as little about our customers as we possibly can, while still allowing our app to function.
This starts with account creation. We use Sign in with Apple and Sign in with Google because it allows us to not maintain a database of customers usernames and passwords that we would have to be able to verify to log you in.
Any text contact data shared between two users of our service is end-to-end encrypted (E2EE). We can't access it, even under government subpoena. We can't access it to sell it, advertise against it, or profit off it in any other way.
We've put a fair amount of effort into not knowing anything. For example, when you verify a way you want searchable in our app, we don't want access to that. So, we never save it. When you verify a searchable, we run that data through a one way hashing algorithm and store that hashed value with your account. When you search for a user, that search criteria are run through the same hashing algorithm and then compared to our list of hashed values. We don't know what or who you're searching for, but we can still match you with what you're looking for.
Where everything is not end-to-end encrypted
We'd like everything to be E2EE, but there's two situations where we don't:
- If you're inviting a new user to the service, until they have an account we can't give them a private key. During the period between when you invite them and when they join, we still encrypt that data, but, by necessity, with a public key. We could access that if a government forced us to. We will never choose to, outside of government subpoena. During this time we only ever store that data in RAM, and it is cleared when the invitation is accepted or times out. This only happens when you're inviting a new user to the service, not when connecting with an existing user of the app.
- Profile photos are only encrypted using public keys. This is both so that we can verify if customers are using the photo sharing inappropriately and also because of server costs. If you have 30,000 contacts, this is not as unusual as you'd think, E2EE would necessitate keeping 30,000 copies of the photo on the server, each encrypted with it's own private key for an individual contact to be able to download and decrypt.
Paywalls
There's basically three ways to monetize an app:
- Ads
- Subscriptions
- Sell user data
Selling user data was a non starter for us, so we don't do that. We'll never do that. That leaves ads and subscriptions.
I am strongly of the opinion that apps are best when the customer's experience and app's business model are in alignment. Most people would guess that subscriptions make significantly more money than ads, and that ads only make money if people see them. So, here are the compromises we came to for the ad tier:
- There are ads at the top of the app. You'll see them.
- No background updates. The app costs us just as much to run if open it or not, so to make sure the AWS bill can get paid, we need ad tier users to open the app. If you're on the free tier, when your contacts send you updates, you'll need to open the app to approve the changes to see the most recent contact information.
- Lower quality file size shared profile photos on ad tier. By far, the largest portion of our server bill is profile photos. To reduce the server bill for members on the free tier, photos you share will be a lower file size than on the paid tier.
In short, we want to know as little about you as possible while having a business model that will keep the lights on.