How Firedown protects your data
Last reviewed: October 1, 2026Firedown has no accounts and keeps no record of what you browse or download. Bookmarks and backups are encrypted on your phone before they leave it, with keys only you hold.
At a glance
- No account. No email, no password. A recovery code generated on your phone is the only key, and it never leaves the phone.
- Nothing in between. Downloads go straight from the site to your phone. No server of ours sees them.
- Encrypted before it leaves. Backups and bookmark sync are encrypted on your phone. Our servers store bytes they cannot read.
- What we can see. Sizes, counts and times of what you back up. Never names or contents.
01 Across the app
- Browsing. Firedown is built on Firefox's GeckoView engine with uBlock Origin inside, so ads and trackers are blocked before they load. Nothing about what you browse is sent to us.
- Downloads. Files come straight from the site to your phone, with no server of ours in between, so there is nothing for us to log.
- Sending to another phone. A finished download can go directly to another phone, end-to-end encrypted over WebRTC, with nothing stored on a server.
- Safe Folder. Files you move there sit behind your PIN or fingerprint, invisible to every other app. It stays on your phone and is never part of Cloud Backup.
- Bookmark sync. Free and off by default. Bookmarks are encrypted on your phone under your recovery code before they are uploaded.
- Updates. Every build is signed with the same key and can be checked against our GitHub releases. Once a day the app asks whether a newer version exists; that request carries the app version and a token that changes every month, and is used only to count active installs.
02 Cloud Backup assumes the server is compromised
Cloud Backup keeps an encrypted copy of the downloads you choose and restores them on any phone that has your recovery code. Nothing is uploaded until you ask, and you pay only for the storage you use.
It is designed as if our server were breached, seized, subpoenaed or misconfigured by us. In each case your files stay unreadable, because the server never holds anything that can decrypt them.
03 Your recovery code is the whole key
There is no account, no email and no password. Your phone generates a recovery code and derives every key from it.
The code is never sent anywhere: not when backing up, not when restoring, not when pairing a browser. We hold no copy and cannot produce one.
04 What happens when you back up a file
- A fresh key is generated for that file alone. No single key unlocks the whole backup.
- The file is encrypted on your phone, in pieces. Each piece is tied to its place in that file, so pieces cannot be swapped, reordered or moved between files.
- The pieces upload straight to the storage provider. No server of ours ever sees anything readable.
- The file's key is locked with one derived from your recovery code and stored beside the file, useless without the code.
- The index (names, types, dates, previews) is encrypted as one block. We hold it and hand it back; we cannot open it.
Restoring runs the same steps in reverse, on your phone. No key exists anywhere else.
- Name
- Type
- Size
- 18.9 MB · still visible
- Saved
- 14 Jul 2026, 09:12 · still visible
This is what leaves your phone. Name and type travel inside the encrypted index; size and time cannot be hidden.
05 What we can and cannot see
Encryption hides what a file is, not that it exists.
We can see
- How large each file is
- How many files you have
- When you backed them up or restored them
- The IP address you connected from
- How much storage credit you hold
We cannot see
- File names
- File contents
- Thumbnails or previews
- What type of file anything is
- Which site a download came from
- Anything you have not backed up
| Object | Size | Stored |
|---|---|---|
| a3f9c2…7e10 | 8,388,642 bytes | 14 Jul 2026, 09:12 |
| b71d04…9fa3 | 8,388,642 bytes | 14 Jul 2026, 09:12 |
| c0e5aa…12b8 | 2,104,331 bytes | 14 Jul 2026, 09:13 |
Those three pieces are everything we store for the 18.9 MB file above: no name, no type. Sizes and times are real signals, and encryption does not remove them.
06 Paying without being identified
Paying for storage usually ties a person to an account. Here it does not.
Credit is issued as an anonymous token via a blind signature: the payment system signs it without seeing what it signs. A payment can be verified as genuine but cannot be linked to the account that spends it. We could not produce that link if asked, because it is never created.
There is no card option: credit is paid in Bitcoin, over Lightning or on-chain, so no card processor ever sees a payment.
07 Opening your backup in a browser
To open your backup on a computer, scan a code with the app. The app sends that one browser session the storage keys, encrypted so only that session can read them. A login token would not be enough: the browser needs the keys to decrypt your files.
Your recovery code never travels. A paired browser reaches your backed-up files and nothing else; it cannot re-derive the code, and the keys are erased when you sign out or close the tab.
Both screens show the same six digits before the keys are handed over. If they differ, choose They don't match.
08 What this does not protect against
- A compromised phone. Encryption happens on your device, so a compromised device has the files in the clear. Nothing server-side fixes that.
- A lost recovery code. Unrecoverable, by anyone.
- Metadata. Sizes, counts and times of your backups are visible to us, and could not be hidden without a far more expensive design.
- Files you never backed up. Cloud Backup covers only what you back up. The Safe Folder stays on your phone and is never included.
09 Check it yourself
Encryption, key derivation and the pairing handshake all run in the apps, not on the server. Every claim here can be checked from the client alone.
| File | What it does |
|---|---|
| sync/crypto/SyncIdentity.java | derives every key from the code |
| sync/crypto/VaultCrypto.java | per-file encryption |
| sync/crypto/BookmarkBlob.java | the encrypted index |
| sync/crypto/Canonical.java | request signing |
| sync/crypto/PairSeal.java | browser pairing |
| sync/crypto/BlindSignature.java | anonymous payment tokens |
Audits. Firedown has not had an independent security audit. The code is reviewed internally, including AI-assisted review, and every claim on this page maps to a file in the public source above.
Read the source on GitHub, and see our Privacy Policy for what is stored and by whom.
Report security problems privately to [email protected]. The app repository's SECURITY.md has the details.