Confidentialité
izzy.share est zero-knowledge par conception. Le serveur ne voit jamais ce que vous partagez.
// ce qui est stocké
- Le chiffré (blob opaque) dans Cloudflare R2 (UE)
- Métadonnées opaques (expiration, ouvertures, e-mail du destinataire haché si fourni) dans Cloudflare KV
- Un journal d'audit (type d'évènement, IP/UA hachés, pays) conservé 90 jours dans Cloudflare D1 (UE)
// ce qui n'est jamais stocké
- Le texte en clair
- Les clés de déchiffrement pour les liens en mode partage (elles vivent uniquement dans le fragment de l'URL, qui n'atteint jamais nos serveurs).
Exception (mode requête) : lorsqu'un client envoie un secret à un utilisateur izzy.share, la clé de chiffrement transite brièvement par le Worker afin que nous puissions l'envoyer par e-mail dans un fragment d'URL au propriétaire de la requête. Le Worker la garde en mémoire le temps de l'envoi de l'e-mail puis l'oublie ; elle n'est ni journalisée ni persistée — voir la note de confiance ci-dessous. - Les adresses e-mail brutes des destinataires (après l'envoi de l'e-mail de notification)
- Les adresses IP ou User-Agent en clair
// effacement
Chaque partage s'efface automatiquement après lecture ou expiration. Les expéditeurs peuvent révoquer manuellement à tout moment.
// mode requête (note de confiance)
Les liens de requête permettent à quelqu'un d'envoyer un secret au propriétaire du lien. Le navigateur du soumissionnaire chiffre localement — le serveur ne voit toujours pas le texte en clair — mais la clé AES doit parvenir au propriétaire d'une manière ou d'une autre. Nous le faisons en lui envoyant par e-mail une URL d'inbox à usage unique avec la clé dans le fragment d'URL :
https://share.izzy.agency/app/inbox/<id>#k=<keyB64u>&iv=<ivB64u>Le serveur conserve la clé en mémoire du Worker uniquement pendant la durée d'une requête de soumission (le temps d'appeler le fournisseur d'e-mail) puis l'oublie. Elle n'est jamais persistée dans nos bases de données ou logs.
La frontière de confiance se déplace vers votre boîte de réception. Si votre e-mail est compromis (ou si votre fournisseur reçoit une demande aimable), la soumission est compromise aussi. Le même principe s'applique aux URL d'inbox transférées. Traitez l'e-mail comme une clé à usage unique — ouvrez-le depuis un appareil sûr, puis laissez-le expirer ou supprimez-le. Des options de défense en profondeur (phrase secrète, Turnstile) sont en cours d'ajout.
// envoi par e-mail du lien de partage
Lors de la création d'un partage, l'émetteur peut cocher « envoyer l'URL directement au destinataire ». Lorsque cette option est activée, le navigateur de l'émetteur transmet la totalité de l'URL — fragment compris — au Worker, qui la passe immédiatement à Resend :
https://share.izzy.agency/en/s/<id>#k=<keyB64u>&iv=<ivB64u>Le Worker conserve l'URL en mémoire le temps d'un seul appel HTTP, puis l'oublie. Elle n'est pas écrite dans D1, KV, R2 ni les logs. Le seul fait audité est qu'un évènement share_url_emailed a eu lieu pour cet identifiant de partage — sans URL, sans adresse en clair.
Même frontière de confiance que le mode requête : la boîte de réception du destinataire devient le coffre-fort. Si vous préférez livrer le lien hors-bande (Signal, en personne, votre propre canal chiffré), décochez simplement la case et l'URL ne quittera jamais votre navigateur.
Vous pouvez ajouter une phrase secrète optionnelle dans le formulaire de création — elle est hachée dans votre navigateur (PBKDF2) et sert de second facteur que le destinataire doit saisir avant d'obtenir le contenu chiffré.
// protection anti-bot (Cloudflare Turnstile)
Sur les pages publiques /auth/login et /[lang]/r/[id], izzy.share utilise Cloudflare Turnstile en mode invisible pour ralentir les robots qui pourraient inonder l'émetteur de liens magiques ou les liens de requête. Turnstile collecte des signaux du navigateur pour distinguer les humains des automates. Aucun déchiffrement ou contenu de partage ne lui est transmis — uniquement les signaux nécessaires au défi.