One of the creators was applying for a mortgage and needed to send sensitive documents to a lending agent. He didn't want to e-mail these files as attachments that would live forever on the agent's mail server. The best he could come up with was to upload them to a public DropBox folder and ask the agent to let him know when they downloaded them so he could immediately delete them.
BurnBox is a way to automate this process.
The moment a message is viewed, it is loaded into memory from the database and file system, destroyed from the database and file system, and served from memory (source).
It is. Efficiency is being sacrificed for assurance.
We could, for instance, use S3 and CloudFront to store and serve the files. But that means unknown copies of your files on the S3 and CloudFront servers. And file deletes are issued through an API call, which is undoubtedly queued on the Amazon side and processed at a later time.
Errors can happen during file download--lost Internet connection, closed browser, etc.--but we'd rather go through the simple process of recreating the message than think that our messages are hanging around on a server. The most important thing is that messages are deleted, forever, from BurnBox.
Yes, we encrypt messages and files 'at rest'. This means if our server is somehow compromised, and an attacker is able to view what is currently in our database, they still can not view the actual contents of any messages we are storing, because the contents are encrypted. Messages can only be decrypted with a key that is contained in your Burnbox link, and we do not store that key.