Neat. It uses client-side crypto (AES-128-GCM) to secure the file; the key is in the fragment portion of the URL so it doesn't automatically hit the server (ass

Neat. It uses client-side crypto (AES-128-GCM) to secure the file; the key is in the fragment portion of the URL so it doesn't automatically hit the server (assuming you trust the server JS). The protocol is a little bit strange, though. The file metadata is transmitted as an X-File-Metadata header on upload, and includes the SHA256 hash of the original (unencrypted) file (as the "aad" parameter to the X-File-Metadata upload parameter). This is a little concerning for privacy; while the filename is easy to disguise, hiding the SHA256 sum requires modifying the file in some way. Of course, this might only be a concern for uploading known files, but it's still a bit of an infoleak. It's also strange in that the key isn't checked in any way (even for sanity) before initiating a download, so if you mess up and leave it off (or corrupt some bits), you won't find out until the end of the download that you can't get the file. Worse, the file will be deleted, forcing you to ask your sender for another copy. The client-side crypto has one other downside: there doesn't seem to be a standard way in JavaScript to stream a POST request yet. You could emulate it with e.g. WebSockets, but those are a lot more heavyweight and CPU-intensive (for the server) than simple POST requests. So, the current implementation just encrypts the entire file as one giant block, and then uploads it - placing the whole file in memory. Hence the 1GB soft-limit. Downloads are similarly limited. Luckily, non-browser clients can do whatever they like, so I wrote a Python client that's compatible with the server, but uses streaming POST and on-the-fly en/decryption to save memory. Check it out at https://github.com/nneonneo/ffsend https://github.com/nneonneo/ffsend - feedback welcome!