Sunday, January 20, 2013

Announcing the first client-encrypted in-browser file sharing service,

End-to-end encryption in a file sharing service is a file sharing service much like MegaUpload or RapidShare, with an important twist; all files are encrypted in your browser. Browser support is wider than Mega: we support Chrome, Firefox, Safari, and Chrome for Android. We are not able to see your file's contents or name, and we have no means to access them. We do not log IPs and have no means to know what is being shared on our service.

Additionally, allows for automatic self-destruction of your files; by default, your files will self-destruct after 10 views or 7 days. is not Mega - it is not meant for long-term file storage. is meant for end-to-end transmission and transient storage only. It is not currently possible to keep files on for longer than 7 days; this is a feature, not a bug.

We have been up since AngelHack DC, November 18th 2012.

We believe that the smaller an application is, the greater the chances of it being truly secure. To help with that, the client-side code is small and simple enough to understand and is intentionally kept public for review.

Why does this exist?

File sharing on the web is fraught with problems from the very beginning.

By sharing your files, anywhere, on almost every mainstream service, you implicitly trust the operators not to look at your files. This introduces a number of problems if you don't want your data to be available to just anyone:

1. You must be very careful to store your file on a service that randomizes its URLs, so it cannot be found simply by chance.
2. You must store your files in an encrypted archive. To do this, you must have an archiver capable of encryption, and the knowledge to choose a secure algorithm.
3. You should be careful to delete your files after the intended recipient(s) have downloaded them.

It is unlikely that the average computer user will have the knowledge to follow all three of these steps. Yet everyone has files that should they want to privately share. Many encounter this on a regular basis with family, business partners, lawyers, landlords, and so on.

Email is a decent alternative but you must be very careful to encrypt properly as email is often transferred in plain-text. In addition, your archive may live nearly forever (e.g. Gmail) in the recipient's mailbox. If the data is truly sensitive this may not be acceptable. solves these problems in a way that is so simple, your grandmother can use it.

How to Use

It is simple to use the service: simply attach a file and click upload.

We have only a minimal set of options. You may specify a date and number of views allowed on your file. The file will be deleted after receiving that number of views, or once the date has been reached.

For now, defaults and maximums are 10 views and 1 week.  File size maximum is 10MB. We may introduce a paid option that allows for more customization. can easily be used as a simple encrypted end-to-end transfer service. Simply set your view limit to 1 and the file will be deleted as soon as the recipient has downloaded it.

Public Repo

For those of you who are security fanatics, all client-side code is purposely kept un-minified for inspection. You can see exactly how your data is sent. The simplest way to verify I am not being sent any compromising information is to look at your inspector's Network tab.

The client-side files are hosted in a public repo on GitHub. Pull requests are very welcome.

Technical Details

Uploaded files are grabbed as binary strings using the HTML5 File API. They are then encrypted using CryptoJS's fast AES encryption algorithm. Files are encrypted and decrypted in 512kb chunks by up to 4 web workers for extra speed. Encryption/decryption reaches about 2MB/sec on an i5 Macbook Air.

Files are sent to our server which stores on S3. File contents and name are encrypted separately. MIME type is sent in the clear for analytics; these are the only analytics we have. We do not log IP addresses.

We are very careful not to include any plugins or outside JavaScript inside That means no analytics, no Facebook connect, no Flash copy-paste, nothing. All assets are loaded from our server.

When downloading, the file is decrypted in chunks, reassembled, and transformed into a Blob object. Unfortunately, Safari doesn't support Blob URLs - the application will fallback to data-URIs, but this tends to crash the browser after ~6MB. will notify you of this if it applies. does not exist to make money and is likely to remain as a proof-of-concept rather than a full-blown sharing service.

Who are you guys?

This project came out of AngelHack DC, a 24-hour hackathon hosted on November 17-18th. I am Samuel Reed; my partners are Kevin Ohashi and Sean Perkins.


  1. Mmm, I see various problems. Despite the fact of using Rabbit (always use a widely used and tested cipher like AES) how can you ignore use HTTPS? A MitM attack could corrupt your javascript source to avoid use encryption and later sniff the file in plain text.

  2. You're absolutely right; HTTPS is now enabled.

  3. This is absolutely the right way to address a security vulnerability. Go you guys.

  4. Thanks. In addition (and this is part of the reason why the client code is open-source), I was informed that my random passwords were potentially insecure as there were only 2^96 possible combinations. While this would still take hundreds of millions of years to crack on today's hardware, it won't on tomorrow's. Since then we've updated it to use the entire 128-bit space.

  5. Amazing! Thanks for this great project. We will fork this and send pull requests. See you on github :)

  6. So..., I can't download a tarbal or something that has all the files you guys are having on your servers, so I can make my own server (wampserver) host a copy and thus function the same way?, this isn't opensourced like ownCloud is?

    I am a little bit confused