01Documenté
Le contenu Hat est chiffré de bout en bout
City of Hats documente un chiffrement côté client pour les messages, fichiers et appels entre Hats, afin que l’infrastructure de livraison traite du contenu chiffré plutôt que le texte des conversations.
PortéeCommunications Hat-à-Hat sur les clients City of Hats pris en charge.
Éléments de preuveLa spécification nomme un établissement hybride X25519 et ML-KEM-768, une Double Ratchet et le chiffrement authentifié AES-256-GCM.
Limite importanteLe chiffrement ne protège pas le texte en clair sur un terminal compromis ou déverrouillé, ni contre un destinataire qui enregistre ce qu’il peut lire.
Lire la spécification technique →
02Observable
Un Hat ne nécessite ni téléphone ni e-mail
Une personne peut créer un Hat pseudonyme et être jointe par code Hat ou Phrase ID sans enregistrer de numéro d’opérateur ni d’adresse e-mail.
PortéeCréation de base d’un Hat grand public ; les services payants, administratifs, d’assistance ou de facturation peuvent collecter des informations distinctes.
Éléments de preuveLe parcours public de création peut être testé sans fournir de téléphone ni d’e-mail.
Limite importanteLe pseudonymat n’est pas un anonymat absolu. Terminaux, réseaux, informations volontairement partagées et données opérationnelles de connexion restent dans le modèle de menace.
Voir les identités pseudonymes →
03Observable
Le fournisseur ne détient aucun coffre de récupération des conversations
La messagerie grand public est conçue sans coffre City of Hats capable de restaurer l’historique perdu d’une conversation Hat.
PortéeMessages Hat et état de conversation détenu par le terminal ; les dossiers professionnels distincts suivent la Politique de confidentialité.
Éléments de preuveLe comportement de récupération et la documentation de confidentialité indiquent que City of Hats ne peut restaurer un contenu détruit ou perdu avec l’appareil.
Limite importanteC’est aussi un compromis de disponibilité : perdre le seul terminal autorisé peut entraîner la perte définitive des messages.
Lire la politique de traitement →
04Documenté
L’établissement des clés utilise un hybride post-quantique
Le design publié combine X25519 classique et ML-KEM-768 avant de dériver les clés du protocole de conversation.
PortéeSessions Hat prises en charge sur les clients utilisant la version actuelle du protocole.
Éléments de preuveLes algorithmes et la construction hybride sont documentés dans Transparence et Chats sécurisés.
Limite importanteNommer des algorithmes robustes ne constitue pas un audit indépendant de l’implémentation. La sécurité dépend aussi de l’intégration, des clés, des clients et de la cryptanalyse future.
Examiner le design du chat sécurisé →
05Documenté
Les appels n’exposent pas directement l’adresse IP à l’autre participant
La voix et la vidéo sont conçues pour passer par un relais de média chiffré plutôt que par un chemin pair-à-pair révélant les adresses IP.
PortéeAppels voix et vidéo City of Hats utilisant l’architecture de relais documentée.
Éléments de preuveLes pages Appels chiffrés et Transparence décrivent un média uniquement relayé et des clés fraîches pour chaque appel.
Limite importanteLe relais et les fournisseurs réseau traitent toujours les connexions nécessaires. Le relais ne cache pas un terminal à son propre réseau et ne neutralise pas un appareil compromis.
Voir l’architecture des appels →
06Observable
L’expéditeur peut réduire l’exposition après l’envoi
Voir une fois, Rappel, GeoLock, Envoi certifié, filigrane invisible et Channel Seal limitent l’accès, la conservation ou la divulgation ordinaires.
PortéeMessages et fichiers envoyés avec le contrôle choisi sur des clients compatibles.
Éléments de preuveLes contrôles et parcours destinataire sont visibles dans le produit et documentés sur leurs pages.
Limite importanteAucune application ne peut faire oublier un contenu à un destinataire autorisé, bloquer toute caméra externe ni protéger un texte déjà capturé hors du lecteur.
Examiner les modes de sécurité →
