How Firedown protects your data
Last reviewed: October 29, 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.
- Your storage, our encryption. Backups go to storage you choose: a folder on Google Drive, Dropbox, Nextcloud, an SD card or the phone itself, a WebDAV server, or an S3 bucket. They are encrypted on your phone before they are written there.
- What the provider can see. How many files, how large, and when they were written. 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.
- Signing in to sites. You sign in on the site’s own page, as in any browser. Firedown keeps no passwords: only your password manager can save one, through Android’s autofill. Nothing you type into a site 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. When the two phones cannot reach each other directly, the encrypted stream passes through our relay, which cannot read it.
- 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 backed up.
- 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; its fingerprint, and how to check it, are on the Install page. 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 Backup lives in storage you choose
Backup keeps an encrypted copy of the downloads you choose. You pick where once: a folder through Android's own folder picker (in Google Drive, Dropbox or Nextcloud, an SD card, or the phone's storage), a WebDAV server you sign in to (Nextcloud, ownCloud, a NAS), or an S3 bucket you give Firedown the keys to (Backblaze B2, Cloudflare R2, Wasabi, MinIO). In a folder, Firedown writes the encrypted files and the provider's app syncs them the way it syncs anything else. To a server or a bucket, Firedown uploads them itself.
There is no Firedown server in that path, and nothing about what you back up, or where, is sent to us. In a folder, Firedown can reach only the one folder you picked, nothing else in your Drive or on your card. On a server or in a bucket, it can reach whatever the sign-in or the keys allow, which is why it asks for a key limited to one bucket. The sign-in stays on your phone, encrypted, and is never backed up. Choosing a different place forgets the old one and leaves its files where they are.
It is designed as if the provider could read everything it stores, or hand it to someone else. In each case your files stay unreadable, because the folder 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 and never written to the folder. To read your backup on another phone, enter the same code there and choose the same folder, server or bucket. 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 with AES-256-GCM, in pieces. Each piece is tied to its place in that file, so pieces cannot be swapped, reordered or moved between files.
- The file's key is locked with one derived from your recovery code. It goes into a small companion file, encrypted together with the name, type, dates and preview.
- Both files are written under random names to your folder, server or bucket.
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 companion file; size and time cannot be hidden.
05 What the provider can and cannot see
Whoever holds your backup sees files, not what they are. Encryption hides what a file is, not that it exists.
The provider can see
- How large each file is
- How many files you have backed up
- When each one was written
- A folder name derived from your recovery code, which cannot be turned back into the code
- The IP address the files are uploaded from
- What it already knows from your account with it
It cannot see
- File names
- File contents
- Thumbnails or previews
- What type of file anything is
- Which site a download came from
- Your recovery code, or any key
| File | Size | Written |
|---|---|---|
| a3f9c2…7e10.fdvc | 18,900,102 bytes | 14 Jul 2026, 09:12 |
| a3f9c2…7e10.entry | 41,283 bytes | 14 Jul 2026, 09:12 |
Those two files are everything the folder holds for the 18.9 MB file above: a random name, no type. Sizes and times are real signals, and encryption does not remove them.
06 Bookmark sync and our server
Bookmark sync is the one feature that stores data on a server of ours. Your bookmarks are encrypted on your phone into a single block under a key derived from your recovery code. The server stores that block and hands it back; it cannot open it.
Every request is signed with a key derived from the same code, so only your phones can replace your bookmarks. The server sees an account number derived from the code, the size of the block, when it changes, and the IP address each request comes from.
07 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 in the folder fixes that.
- A lost recovery code. Unrecoverable, by anyone.
- Metadata. Sizes, counts and times of your backups are visible to whoever holds your backup, and could not be hidden without a far more expensive design.
- Linking. If you use bookmark sync, the backup folder's name is the same account number our bookmark server knows. Someone holding both could tell they belong to one person, and still read neither.
- Losing the folder, server or bucket. The provider keeps your backup available, not secret. If it deletes the files or closes your account, or the folder was on a phone or card that is lost, the backup goes with it.
- Files you never backed up. Backup covers only what you back up. The Safe Folder stays on your phone and is never included.
08 Check it yourself
Encryption and key derivation run in the app, not on a server. Every claim here can be checked from the app's source 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 companion files and bookmarks |
| sync/BackupLayout.java | what is written to your folder, server or bucket |
| sync/S3Settings.java | the keys to a bucket, encrypted on your phone |
| sync/WebDavSettings.java | the password of a server, encrypted on your phone |
| sync/VaultEngine.java | backing up and restoring a file |
| sync/crypto/Canonical.java | bookmark sync request signing |
The engine. Firedown’s builds of GeckoView and FFmpeg are public too, with our changes: firedown-geckoview and firedown-ffmpeg.
Ask an AI assistant. Give it this request, then check its answers in the files it cites.
Read the source of the Android app Firedown at https://github.com/solarizeddev/firedown. Its browser engine is at https://github.com/solarizeddev/firedown-geckoview. Answer each question with links to the files that show it: 1. Which servers does the app contact by itself, and what does it send them? 2. Can the app read, store or send the passwords I type when I sign in to a website? 3. Are backups and synced bookmarks encrypted on the phone before they leave it, and who holds the key? 4. Does anything in the code contradict https://www.firedown.app/security or https://www.firedown.app/privacy? Quote the code, and say where you are not sure.
What the source cannot show. Our builds are not yet reproducible, so nothing proves that an APK was built from this source: that rests on our signing key and our word. Our server’s code is not public either; what it holds of your bookmarks, and what passes through the relay, is encrypted by the app, which the source does show.
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.