🔍 Transparence technique
Ce que nous voyons.
Ce que nous ne faisons pas.
Ceci n'est pas une page marketing. Il s'agit d'une spécification technique indiquant exactement quelles données City of Hats collectent, à quoi nos serveurs peuvent et ne peuvent pas accéder et où se situent nos limites de cryptage.
Dernière mise à jour : avril 2026🎯 ; Notre position
Nous pensons que la sécurité doit être prouvée et non revendiquée.
City of Hats est une jeune plateforme. Nous avons lancé sur les magasins d'applications en mars 2026. Nous ne sommes pas encore open source. Nous n’avons pas encore réalisé d’audit indépendant. Nous sommes transparents à ce sujet et nous travaillons activement à combler ces écarts. En attendant, voici un compte rendu détaillé de ce que fait réellement notre système.
Notre engagement : Nous publierons le rapport complet de notre premier audit cryptographique indépendant sur cette page. Aucune expurgation.
🛡 Modèle de menace
Ce contre quoi nous protégeons — et ce que nous ne protégeons pas
Aucun système n'est invulnérable. Déclarer ce que nous défendons contre — et où se trouvent nos limites — est plus crédible que de revendiquer une sécurité absolue.
Conçu pour protéger contre
- ✅ Surveillance passive du réseau
- ✅ Accès aux données côté serveur (nous ne pouvons pas lire les messages E2E)
- ✅ Corrélation d'identité via des numéros de téléphone ou des e-mails
- ✅ Futures attaques quantiques (échange de clés PQ hybrides)
- ✅ Compromis clé exposant les messages passés (forward secret)
- ✅ Analyse de la longueur du message (remplissage des métadonnées)
Pas encore formellement évalué par rapport
- ⚠ Adversaires des États-nations
- ⚠ Appareils utilisateur compromis (attaques au niveau du système d’exploitation)
- ⚠ Attaques ciblées avancées
- ⚠ Analyse du trafic à grande échelle (timing, modèles de fréquence)
Conseil honnête : Les utilisateurs présentant des modèles de menaces à haut risque doivent combiner plusieurs outils et pratiques sécurisés. Aucune application ne constitue à elle seule une solution de sécurité complète.
🔒 Cryptage
Architecture de chiffrement
Tous les messages, appels et transferts de fichiers chapeau à chapeau utilisent un cryptage de bout en bout côté client. Le serveur ne détient jamais les clés de déchiffrement des conversations des utilisateurs.
Protocole Double Ratchet
Même famille de protocoles que Signal. Chaque message utilise une clé unique. La compromission d'une clé n'expose pas les messages passés ou futurs (forward secret + futur secret).
Hybride post-quantique
Key exchange uses X25519 + ML-KEM-768 (Kyber). Même si un ordinateur quantique interrompt à l’avenir l’échange de clés classique, les messages restent protégés.
AES-256-GCM
Toutes les charges utiles des messages, le contenu des fichiers et la signalisation d'appel sont cryptés avec le cryptage authentifié AES-256-GCM. Les en-têtes sont également cryptés pour éviter les fuites de métadonnées.
Clés d'expéditeur de groupe
Les messages de groupe utilisent un protocole de clé d'expéditeur avec un cliquet à chaîne HMAC et des signatures ECDSA. Chaque expéditeur gère son propre porte-clés distribué sur des canaux cryptés 1:1.
Pile de protocoles
Échange de clés → X25519 + ML-KEM-768 (post-quantique hybride)
Ratchet → Double Ratchet (Signal famille de protocoles)
Chiffrement symétrique → AES-256-GCM
Dérivation de clé → HKDF-SHA-256
Authentification du message → HMAC-SHA-256
Signatures → ECDSA P-256 (groupes)
Phrase secrète KDF → PBKDF2
Exécution → API Web Crypto (native du navigateur)
Bibliothèque PQ → @noble/post-quantum (ML-KEM-768)
Échange de clés → X25519 + ML-KEM-768 (post-quantique hybride)
Ratchet → Double Ratchet (Signal famille de protocoles)
Chiffrement symétrique → AES-256-GCM
Dérivation de clé → HKDF-SHA-256
Authentification du message → HMAC-SHA-256
Signatures → ECDSA P-256 (groupes)
Phrase secrète KDF → PBKDF2
Exécution → API Web Crypto (native du navigateur)
Bibliothèque PQ → @noble/post-quantum (ML-KEM-768)
Vérifiez nos réclamations. Le code source cryptographique complet, les spécifications du protocole et la documentation de l'architecture sont publiés sous licence MIT :
github.com/City-of-Hats/coh-crypto-spec →
github.com/City-of-Hats/coh-crypto-spec →
👁 Visibilité des données
Ce que nos serveurs peuvent et ne peuvent pas voir
Ce tableau documente exactement quelles données existent sur nos serveurs. On distingue ce qui est crypté (opaque pour nous) et ce qui est visible.
| Type de données | Accès au serveur | Détails |
|---|---|---|
| Contenu du message | ✕ Impossible de voir | Tous les messages chapeau à chapeau sont chiffrés de bout en bout côté client. Le serveur stocke uniquement le texte chiffré opaque. |
| Fichiers joints | ✕ Impossible de voir | Les fichiers sont cryptés côté client avant le téléchargement. Le serveur stocke les blobs chiffrés. |
| Appels vidéo vocaux & | ✕ Impossible de voir | Les appels utilisent WebRTC peer-to-peer avec signalisation cryptée. Le serveur facilite uniquement la configuration de la connexion. |
| Dead Drops / EchoDrops | ✕ Impossible de voir | Contenu chiffré côté client. La clé de déchiffrement se trouve dans le fragment d'URL (jamais envoyé au serveur) ou dérivée d'une phrase secrète. |
| GhostFrame Charges utiles | ✕ Impossible de voir | Contenu stéganographique intégré et chiffré côté client avant le téléchargement. |
| Clés privées | ✕ Impossible de voir | Les clés privées ECDH et post-quantiques sont générées et stockées uniquement sur l'appareil. Jamais transmis au serveur. |
| Codes de chapeau | ✓ Visible | Les identifiants de chapeau sont stockés pour acheminer les messages. Ils sont pseudonymes et ne sont pas liés à une véritable identité. |
| ID de paire de canaux | ✓ Visible | Un enregistrement indiquant que Hat A et Hat B ont un canal. Requis pour le routage des messages. |
| Horodatages | ✓ Visible | Horodatages d’envoi/réception des messages. Requis pour la logique de commande et d’expiration. |
| Clés publiques | ✓ Visible | Les clés publiques ECDH et ML-KEM sont publiées pour permettre l'échange de clés. C'est par conception que les clés publiques — sont censées être publiques. |
| Jetons de notification push | ⚠ Métadonnées uniquement | Les jetons push de l'appareil sont stockés pour envoyer des notifications. Le contenu des notifications utilise du texte générique et non du contenu de message. |
Divulgation honnête : Comme toutes les plateformes de messagerie (y compris Signal), nous devons stocker certaines métadonnées de routage pour transmettre les messages. Les codes de chapeau sont pseudonymes — aucun numéro de téléphone, e-mail ou identité n'est requis. Mais nous savons que Hat A a envoyé un message à Hat B à un moment donné.
⚙ Modes de cryptage
Deux chemins de cryptage — expliqués honnêtement
Tout le contenu de City of Hats n'utilise pas le même chemin de cryptage. Nous sommes transparents quant au moment où le serveur peut et ne peut pas accéder au contenu.
E2E côté client (par défaut)
Utilisé pour tous les messages chapeau à chapeau, appels, morts-vivants, GhostFrame et EchoDrop.
- ✅ Chiffré sur votre appareil avant l'envoi
- ✅ Décrypté uniquement sur l'appareil du destinataire
- ✅ Le serveur stocke le texte chiffré opaque
- ✅ Nous ne pouvons pas décrypter même si nous y sommes obligés
Chiffrement côté serveur (limité)
Utilisé uniquement pour le contenu généré par le système : les annonces de la plateforme et le robot intelligent CHECK.
- ⚠ Le serveur génère et crypte ce contenu
- ⚠ Le serveur contient les clés de chiffrement pour ces chemins
- ℹ Cela s'applique uniquement aux messages du bot/système
- ✅ Le chat d'utilisateur à utilisateur n'est jamais sur cette voie
Pourquoi deux modes ? Le robot d'intelligence CHECK doit générer des rapports de sécurité côté serveur (il interroge des bases de données externes). Les annonces de la plateforme sont diffusées à tous les utilisateurs. Ce ne sont pas des conversations privées — ce sont des messages système. Toutes les communications d'utilisateur à utilisateur utilisent exclusivement l'E2E côté client.
📋 ; Politique de journalisation
Ce que nous enregistrons
Nous croyons qu'il est important de divulguer exactement ce qui est enregistré, plutôt que de prétendre de manière générale « pas de journalisation ».
| Catégorie | Ce qui est enregistré | Rétention |
|---|---|---|
| Adresses IP (application) | La limitation de débit utilise un hachage SHA-256 unidirectionnel des adresses IP. L'adresse IP brute n'est pas stockée dans la base de données. Les journaux d'accès au serveur Web standard peuvent contenir temporairement des adresses IP. | Haché : persistant. Journaux d’accès : alternés régulièrement. |
| Adresses IP (site Web) | Le site Web marketing (cityofhats.com) collecte des analyses des visiteurs, notamment l'adresse IP et la géolocalisation approximative. Ceci est distinct de l’application de messagerie. | Non lié à l'identité de messagerie. |
| Contenu du message | Non connecté. Non accessible. Le texte chiffré E2E est stocké pour livraison, puis soumis à une expiration configurée par l'utilisateur. | Contrôlé par l'utilisateur (minuteries de gravure, expiration automatique). |
| Journaux d'erreurs/de crash | Journaux d’erreurs côté serveur pour le débogage. Ceux-ci contiennent des types d'erreurs et des traces de pile, pas le contenu du message. | Rotation régulière. |
| Événements de limite de débit | Enregistré avec des identifiants hachés pour éviter les abus. Aucun contenu de message. | Fenêtre roulante. |
| Données du compte | Si vous vous connectez avec Auth0 (Google/Apple), votre fournisseur d'authentification partage un e-mail. Les comptes anonymes (avec chapeau uniquement) n'ont pas d'adresse e-mail liée. | Jusqu'à la suppression du compte. |
🔑 Gestion des clés
Où vivent vos clés
Les clés privées ne quittent jamais votre appareil. Voici exactement comment les éléments clés sont traités.
| Type de clé | Emplacement de stockage | Accès au serveur |
|---|---|---|
| Clé privée ECDH | Appareil uniquement (navigateur localStorage) | Jamais transmis |
| Clé secrète ML-KEM | Appareil uniquement (navigateur localStorage) | Jamais transmis |
| Double Ratchet État | Appareil uniquement. Sauvegarde cryptée facultative sur le serveur (chiffrée avec une clé dérivée de la clé privée). | Sauvegarde cryptée uniquement |
| Clés d'expéditeur de groupe | Appareil uniquement (navigateur localStorage) | Jamais transmis |
| Clé publique ECDH | Publié sur le serveur pour l'échange de clés | Visible (par conception) |
| Clé publique ML-KEM | Publié sur le serveur pour l'échange de clés | Visible (par conception) |
Limitation connue : Puisqu'il s'agit d'une application Web/PWA, les clés privées sont stockées dans le stockage local du navigateur. Il s'agit de la norme pour les messageries cryptées basées sur le Web, mais cela signifie que la sécurité de l'appareil (verrouillage de l'écran, cryptage complet du disque) est essentielle. La fonction PIN en option encapsule les clés stockées avec un cryptage dérivé de PBKDF2 pour une protection supplémentaire.
⚖ Demandes juridiques
Application de la loi et demandes juridiques
City of Hats Inc. est constituée en Ontario, au Canada et fonctionne sous le droit canadien.
- ✓ Nous ne pouvons pas fournir le contenu du message. Les messages cryptés E2E sont stockés sous forme de texte chiffré. Nous ne détenons pas de clés de décryptage. Même si la loi nous y oblige, nous ne pouvons pas décrypter les messages d’utilisateur à utilisateur.
- ✓ Ce que nous pourrions fournir si la loi nous y oblige : Codes chapeau, enregistrements de paires de canaux, horodatages, clés publiques et adresse e-mail du compte (si l'utilisateur s'est connecté auprès d'un fournisseur). Il s’agit des mêmes métadonnées que celles stockées par tout service de messagerie crypté.
- ✓ Les comptes anonymes contiennent un minimum de données. Les utilisateurs qui créent des comptes uniquement sans se connecter n'ont pas d'e-mail, pas de numéro de téléphone et aucune information d'identité sur nos serveurs. Le code du chapeau est le seul identifiant.
- ✓ Nous publierons un rapport de transparence. Nous avons l'intention de publier des statistiques globales sur les demandes légales reçues et les données fournies, conformément à la loi applicable.
- ✓ Canari de mandat : City of Hats maintient un canari de mandat. Si jamais il est supprimé, cela indique que nous avons reçu une ordonnance légale secrète.
🛤 Feuille de route de confiance
Ce que nous faisons ensuite
Nous progressons vers une confiance totalement vérifiable. Voici notre feuille de route publique.
Page de transparence technique
Cette page. Une spécification détaillée et honnête de ce que fait notre système. Publié en avril 2026.
Couche cryptographique open source
Nous publierons la mise en œuvre du protocole de cryptage (Double Ratchet, hybride post-quantique, clés d'expéditeur de groupe) en open source pour une vérification indépendante.
Audit de sécurité indépendant
Une société tierce réputée auditera notre mise en œuvre cryptographique. Le rapport complet sera publié ici, non expurgé.
Rapports de transparence
Rapports réguliers sur les demandes juridiques reçues, les données divulguées et la disponibilité du système. Publié sur cette page.
🤝 Vérifiez-le vous-même
Vous n'êtes pas obligé de nous faire confiance
City of Hats comprend des outils intégrés vous permettant de vérifier que le cryptage fonctionne comme décrit.
- ✓ Numéros de sécurité. Chaque canal affiche un numéro de sécurité unique dérivé des clés publiques des deux parties. Comparez hors bande pour vérifier qu’aucune attaque de l’homme du milieu n’a eu lieu.
- ✓ Alertes de changement de clé. Si les clés de cryptage d'un contact changent (nouvel appareil, réinstallation), vous recevez une alerte. Cela empêche la substitution silencieuse de clé.
- ✓ Chaîne de journaux d'audit. Les journaux d'audit cryptographiques utilisent des chaînes de hachage afin que la falsification du journal soit détectable.
- ✓ Indicateur E2E. Chaque canal crypté affiche une icône de verrouillage avec « E2E » pour confirmer que le cryptage côté client est actif pour cette conversation.
- ✓ Spécification cryptographique ouverte. Notre conception complète du protocole — échange de clés, Double Ratchet, hybride post-quantique, cryptage de groupe — est publiée publiquement. Vérifiez-le vous-même : github.com/City-of-Hats/coh-crypto-spec
📬 Contact
Des questions ou des préoccupations ?
Si vous êtes un chercheur en sécurité, un journaliste ou si vous avez des questions sur nos pratiques en matière de confidentialité, nous sommes ouverts à la conversation.
City of Hats Inc. · Toronto, Canada · Constituée en Ontario