Centre de confiance
Sécurité, confidentialité, conformité
Filarr est conçu pour que vos fichiers soient chiffrés sur votre appareil avant tout envoi — la clé ne quitte jamais votre navigateur. Nous ne pouvons donc ni lire, ni analyser, ni remettre vos contenus à qui que ce soit. Cette page documente exactement ce que cela implique, et ce que nous ne pouvons pas faire.
Le modèle zero-knowledge
Chaque fichier est chiffré avec AES-256-GCM dans votre navigateur. Pour un partage Filarr Send, la clé voyage dans le fragment d’URL (#) — la portion d’un lien que les navigateurs n’envoient jamais au serveur (RFC 3986). Pour une demande de fichier (File Request), le déposant scelle sa clé vers votre clé publique X25519, elle aussi transmise par le fragment du lien. Nos serveurs ne stockent que du chiffré opaque et des métadonnées.
Ce que nous pouvons — et ne pouvons pas — faire
C’est la conséquence directe du chiffrement de bout en bout. C’est aussi notre engagement.
- ❌ Lire le contenu de vos fichiers — impossible, nous n’avons pas la clé.
- ❌ Analyser/scanner vos fichiers côté serveur (y compris pour la modération automatique ou l’eDiscovery).
- ❌ Récupérer un fichier dont la clé (dans le lien) a été perdue.
- ❌ Remettre un contenu en clair à un tiers, y compris sur réquisition — nous ne l’avons jamais en clair.
- ✅ Fournir des métadonnées limitées (horodatage, pays + sous-réseau /16, jamais l’IP complète) en réponse à une demande légale valide.
- ✅ Révoquer et supprimer un partage par identifiant sur signalement (voir Trust & Safety).
Résidence des données
Vos fichiers sont chiffrés de bout en bout avant de quitter votre appareil : l’hébergeur ne peut rien en lire, où qu’il les range. Ils sont stockés sur Cloudflare R2, dans la région « Europe de l’Ouest » de Cloudflare — un indice de localisation, sans juridiction contraignante (cette région peut inclure le Royaume-Uni) ; la base de données des comptes est servie depuis la même région. Cloudflare est une société américaine ; l’argument déterminant n’est donc pas la localisation, mais le fait que le chiffrement de bout en bout neutralise toute injonction (y compris le CLOUD Act) portant sur le contenu : ce qui est remis ne peut être que du chiffré illisible. La liste complète de nos sous-traitants et de leurs localisations est publique.
→ Liste publique des sous-traitants
RGPD & conformité
Pour les données de compte (e-mail, facturation), Filarr est responsable de traitement. Pour les fichiers et métadonnées traités pour le compte d’un client professionnel, Filarr agit comme sous-traitant : un accord de traitement (DPA, article 28 RGPD) est disponible et signable sur demande.
Droits des personnes (accès, rectification, effacement, opposition, portabilité) : écrivez à contact@filarr.com. Vous pouvez aussi supprimer un partage à tout moment depuis « Mes partages », sans compte.
Trust & Safety
Le chiffrement de bout en bout rend impossible tout scan de contenu côté serveur — nous l’assumons. Pour le contenu illégal, un mécanisme de signalement (aligné sur le mécanisme de notification du DSA, art. 16) est présent sur chaque page de réception et de dépôt : il agit sur l’identifiant et les métadonnées du lien, jamais sur le contenu. Un dépôt anonyme est protégé par une preuve de travail (proof-of-work) et des quotas par adresse, et tout partage peut être retiré sur signalement fondé.
Sécurité & divulgation responsable
- Architecture cryptographique & modèle de menace
- security.txt (divulgation responsable, RFC 9116)
- Code source du client desktop publié (BSL 1.1 → Apache 2.0 le 19 avril 2030) — lisible et compilable. Le terme exact est « source available » : jusqu’à cette date, la licence restreint certains usages en production et ne répond donc pas à la définition open source de l’OSI.
Une vulnérabilité ? Écrivez à contact@filarr.com. Merci de nous laisser un délai raisonnable avant toute divulgation publique.
Intégrité des binaires
Chaque version Windows est signée Authenticode (certificat SSL.com, SHA-256), et le condensat SHA-512 de l’exécutable est recalculé après signature puis publié avec la release — vous pouvez le comparer avant d’installer. La notarisation Apple n’est pas encore en place : sur macOS, l’application est distribuée hors Mac App Store et Gatekeeper affichera un avertissement. Nous préférons l’écrire ici plutôt que de vous laisser le découvrir.
Garde-fous du stockage personnel
Quand vous branchez votre propre bucket, l’adresse que vous fournissez est validée avant toute connexion : HTTPS obligatoire, pas d’identifiants dans l’URL, et refus des adresses internes — boucle locale, plages privées RFC 1918, lien-local et points de métadonnées des hébergeurs cloud, y compris sous leurs écritures décimales ou hexadécimales et leurs équivalents IPv6. Les redirections ne sont jamais suivies, et un seul endpoint personnalisé est accepté par période de sept jours. Ces règles existent pour qu’un champ de configuration ne devienne pas un moyen de faire parler notre infrastructure.
Voir aussi : Confidentialité · CGU · Mentions légales