Filarr Sharing arrive : partage de fichiers chiffré end-to-end, avec ou sans compte

Réponse rapide. Filarr permet désormais de partager n'importe quel fichier de votre vault sous forme de lien. La clé de déchiffrement vit dans le fragment URL (la partie après le #) que les navigateurs n'envoient jamais au serveur. Les serveurs Filarr ne peuvent littéralement pas déchiffrer votre fichier — ils ne voient que des octets chiffrés opaques. Il y a aussi Filarr Send sur filarr.com/send pour partager sans compte : mêmes garanties de chiffrement, aucune inscription requise.

Il y a deux semaines, Filarr ne savait pas partager un fichier. Si vous vouliez envoyer un document chiffré à quelqu'un, vous l'exportiez depuis Filarr, le chiffriez à nouveau avec autre chose, et vous vous arrangiez avec le destinataire pour qu'il sache comment le déchiffrer.

Aujourd'hui — 17 mai 2026 — le partage de fichiers arrive. Deux variantes :

1. Partage depuis l'app Filarr desktop si vous avez un compte. Clic droit sur n'importe quel fichier, obtenez un lien, choisissez l'expiry et les options, envoyez.
2. Filarr Send si vous n'en avez pas. Déposez un fichier sur filarr.com/send, récupérez le même lien chiffré, aucun compte requis.

Dans les deux cas, la même garantie de chiffrement end-to-end : le fichier est chiffré sur votre appareil avant l'upload, la clé de déchiffrement n'arrive jamais sur les serveurs Filarr, le destinataire télécharge et déchiffre dans son propre navigateur. Cet article explique comment l'astuce fonctionne, ce qu'on voit côté serveur (presque rien), et quels sont les compromis.

Comment fonctionne l'astuce de l'URL ?

Toute l'architecture repose sur un détail du HTTP auquel la plupart des gens n'ont jamais pensé : le fragment URL (#) n'est jamais envoyé au serveur.

Quand vous tapez filarr.com/s/abc123 dans un navigateur, le navigateur envoie GET /s/abc123 à filarr.com. Quand vous tapez filarr.com/s/abc123#k=cleopaque, le navigateur envoie toujours GET /s/abc123 — la partie #k=cleopaque reste dans la mémoire du navigateur et n'est jamais transmise. C'est défini dans la RFC 3986 §3.5.

Filarr utilise ça pour la clé de partage. Quand vous créez un share :

1. Votre appareil génère une clé aléatoire fraîche de 256 bits (K_share)
2. Chiffre votre fichier avec AES-256-GCM en utilisant cette clé
3. Upload les octets chiffrés vers Cloudflare R2 en Europe
4. Construit une URL comme https://filarr.com/s/abc123#k={K_share_base64}
5. Vous partagez cette URL via le canal de votre choix

Quand le destinataire clique sur le lien :

1. Son navigateur charge filarr.com/s/abc123 (aucune clé envoyée)
2. L'app web Filarr reçoit cette requête, retourne la page destinataire
3. Le JavaScript dans la page lit la clé depuis window.location.hash
4. Le navigateur télécharge les octets chiffrés depuis le serveur
5. Le navigateur déchiffre en mémoire avec la clé

Vue du serveur Filarr : un blob chiffré opaque et un ID de share. Pas de clé, pas de texte en clair, pas de nom de fichier. Même si toute notre infra était compromise demain, l'attaquant n'aurait que du bruit chiffré. C'est ce que « zero-knowledge » signifie en pratique — voir le chiffrement zero-knowledge expliqué pour le modèle approfondi.

Que voit réellement le serveur ?

Liste honnête. Le serveur Filarr (le Worker Cloudflare qui gère les shares) voit :

• Les octets du blob chiffré (opaques pour lui — AES-256-GCM)
• L'ID du share
• Le timestamp d'expiry, le compteur de max-downloads
• Pour les entrées d'audit log : le code pays (depuis la géolocalisation IP de Cloudflare) et le sous-réseau /16 du destinataire (par exemple 192.168.x.x)
• Votre ID de compte, si vous utilisez le partage authentifié
• Un hash de l'IP du créateur, pour Filarr Send anonyme (pour rate-limit et traceback DMCA)

Le serveur ne voit jamais :

• Le contenu du fichier (chiffré avant l'upload)
• Le nom du fichier (le manifest est aussi chiffré ; le serveur voit manifest.enc, pas rapport.pdf)
• La taille exacte du fichier en clair (les chunks sont uniformes en 16 Mo)
• La clé de déchiffrement (elle est dans le fragment URL, jamais transmise)
• Votre mot de passe si vous protégez le share par mot de passe (juste un dérivé HKDF stretché — le serveur stocke un salt mais jamais le mot de passe)
• L'IP complète du destinataire (on garde uniquement le sous-réseau /16 — c'est de la granularité 192.168.x.x, jamais 192.168.1.42)

C'est appliqué dans le code, pas par politique. Il n'y a pas de « faites-nous confiance » — l'architecture cryptographique rend le déchiffrement côté serveur mathématiquement impossible.

Comment fonctionne l'option mot de passe ?

Si vous cochez « protéger par mot de passe » à la création du share, le lien contient toujours une clé dans le fragment, mais elle n'est qu'une moitié du matériel de déchiffrement. La vraie clé de déchiffrement est calculée comme :

K_actual = HKDF-SHA-256(K_share || password, salt, "filarr-share-v1")

Le salt est aléatoire par share, stocké sur le serveur (sans le mot de passe). Le destinataire a besoin à la fois de l'URL et du mot de passe pour déchiffrer. Le brute-force est rate-limité au niveau du Worker + ralenti par le coût HKDF. Sans le mot de passe, l'URL seule est inutile.

C'est une couche significative si vous craignez que l'URL fuite via screenshots, historique navigateur, post Slack accidentel, etc. Le lien seul ne suffit pas.

Attention : le plan Free ne peut pas utiliser l'option mot de passe — c'est Solo/Pro seulement (et sur la page Filarr Send anonyme). C'est un choix de pricing volontaire.

Qu'est-ce que Filarr Send, exactement ?

Un second mode livré en même temps. Filarr Send est pour les gens qui n'ont pas de compte Filarr mais veulent envoyer un fichier chiffré ponctuellement.

Allez sur filarr.com/send, drag-droppez un fichier, configurez expiry/password/max downloads, récupérez un lien. Même architecture E2EE que le mode authentifié — votre navigateur fait tout le chiffrement côté client, le Worker Cloudflare ne voit que des chunks chiffrés.

Limites pour le Send anonyme :

• Taille max fichier : 2 Go
• Expiry max : 7 jours
• Téléchargements max : 10
• 5 sends actifs max par IP par 24h (rate-limit, IP hashée en SHA-256)
• Option mot de passe disponible

C'est le créneau WeTransfer / Wormhole / Firefox Send, mais avec un vrai E2EE que le service ne peut pas casser. Utile quand vous êtes sur un ordinateur d'hôtel, sur le laptop d'un ami, ou que vous ne voulez juste pas créer un autre compte.

Que peut voir le propriétaire d'un share (audit log) ?

Les shares authentifiés affichent un audit log. Sur la page /shares dans l'app desktop, dépliez « Historique » sur n'importe quel share actif pour voir qui a téléchargé.

Ce que vous voyez :

• Timestamp de chaque téléchargement
• Pays (par exemple France, US — depuis la géolocalisation IP de Cloudflare)
• Sous-réseau /16 (par exemple 89.156.x.x)

Ce que vous ne voyez pas :

• L'adresse IP complète (uniquement /16)
• Le user agent
• Aucun identifiant du destinataire

Le sous-réseau /16 est un compromis : assez précis pour repérer « ça a été téléchargé 12 fois depuis 5 réseaux différents », assez grossier pour qu'on ne logue jamais des IPs identifiantes. Un /16 d'un FAI français couvre environ 65 000 IPs.

L'option « 1 téléchargement par IP »

Pour quand vous voulez un destinataire spécifique. Activez cette option dans le modal de partage, et après le premier téléchargement réussi depuis un sous-réseau /16, les requêtes suivantes depuis le même sous-réseau renvoient 403.

Attention que l'UI vous précise : si votre destinataire est derrière un NAT d'entreprise ou un NAT carrier-grade (réseaux mobiles, gros bureaux), il partage la limite avec tout le monde sur ce NAT. Si plusieurs collègues doivent récupérer le fichier, n'utilisez pas cette option.

Quelles sont les limites par plan ?

	Anonyme (Send)	Free	Solo (4 €/mo)	Pro (8 €/mo)
Taille max fichier	2 Go	1 Go	10 Go	50 Go
Expiry max	7 jours	14 jours	90 jours	1 an
Shares actifs max	3/IP	10	100	illimité
Téléchargements max par share	10	50	1 000	illimité
Protection mot de passe	✓	✗	✓	✓
Audit log	✗	✓	✓	✓
1-téléchargement-par-IP	✗	✓	✓	✓
Révoquer / annuler	✗	✓	✓	✓

La progression est intentionnelle : anonyme est le mode « j'essaie une fois » (proche de l'offre WeTransfer), Free vous donne un vrai compte et des shares persistants, Solo et Pro sont pour l'usage professionnel où il faut des gros fichiers et des longues durées.

Cas d'usage réels

Scénarios concrets où c'est utile.

Un designer qui livre un projet. Les livrables finaux sont lourds — archives InDesign, vidéo brute, PSDs avec layers. Email ne passe pas, WeTransfer expire en 7 jours sans chiffrement, Google Drive voit tout. Filarr Pro : 50 Go par fichier, 1 an d'expiry, protégé par mot de passe.

Un avocat qui envoie un brouillon de contrat. Confidentiel, ne peut pas passer par email standard. Plan Solo : chiffré, password-protégé, 1-téléchargement-par-IP verrouillé sur l'IP du bureau du destinataire.

Un journaliste qui reçoit un leak. La source utilise Filarr Send (pas de compte, pas de traçabilité pour elle), crée un lien 7 jours vers un document unique, envoie l'URL au journaliste via Signal. Le journaliste télécharge depuis une machine propre. Aucun compte Filarr requis des deux côtés.

Envoi depuis un ordinateur d'hôtel. Vous n'avez pas votre laptop, vous devez envoyer un document sensible. Filarr Send : drag-drop dans le navigateur, lien chiffré, envoyé via votre téléphone. Le document ne vit jamais sur l'ordinateur de l'hôtel au-delà de la passe de chiffrement.

Ce dont il faut être conscient

Limites honnêtes.

L'URL contient la clé de déchiffrement. Quiconque a l'URL peut télécharger. Traitez-la comme un mot de passe : ne la postez pas sur Slack, ne la mettez pas dans un sujet d'email, ne la partagez pas sur Twitter. Si vous devez la partager via des canaux non sécurisés, utilisez l'option mot de passe.

L'historique du navigateur capture l'URL complète, fragment inclus. Si vous avez ouvert le lien de partage sur une machine partagée, l'URL peut être dans l'historique de quelqu'un. Utilisez la navigation privée ou videz l'historique quand c'est pertinent.

Les shares Filarr Send ne peuvent pas être révoqués. Une fois le lien sorti, il est sorti — vous pouvez attendre l'expiration ou que les downloads max soient atteints, mais vous ne pouvez pas le tuer manuellement. Les shares authentifiés peuvent être révoqués à tout moment.

La clé de chiffrement pour les shares que vous avez créés est cachée dans le localStorage de votre appareil. Si vous videz les données navigateur sur filarr.com, vous perdez la capacité de re-copier l'URL pour les shares créés depuis cet appareil. Les shares continuent de marcher pour les destinataires qui ont déjà le lien — mais vous ne pouvez plus le reconstituer depuis /shares.

En quoi est-ce différent de Proton Drive ou Tresorit Send ?

Proton Drive propose un partage E2EE similaire mais nécessite que le destinataire interagisse avec l'app web Proton. Leur modèle de clés est différent — ils utilisent l'infrastructure d'identité Proton.

Tresorit Send fait du partage E2EE friendly aux anonymes. Le plus proche analogue de Filarr Send. Leur service est solide ; la différence principale avec Filarr Send est qu'on est une boîte open-core avec notre code client publié sur GitHub — vous pouvez auditer le code de partage. Voyez src/services/sharing/shareCrypto.ts si vous voulez vérifier l'implémentation.

WeTransfer n'est pas E2EE. Votre fichier est chiffré en transit (HTTPS) et au repos avec les clés de WeTransfer, mais ils peuvent le déchiffrer. Le stockage gratuit 7 jours est indexé, scanné pour compliance, etc. Utile, mais ce n'est pas ce que Filarr Send remplace.

Comment je commence ?

Si vous avez Filarr installé : mettez à jour vers v2.10.0+ (Paramètres → Vérifier les mises à jour). Clic droit sur n'importe quel fichier de votre vault → « Partager par lien ». Configurez les options, copiez l'URL, envoyez via le canal de votre choix.

Si vous n'avez pas Filarr : allez sur filarr.com/send, déposez un fichier. Pas d'inscription, pas d'installation, chiffré dans votre navigateur avant l'upload.

Pour aller plus loin

• Le chiffrement zero-knowledge expliqué
• End-to-end vs zero-knowledge
• Qu'est-ce que l'AES-256-GCM et pourquoi ça compte
• L'architecture de sécurité de Filarr
• Page comparatif Sharing
• Filarr Send (essayez sans compte)

Télécharger Filarr — gratuit, chiffré, local-first →