Sécurité et confidentialité

Pas de comptes, pas de connexion

encrypt.click n'a ni comptes utilisateurs, ni connexions, ni profils. Vous n'avez pas besoin de vous inscrire ni de fournir d'informations personnelles pour utiliser les outils.

Outils dans le navigateur

Les utilitaires développeur et confidentialité (hachage, génération de clés, encodage, aides locales, etc.) s'exécutent dans votre navigateur via Web Crypto et d'autres API locales. Leurs entrées ne sont pas envoyées à encrypt.click pour traitement.

Lorsqu'un outil a besoin de données publiques que vous déclenchez (par ex. le hasard Drand pour Time Capsule via notre proxy same-origin), la requête n'inclut pas vos secrets en clair ni vos mots de passe.

Partage chiffré de messages et de fichiers

Encrypt & share exécute AES-GCM dans votre navigateur avant tout envoi. Le mot de passe reste sur votre appareil sauf si vous le copiez ou l'envoyez vous-même.

L'upload automatique préfère le stockage de ciphertext first-party (upload.encrypt.click). Ce chemin est limité (environ 50 Mo) et la disponibilité est garantie environ 24 heures. En cas d'échec, le navigateur n'envoie que du ciphertext à l'API d'upload d'encrypt.click, qui peut le relayer côté serveur vers des hôtes temporaires compatibles Send. Ces hôtes devraient voir le ciphertext et la sortie serveur - pas un upload direct de clair depuis le navigateur.

Les destinataires ouvrent des liens sur encrypt.click (souvent /u). Le matériel chiffré peut être dans le fragment d'URL (non envoyé à nos serveurs lors d'un chargement normal) ou pointer vers un ciphertext uploadé. Un enrobage PNG optionnel peut cacher le lien dans une image pour un partage hors ligne.

Chat, appels, tableau blanc et fichiers chiffrés

Les messages de chat, indicateurs de saisie et la signalisation d'appel sont chiffrés dans le navigateur (AES-GCM) avant d'atteindre le relais PartyKit. Le relais transmet du ciphertext et ne stocke pas l'historique du chat.

Les appels en direct utilisent WebRTC avec une politique ICE TURN-only afin de ne pas échanger directement les IP des pairs. Les médias sont protégés par DTLS-SRTP entre participants ; TURN ne relaie que des paquets chiffrés. Les identifiants TURN viennent d'encrypt.click (/api/turn).

Les pièces jointes du chat sont chiffrées côté client avant upload, avec la même approche ciphertext-first qu'Encrypt & share (stockage first-party si disponible, sinon relais serveur du ciphertext uniquement).

Sans mot de passe de salle, la clé est dérivée du seul nom de salle. Quiconque devine ce nom peut rejoindre et déchiffrer. Les relais peuvent tout de même observer la présence et le timing des métadonnées même si les payloads sont chiffrés.

Le tableau blanc utilise la même infrastructure temps réel pour les traits et l'état collaboratifs. Traitez l'accès comme pour le chat : mot de passe fort pour tout ce qui est sensible.

Raccourcissement d'URL optionnel

Si vous raccourcissez un lien de partage, le navigateur appelle /api/shorten sur encrypt.click. Le backend interroge ensuite le raccourcisseur choisi côté serveur.

Le raccourcisseur reçoit l'URL complète. Pour les liens chiffrés, cela peut inclure des métadonnées du payload chiffré. Pour une confidentialité maximale, évitez les raccourcisseurs tiers pour les liens sensibles.

Les liens courts partagés peuvent rester sur un domaine encrypt.click. À l'ouverture, encrypt.click peut résoudre le raccourcisseur côté serveur et rediriger vers une URL encrypt.click, de sorte que le raccourcisseur voit surtout l'infrastructure plutôt que le navigateur du visiteur - tout en pouvant journaliser qu'un lien chiffré donné a été résolu.

Cookies et stockage local

Le site ne dépose pas de cookies de suivi ou d'analyse et n'utilise pas de trackers tiers ni de pixels publicitaires. Le navigateur peut utiliser localStorage pour les préférences (thème, langue) et, pour le chat avec historique local, des enveloppes de messages chiffrées sur l'appareil. Session storage peut conserver brièvement un mot de passe de salle à l'entrée.

Cloudflare (hébergement) peut déposer des cookies de sécurité et anti-abus selon le trafic et les réglages du navigateur, selon les politiques de Cloudflare.

Sécurité réseau et transport

• Tout le trafic est servi en HTTPS avec un TLS moderne.
• HTTP Strict Transport Security (HSTS) est activé avec includeSubDomains et preload.
• Content Security Policy (CSP) restreint scripts, styles, polices et connexions ; des hashs de scripts inline remplacent un large unsafe-inline pour les scripts.
• Le framing est désactivé via frame-ancestors 'none' et X-Frame-Options: DENY.
• Une vérification d'intégrité du déploiement côté client compare les assets du build à un manifeste publié et, si possible, au dernier commit main sur GitHub.

Infrastructure tierce

Le site est hébergé sur Cloudflare Pages. Le chat et le tableau blanc temps réel utilisent PartyKit. Le relais d'appel peut utiliser Cloudflare TURN et/ou d'autres fournisseurs TURN configurés. Des hôtes de ciphertext temporaires (instances compatibles Send) peuvent recevoir des blobs chiffrés si l'upload first-party est indisponible.

encrypt.click ne tient pas sa propre base des entrées des outils. La limitation d'abus des API utilise un hash salé d'IP en mémoire pour une courte fenêtre (environ 60 secondes). Cloudflare peut aussi appliquer des protections bot/challenge selon ses politiques.

Divulgation responsable

Si vous pensez avoir trouvé un problème de sécurité ou de confidentialité sur encrypt.click, écrivez à mail@encrypt.click. Donnez assez de détails pour reproduire et évitez les tests qui pourraient affecter d'autres utilisateurs.

Résumé non juridique

Cette page est un résumé lisible de la façon dont encrypt.click est conçu pour traiter les données. Ce n'est pas un contrat ni des conditions d'utilisation complètes. Aucune garantie de sécurité parfaite n'est donnée ; vous utilisez les outils à vos risques.