Firedown Retour
Sécurité

Comment Firedown protège vos données

Dernière révision : 18 octobre 2026

Firedown n’a pas de comptes et ne garde aucune trace de votre navigation ni de vos téléchargements. Les favoris et les sauvegardes sont chiffrés sur votre téléphone avant de le quitter, avec des clés que vous seul détenez.


En bref


01 Dans toute l’application


02 La sauvegarde vit dans le stockage de votre choix

La sauvegarde conserve une copie chiffrée des téléchargements que vous choisissez. Vous choisissez l’endroit une seule fois : un dossier, avec le sélecteur de dossiers d’Android lui-même (dans Google Drive, Dropbox ou Nextcloud, une carte SD ou le stockage du téléphone), un serveur WebDAV auquel vous vous connectez (Nextcloud, ownCloud, un NAS), ou un bucket S3 dont vous donnez les clés à Firedown (Backblaze B2, Cloudflare R2, Wasabi, MinIO). Dans un dossier, Firedown écrit les fichiers chiffrés et l’application du fournisseur les synchronise comme elle synchronise tout le reste. Vers un serveur ou un bucket, Firedown les envoie lui-même.

Aucun serveur Firedown ne se trouve sur ce chemin, et rien de ce que vous sauvegardez, ni de l’endroit, ne nous est envoyé. Dans un dossier, Firedown ne peut accéder qu’au seul dossier que vous avez choisi, à rien d’autre dans votre Drive ou sur votre carte. Sur un serveur ou dans un bucket, il peut accéder à tout ce que permettent la connexion ou les clés ; c’est pourquoi il demande une clé limitée à un seul bucket. Les identifiants restent sur votre téléphone, chiffrés, et ne sont jamais sauvegardés. Choisir un autre endroit oublie l’ancien et laisse ses fichiers là où ils sont.

Elle est conçue comme si le fournisseur pouvait lire tout ce qu’il stocke, ou le remettre à quelqu’un d’autre. Dans un cas comme dans l’autre, vos fichiers restent illisibles, car le dossier ne contient jamais rien qui puisse les déchiffrer.


03 Votre code de récupération est toute la clé

Pas de compte, pas d’e-mail, pas de mot de passe. Votre téléphone génère un code de récupération et en dérive chaque clé.

Le code n’est jamais envoyé nulle part et n’est jamais écrit dans le dossier. Pour lire votre sauvegarde sur un autre téléphone, saisissez-y le même code et choisissez le même dossier, serveur ou bucket. Nous n’en détenons aucune copie et ne pouvons pas en produire.

Perdez le code et vos fichiers sauvegardés sont perdus. Irrécupérables, ni par vous, ni par nous, ni par le fournisseur. Il n’y a pas de lien de réinitialisation, car un tel lien est exactement ce qui laisserait entrer quelqu’un d’autre. Notez-le.

04 Ce qui se passe lors d’une sauvegarde

  1. Une clé neuve est générée pour ce seul fichier. Aucune clé unique n’ouvre toute la sauvegarde.
  2. Le fichier est chiffré sur votre téléphone avec AES-256-GCM, en morceaux. Chaque morceau est lié à sa position dans ce fichier : impossible de les échanger, réordonner ou déplacer entre fichiers.
  3. La clé du fichier est verrouillée par une clé dérivée de votre code de récupération. Elle est placée dans un petit fichier compagnon, chiffrée avec le nom, le type, les dates et l’aperçu.
  4. Les deux fichiers sont écrits sous des noms aléatoires dans votre dossier, sur votre serveur ou dans votre bucket.

La restauration suit les mêmes étapes en sens inverse, sur votre téléphone. Aucune clé n’existe nulle part ailleurs.

Chiffrement sur votre appareil…
Nom
Type
Taille
18.9 MB (toujours visible)
Enregistré
14 juil. 2026, 09:12 (toujours visible)

Voici ce qui quitte votre téléphone. Le nom et le type voyagent dans le fichier compagnon chiffré ; la taille et l’heure ne peuvent pas être cachées.


05 Ce que le fournisseur peut voir, ou non

Celui qui détient votre sauvegarde voit des fichiers, pas ce qu’ils sont. Le chiffrement cache ce qu’est un fichier, pas le fait qu’il existe.

Le fournisseur peut voir

  • La taille de chaque fichier
  • Combien de fichiers vous avez sauvegardés
  • Quand chacun a été écrit
  • Un nom de dossier dérivé de votre code de récupération, qui ne permet pas de remonter au code
  • L’adresse IP depuis laquelle les fichiers sont envoyés
  • Ce qu’il sait déjà grâce à votre compte chez lui

Il ne peut pas voir

  • Les noms de fichiers
  • Le contenu des fichiers
  • Les miniatures ou aperçus
  • Le type de chaque fichier
  • Le site d’origine d’un téléchargement
  • Votre code de récupération, ni aucune clé
Ce que contient le dossier
FichierTailleÉcrit
a3f9c2…7e10.fdvc18,900,102 bytes2026-07-14 09:12
a3f9c2…7e10.entry41,283 bytes2026-07-14 09:12

Ces deux fichiers sont tout ce que le dossier contient pour le fichier de 18.9 MB ci-dessus : un nom aléatoire, pas de type. Les tailles et les horaires sont de vrais signaux, et le chiffrement ne les supprime pas.


06 La synchronisation des favoris et notre serveur

La synchronisation des favoris est la seule fonction qui stocke des données sur l’un de nos serveurs. Vos favoris sont chiffrés sur votre téléphone en un seul bloc, avec une clé dérivée de votre code de récupération. Le serveur stocke ce bloc et le restitue ; il ne peut pas l’ouvrir.

Chaque requête est signée avec une clé dérivée du même code, donc seuls vos téléphones peuvent remplacer vos favoris. Le serveur voit un numéro de compte dérivé du code, la taille du bloc, le moment où il change, et l’adresse IP d’où vient chaque requête.


07 Ce contre quoi cela ne protège pas


08 Vérifiez par vous-même

Le chiffrement et la dérivation de clés s’exécutent dans l’application, pas sur un serveur. Chaque affirmation de cette page peut être vérifiée à partir du seul code source de l’application.

Où regarder
FichierRôle
sync/crypto/SyncIdentity.javadérive chaque clé du code
sync/crypto/VaultCrypto.javachiffrement par fichier
sync/crypto/BookmarkBlob.javales fichiers compagnons chiffrés et les favoris
sync/BackupLayout.javace qui est écrit dans votre dossier, sur votre serveur ou dans votre bucket
sync/S3Settings.javales clés d’un bucket, chiffrées sur votre téléphone
sync/WebDavSettings.javale mot de passe d’un serveur, chiffré sur votre téléphone
sync/VaultEngine.javasauvegarde et restauration d’un fichier
sync/crypto/Canonical.javasignature des requêtes de synchronisation des favoris

Audits. Firedown n’a fait l’objet d’aucun audit de sécurité indépendant. Le code est relu en interne, y compris avec une relecture assistée par IA, et chaque affirmation de cette page correspond à un fichier du code source public ci-dessus.

Lisez le code source sur GitHub, et consultez notre Politique de confidentialité pour savoir ce qui est stocké et par qui.

Signalez les problèmes de sécurité en privé à [email protected]. Le fichier SECURITY.md du dépôt de l’application donne les détails.

Ceci est une traduction de courtoisie. En cas de divergence, la version anglaise de cette page fait foi.