Firefox Send

» see send.firefox.com as it lived, on the wayback machine

~ the last words ~

by 2019 sending a file to a non-technical person was a small daily problem. dropbox wanted an account on both ends and wetransfer worked but spammed both sides with marketing email. firefox send solved it in one screen. you opened send.firefox.com and dragged a file in. the browser encrypted it in your tab before uploading. you got back a link with the key in the url fragment. you sent the link and the recipient clicked it once. the file was deleted from mozilla's servers as soon as it had been downloaded.

firefox send started august 1 2017 as a mozilla test pilot experiment. it stayed in beta for nineteen months, then mozilla released the public version on march 12 2019 with a 1 gb limit for anonymous users and a 2.5 gb limit for anyone signed into a firefox account. it ran for sixteen months as a real service before mozilla suspended it on july 7 2020 in response to malware operators using it as a payload host. the official shutdown notice went up on september 17 2020 and the send.firefox.com domain stopped serving the app.

mozilla cited two reasons for the kill, the malware abuse pattern and the lack of any reporting mechanism for abusive links. neither was strictly unsolvable. the suspension happened during a broader mozilla restructuring that included 250 layoffs in august 2020, which is the part of the story that is harder to write about. the platform was working. it just was not surviving the company.

~ the record ~

~ how it actually worked ~

the key cryptographic detail was that the encryption key never reached mozilla's servers. the browser generated an aes-256-gcm key in javascript and encrypted the file locally before sending the ciphertext up. the key was placed in the url fragment, which browsers do not send in http requests. so mozilla could host the encrypted blob without ever being able to decrypt it. that meant the company could keep a clean privacy claim while still running the service at scale.

on the receive side the recipient's browser pulled the ciphertext and read the key from the url fragment locally, then decrypted the file in the page. once the configured download count was hit mozilla deleted the ciphertext from storage. anyone clicking the link after that got a "file expired" page. the whole flow took fewer steps than dropbox did and it did not require an account on either side for the smallest file sizes.

~ what killed it ~

the design that made send privacy-preserving also made it perfect for malware delivery. an attacker uploaded a payload and got a fresh url, then sent it inside a phishing email. when the corporate proxy followed the link to inspect it, the proxy counted as the download and the file vanished, so the proxy got a clean response. the user clicked the link separately and got the malware. by mid-2020 multiple security researchers had published reports of send.firefox.com urls inside ransomware and credential-stealer campaigns. mozilla suspended the service on july 7 2020 to add abuse-reporting features. those features never shipped.

~ the next chapter ~

the codebase is open source and survived mozilla. third-party hosted clones appeared within weeks of the shutdown. timvisee/send is the most-used fork as of 2026, run as a community project on a handful of mirrors. thunderbird announced in july 2023 that it would resurrect the service as thunderbird send bundled with the email client, although that had not shipped to public release as of early 2026. the cryptographic design itself, browser-side aes-256-gcm with key-in-url-fragment, became the template for half a dozen smaller encrypted file-share projects that came after.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »