Summary
With several file-sharing tools, you’re caught between two options: tools where the company may be able to read what you send, or clumsy processes that force you to email the file instead. However, Firefox Send included a third option where files are encrypted in the browser before upload, and Mozilla didn’t hold decryption keys. Sadly, it was shut down in 2020. Even though there are several replacements today, the reason Firefox Send disappeared still speaks volumes about the services that replaced it. Firefox Send put the key where Mozilla couldn’t read it Your browser encrypted the file before it ever left your computer Firefox Send did a good job by encrypting anything you sent with 128-bit AES-GCM within the browser before it left your device. The key used to encrypt and decrypt was a fragment of the share link that followed the #. This part of the link is never sent to servers during normal requests. That meant Mozilla received the encrypted file, encrypted metadata, and a signing key, but not the secret used to decrypt the file. The secret to decrypt it remained in the link. This isn’t the same as the padlock that is displayed in the address bar. Typically, HTTPS protects the trip between your browser and the service, while Send sealed files before Mozilla stored them. So even though the company hosts and delivers the encrypted package, it doesn’t have the key to decrypt the file. Other elements of the Firefox Send design were simple enough for the regular person to use. It let users set an expiration date, specify the number of downloads per link, or, if needed, add a password. For files under 1GB, you didn’t need an account, but creating one increased the sending limit to 2.5GB. On the other hand, the recipient is simply opening a regular link, and the files are decrypted. It was efficient for anyone who needed to send a sensitive PDF once without having a copy of it left stored in the cloud. It pretty much was the ideal sending option of the time. The same simplicity that made Send useful also made it attractive to attackers Mozilla wasn’t fighting broken encryption; it was fighting abuse Mozilla took the service offline in the summer of 2020. Firefox Send was a convenient option for attackers to distribute malware, and one of the more effective ways of running spear-phishing campaigns. The temporary links and familiar Mozilla domain made it a convenient delivery path for malicious files. On September 17, 2020, it shut down permanently. While no one claimed it cracked encryption, the problem lay in the surrounding design. It had traits like easy links, short lifetimes, and minimal barriers. These are great for anyone who prioritizes private sharing but also attractive to people who want to deliver malicious files. Mozilla’s plans to implement account requirements and abuse reporting never materialized. When the company considered where it needed to focus and the cost of its overall portfolio, it decided against bringing the service back, and Mozilla wiped everything stored on its servers. Elegant cryptography is great, but doesn’t automatically make a free, low-friction public service easy to keep running. It takes a lot of infrastructure and attention to stay useful to real users while resisting abuse. “Encrypted” doesn’t tell you who can read the file The architecture is more significant than the marketing label Many services still claim to encrypt files, but many leave several important questions unanswered.
- Where does the encryption actually happen?
- Who holds the decryption key?
- Can the provider itself open the file?
- Does the link expire or stop after a set number of downloads?
- Does the other person need an account?
- How long does the encrypted copy sit on the server? A service encrypting connections doesn’t guarantee that it can’t read the file when it arrives. Padlocks on the browser address bar give information about the trip without any visibility on who can open the package on arrival. Firefox Send answered those questions clearly. Encryption took place within your browser before the files were uploaded. Mozilla wasn’t holding the decryption secret. There were built-in download limits and expiration, and no account requirements for the recipient. | What matters | Typical cloud sharing | Firefox Send’s design | |---|---|---| | Encrypted during transfer | Yes | Yes | | Encrypted before upload | Depends | Yes | | Provider can decrypt | Often | No | | Expiring / limited downloads | Sometimes | Core feature | | Recipient needs an account | Often | No | If you assume that privacy and convenience are separate problems, you may be wrong. Most people lean towards the easier option the moment a secure option is noticeably harder than attaching files to an email or generating a regular cloud link. What’s more important than a service using encryption is where the keys sit and how much reach the provider has. Firefox Send died, but its best idea survived Thunderbird brands its Send project as a Firefox Send rebirth. It’s rebuilding a lot of the implementation to include more direct user-to-user sharing. After its 2025 security audit with OSTIF, the issues noted were addressed. There are still a few community instances of the original Firefox Send. If you use any, it’s good to bear in mind that a fork doesn’t necessarily mean the same service, and a public instance can only be trusted to the extent you trust the person behind it. The lasting lesson that Firefox Send proved is that real privacy can feel ordinary. No one needed to understand keys or infrastructure to use Firefox Send. The problem is making this simplicity work at scale.