There has been a lot of interest in exactly how SenderDefender works, what exactly it is trying to accomplish and how the site is structured. I’m going to try to break that down without going into exhaustive technical detail as to the implementation and deployment.
SenderDefender is trying to:
- Keep sensitive information out of email.
- Prevent third parties from stealing your data.
- Be very easy to use.
These seem like simple goals, but the reality is that creating any security product that meets all three of them is harder than you would imagine. I tried to combine several ideas to provide a complete solution for point-to-point file transfer. SenderDefender is an encrypted ephemeral transfer service. It differs from competitors in that the security of the data comes first, and at no point should I, anyone in my employ, or any of the service providers I use have access to your plain-text data.
A normal cloud storage service is structured very simply. Take a file. Throw meta data into a database. Put the file on a hard drive somewhere. Locally encrypt it to prevent flagrant physical stealing, store the keys in the data base or some other intermediate storage. Almost all services work this way. The reason this is a terrible security model is that you are essentially giving up full access to your data to the service in question. At any point a member of staff can read that data, and since they control the keys, they can unencrypt it without your knowledge. They can give it away, secretly sell it, or just divulge it. There is real financial incentive for corporate espionage and personal identity theft. Almost every single provider out there works like this.
The backend is a separately secured and federated API service. It doesn’t know anything about your data. Every single file upload is randomly assigned credentials for the duration of the upload, is named a randomized UUID and is committed into a large single shared-mailbox style storage vault. The uploaded data is encrypted locally before it hits the network, and the upload itself goes through a third-party conduit that never touches the API or serving infrastructure.
Finally, the key,seed, and other meta data are encoded into the URL after the fragment identifier for the link. This means that when a SenderDefender link is followed the keys never get transmitted onto the network, they are read locally by the browser once the code is deployed. When you use an email service or other channel you are sending the keys to decrypt the data outside of any channel I control or have access to. After a file has been downloaded the backend explicitly deletes it from the shared mailbox, or if the file is unclaimed for 24 hours it is automatically expired. In an ideal situation the links themselves would be sent via an SSL tunnel or other ephemeral conduit to minimize the chance of compromise. Most email compromises happen weeks, months or years after the initial data has been sent. That is a lot of damaging stuff, sitting around waiting to be discovered.
Every effort has been made to isolate and separately vet the components. Remember the idea here is to limit the amount of time sensitive data is on the network, prevent third party access, and make it easy to use. I think SenderDefender does all three admirably.