When I started working on Mailyard, my intention was to deploy it for myself to deal with my overflowing Gmail inbox. I had accumulated a decade's worth of data, and was caught out when my G Suite (then named Google Apps) plan reverted to the 15gb limit that was enforced on all free mailboxes.
From a privacy standpoint, building an app that you deploy for your own use is pretty straightforward, but I wanted to take things further and offer it as a service to others who might be in a similar boat. Thinking as an end-user, I wouldn't want to give access to my emails to just any third-party, and it was this challenge led me down the rabbit hole that is cybersecurity and privacy.
I wondered what a business would look like if it took privacy measures as far as it could. Could one build and operate a SaaS business but maintain its customers' privacy and anonymity?
Here's what we've got so far.
Mailyard can't read your emails
At no point does Mailyard servers handle your email data in an unencrypted form. That's because most of the work is done in the client-side, which is your browser. When you are asked to log in to your Google account, it is your browser that is connecting directly to Google's servers, and downloading the raw email to your computer.
Your browser then performs the encrypting your data before uploading it to Mailyard servers, which ultimately makes it impossible for us to read your emails. Same goes for any adversary that gains access to our server for that matter. Without your data encryption key, no one can read your emails.
For most tech companies, conventional wisdom dictates that encrypting data in the browser is a fool's errand since "the browser is a hostile environment", to parrot an oft-quoted phrase. This wisdom isn't wrong per se, but needs to be applied in the right context because it's not just end-point security that we should be concerned with.
With one too many data leaks and scandals, companies need to ask themselves if they really need to store private data on their servers in the way that they can access them If you aren't Facebook and Google, whose entire business models are predicated on using and sharing data, then holding private data is more a liability than an asset.
Mailyard encrypts your data within the browser not because doing so safeguards you against end-point attacks (it doesn't), but because it prevents us from snooping around your data. Which for me is fine I guess, it's not like I had time to read your emails anyway!
Mailyard doesn't know your email address(es)
It's true, for a service that backs up your email we don't actually need to know what email addresses you are backing up. Like the emails within them, each mailbox's metadata (which includes your email) will be encrypted before it's sent to our servers. You don't even need an email address to create an account with us; you get to choose a username, preferably a pseudonym (more on usernames in the next point).
Without an email address, we then had to figure out a way to communicate account updates to our customers. We use browser push notifications, which get a bad rep from websites that instantly bombard users with the request to accept notifications. It's unfortunate because push notifications actually put the power back in the hands of users since it can be controlled by the user within the browser, compared to email addresses which are often sold on black-hat marketplaces; you can't buy or sell push subscriptions the way black hat marketers do with email addresses.
While getting push notifications might need a bit of getting used to, our implementation is off to a great start. Even if you aren't a customer, you can also sign up for our marketing push notifications.
Mailyard actually deletes your account upon request
That includes your username, and anything that can tie back to your identity. Your username is only useful for identifying your access when logging in, and not much else. If you delete your account, your username is scrubbed from our database, and decoupled from the billing data that we have to keep (all we have left to identify you is an internally generated UUID).
After you delete your account, your username may be re-used by other people, which isn't a problem since usernames aren't meaningful across services the way email addresses are as a communications channel. In fact, this may lead to even greater privacy protections since it provides plausible deniability in the unlikely case that someone tries to pin something on you based on your username.
Mailyard doesn't use any trackers for analytics
This was one of the hardest decisions I had to make (or at the very least defer making) for a startup that is ultimately for-profit. As of publication, Mailyard does not install any tracking scripts on the web client that downloads your emails, nor even on the marketing website itself.
One concession is that we are using Stripe's client-side libraries, which includes some tracking to prevent fraudulent transactions. However, the use of this library is deployed only on the billing pages that is kept separate from the web client (the code that works with your emails). Going forward, we do have plans to completely isolate the billing code into its own deployment to further separate their concerns.
Not having any tracking poses great difficulty for a startup which relies heavily on analytics to understand what's working and what's not. Although collecting data is so critical to so many tech companies today, we are still figuring out what level of data collection is healthy as a society, which is why I am holding off on installing a tracker.
I am still evaluating various options for analytics to see if we can find some sort of equilibrium. In the event that we do set up analytics, you can trust that it will be done in a fair and transparent manner.
Update 15 Nov 2019: Ackee looks pretty promising!
Update 21 Nov 2019: I've implemented Ackee on its most minimal settings, so only non-personally identifying data is collected, and I am able to keep track of basic usage stats across the product site and the blog (app usage is not tracked).
Mailyard doesn't take in your password
People have gotten so comfortable with filling in their usernames and passwords that it has become an innocuous part of everyday life. They may even know that companies shouldn't store their passwords in plain text, but what they often don't think about is how for brief amount of time their password is available to the server that is processing their request.
This is a big part of the reason why security experts recommend users have different passwords for each site that they use, and ultimately invest (time and/or money) in setting up a password manager, with new passwords for all their accounts.
On our end, Mailyard takes a different approach; your password is used only within the client and is never sent to our servers. Since your password is used (indirectly) to decrypt your data, it would defeat the purpose of all our security measures if you gave us your password each time you logged in.
The approach Mailyard uses is called Secure Remote Password (SRP), and is a small but critical component of our security architecture (which shall be covered in more detail on this blog).
With the above protections, we've already gone above and beyond what's expected, but we're only just getting started. We have many privacy and security ideas that we can take forward, but here's a couple that are up next on our list.
Payment with cryptocurrencies
We currently use Stripe as our payment provider, which is commendable for their privacy protections. Hypothetically speaking though, if a three-letter government agency were to request for data in a way that couldn't be refused from both Mailyard and Stripe (and subsequently your credit card issuer), there's a good chance that they would be able to uncover your real identity.
Even if you used a disposable credit card number, it too is also inextricably bound to your identity in some way, which can help against most threats, but not from state-level actors (hypothetically speaking still of course). We can do one better by supporting payment using cryptocurrencies (am looking at stablecoin implementations), where you dear reader will be in-charge of your own security and privacy.
Fully isolated mode
Mailyard makes use of Lanyard (also authored by me, expect more information at a future date), which is a framework for giving control over data back to users, by moving encryption/decryption client-side. While this configuration offers a great deal more privacy protections than regular web applications, we can still do better.
If an attacker, or a rogue employee, gets access to our servers, they may serve our customers with a poisoned login page, steal our users' passwords (right from the browser), and decrypt all their emails. While Mailyard (and even the most ardent of tech companies) makes every effort within our control to prevent this from happening, I believe that it's not enough to just rely on tech companies to be good stewards of data; as end users we ought to wrestle back some control over our data.
This is why I'm working on a fully isolated mode for Lanyard, where your keys and other secrets are stored within a browser extension, exposing only a minimal interface for websites to authenticate users, encrypt and decrypt data. In this configuration, an attacker will not be able pull off a mass attack on all our users as they will need access to keys on each user's computer.
As a privacy-conscious startup, Mailyard is largely an exploration of how far we can take our privacy safeguards. In the larger scheme of things, Mailyard is software for people that want to take back control of their lives, and not be subject to the tyranny of data collection. If you have questions feel free to shoot me an email at firstname.lastname@example.org.