Introducing TempFile: A Solution for Protecting Privacy in File Sharing

Introducing TempFile: A Solution for Protecting Privacy in File Sharing

File sharing has gradually become a necessary part of our everyday lives. Whether for work or personal use, we rely on various web and mobile applications to send and receive files. The process would usually involve uploading our content to a remote server that is owned by a given company. With the increasing amount of sensitive information being shared, security and privacy have become major concerns. We have to assume that the file-sharing service provider:

  • will not peek into our uploaded files

  • will secure their servers so that our files don't end up stolen as part of a data breach

With this blog post, I would like to introduce a secure file-sharing service called TempFile - This is a side project I've been working on in my spare time. TempFile is a file transfer service that prioritizes security and privacy above all else. Its main goal is to enable users to share their files with confidence, knowing that they are protected and their privacy is maintained. To achieve its goal, the service uses end-to-end (a.k.a. zero-knowledge) encryption before uploading files to the remote server. The process is visualized below:

As seen from the diagram, shared files are first encrypted (on the client's browser) before leaving their machine. The password used to encrypt the data is either auto-generated or chosen by the client. What gets uploaded on the remote server is the encrypted file content which can only be decrypted by clients who know the chosen (or auto-generated) password. Not even I, as a service provider, can decrypt the uploaded files. Even in an unexpected situation when the remote server is compromised, all that hackers might be able to see is encrypted data which they cannot decrypt without knowing the password. The password is never stored on or transferred to the remote server. To share the uploaded files, clients use an auto-generated link. If no client password was provided, the auto-generated one is encoded in the shareable link. These links are non-recoverable and must only be shared with the intended recipients of the uploaded files (DO NOT LOSE YOUR TEMP FILE LINKS). The uploaded files can then be decrypted on the recipient's machine.

At this point, you might be wondering why is the project called TempFile. It's all connected to another significant feature of the service I want to introduce - namely customizable retention policy. Clients have total control over how long their encrypted files sit on the remote server. This is achieved by setting:

  • either the expiry date of the uploaded file - i.e. a date and time after which the file gets automatically deleted from the remote server

  • or the maximum number of downloads allowed for the uploaded file - i.e. how many times this file can be downloaded by other users; after this count is reached, the file gets automatically deleted from the remote server

This is the reason why uploaded files are called temp files. The intention is that they are only temporarily uploaded remotely with the purpose of being shared with other users and after that they must be deleted by the service itself.

Overall, TempFile offers a secure and convenient solution for file sharing. Its end-to-end encryption and retention policy options provide users with peace of mind knowing that their shared files are protected and will not remain on the internet forever.

As of now, TempFile is still in very early Beta stage which means that it still has its limitations (e.g. file uploads are limited to a maximum of 2GB, might be less depending on your browser), but it should be fully functional and ready for use. In my spare time, I will keep working on improving the service and fixing any unexpected problems or bugs as well as adding more features that I had in mind when I first started the project. If you expirience any problems with the service or you have any feedback and suggestions on how to make the service better, please share these with me either in the comments section of this blog post or privately by emailing