Conçu pour la confiance, pas pour l'apparence

Comment fonctionne la connexion

Nous traitons votre mot de passe comme un secret que nous ne voyons jamais en clair, stockons le hachage le plus fort que la spec nous donne, et faisons tourner les refresh tokens pour qu'un cookie volé ne survive pas à la session dont il provient.

• Les mots de passe sont hachés avec argon2id (profil RFC 9106 m=19 MiB). Les anciens hachages bcrypt sont mis à niveau de manière transparente à la prochaine connexion — pas de réinitialisation forcée.
• Les sessions utilisent des familles tournantes de refresh tokens. Si un token volé est rejoué, toute la famille s'invalide et l'appareil légitime doit se réauthentifier — pas de compromission silencieuse.
• Verrouillage de compte configurable après tentatives infructueuses répétées. Levé automatiquement à la première connexion réussie, pour qu'une faute de frappe ne vous bloque pas.
• « Se connecter avec Apple » et « Se connecter avec Google » utilisent OpenID Connect en direct — goia_api se connecte lui-même à Apple et Google, sans aucun intermédiaire d'authentification tiers sur le chemin. Nous ne recevons que l'identifiant du fournisseur en amont, votre e-mail et l'indicateur de vérification — jamais votre mot de passe fournisseur.

Sécurité à la connexion

Chaque connexion passe par un deuxième facteur. Chaque connexion depuis un nouvel appareil vous alerte. Les parents restent informés pour les moins de 18 ans sans rien laisser filtrer d’autre.

• Authentification à deux facteurs à chaque connexion: code à 6 chiffres par e-mail, fenêtre de 30 jours pour les appareils de confiance.
• Alerte e-mail en temps réel lorsque le compte est accédé depuis un nouvel appareil: type, ville et pays approximatifs, horodatage. Un geste révoque l’appareil et force la réinitialisation du mot de passe.
• Les connexions des moins de 18 ans depuis un nouvel appareil alertent aussi les parents de leur cellule. Transparent: les mineurs voient dans Réglages quels parents sont câblés.
• Codes de secours: 8 codes à usage unique à la première configuration, accessibles depuis Réglages → Sécurité, régénérables à la demande. Voie de récupération si l’e-mail est inaccessible.
• Stockage des mots de passe: argon2id, le hachage mémoire-dur standard de l’industrie. Les jetons d’appareil de confiance sont séparés des jetons de session.
• Vérification limitée: 5 codes échoués déclenchent un verrouillage de 15 minutes.

Quand quelque chose semble louche

Si une connexion arrive depuis un pays que nous n'avons pas vu sur votre compte ces 30 derniers jours, nous vous écrivons. L'email comporte un « ce n'était pas moi » en un clic qui révoque la session et vous emmène directement à la réinitialisation du mot de passe.

• Alertes email d'emplacement inconnu (une par pays par fenêtre de 30 jours — un voyage ne vous spamme pas).
• Liste des sessions actives avec révocation par appareil depuis l'app. Vous pouvez déconnecter un téléphone perdu sans changer le mot de passe.
• Détail des connexions échouées (horodatage et code pays seulement — jamais d'IP brute) visible dans le journal de sécurité de l'app.

Vraies apps uniquement

Le trafic mobile est attesté comme provenant d'une vraie installation ConKarma sur un vrai appareil. Les tentatives curl-contre-l'API sont doucement rejetées, ce que doit faire une surface API honnête.

• Firebase App Check sur iOS et Android. Le token est requis sur chaque appel API depuis mobile.
• TLS pinning mobile via le manifeste signé à /.well-known/mobile-pins.json. Les nouveaux pins sont signés par une clé hors-ligne et tournent avec une fenêtre de chevauchement de six semaines, pour qu'une mise à jour ne bloque personne.

Les fonctionnalités adultes sont hors de portée de l'analytique

ConKarma a deux zones: une zone Serene (tout ce qui est family-friendly) et une zone Ember (les fonctions 18+). Les pages Ember ne déclenchent délibérément aucun événement d'analytique tierce. Nous collectons des compteurs Prometheus agrégés côté serveur pour la capacité et l'uptime; rien de plus.

• Les surfaces adultes (défis, désirs, fantasmes, journaux intimes, le coffre privé) ne chargent jamais Google Analytics.
• Le déverrouillage biométrique est requis pour entrer dans les surfaces Ember de l'app. Le système expire et reverrouille si vous changez d'app.
• Le screenshot guard masque le contenu Ember du sélecteur d'apps du système et de tout overlay d'enregistrement d'écran.
• Activation de la zone adulte par appareil : ACTIVÉE par défaut sur votre appareil principal, DÉSACTIVÉE sur tous les autres. Vous optez explicitement par appareil, et la vérification côté serveur échoue en mode fermé (fail-closed).
• Nouvelle invite après inactivité : le verrou biométrique se libère après 5 minutes d'inactivité dans Ember, ou 30 secondes en arrière-plan. Les deux délais sont configurables depuis Réglages → Confidentialité.
• Mise à zéro du cache mémoire : quand vous passez d'Ember à Serene (ou que l'app passe en arrière-plan), chaque image en cache est supprimée de la mémoire — défense en profondeur contre les outils d'inspection mémoire.
• Exclusion de Spotlight, Apple Intelligence et AppIntents : aucun contenu adulte n'est jamais transmis à Spotlight, au LLM sur l'appareil, aux AppIntents, au Smart Stack ou aux widgets de l'écran verrouillé.
• Accès administrateur à deux yeux : aucun humain chez XTZ Group ne peut lire le contenu de la zone adulte unilatéralement — chaque dérogation nécessite l'approbation signée d'un second administrateur, consignée dans un journal d'audit immuable.
• Conservation adulte configurable de 3 ans : les lignes de la zone adulte sont supprimées automatiquement après 3 ans par défaut. La fenêtre est configurable par l'utilisateur (de 90 jours à 10 ans) depuis Réglages → Confidentialité. Suppression définitive une fois la fenêtre écoulée.
• Contrôles de sauvegarde iCloud et d'export RGPD : deux bascules opt-in dans Réglages → Confidentialité gardent le contenu adulte hors des sauvegardes de l'appareil et hors de votre export de données par défaut — pour qu'une sauvegarde ou un export partagé par erreur ne l'expose pas.

Lire les garanties complètes d'isolation des zones →

Infrastructure de consentement + outils de conflit

Les conversations difficiles et le consentement adulte passent par des surfaces structurées et curatoriales — jamais par un pipeline d'IA. Les données qui les sous-tendent restent locales ou privées au couple; rien sur l'activation d'un mot de sécurité ou une réparation fraternelle ne quitte la paire d'appareils, et nos administrateurs ne peuvent pas le lire.

• Outils de conflit — pipeline d'IA exclu: chaque flux de réparation fraternel, en couple et intergénérationnel est du contenu curatorial + formulaires structurés. Le texte qu'un enfant touche provient de notre ensemble éditorial, pas d'un modèle. Le texte qu'un partenaire voit dans un cadre de réparation provient d'une bibliothèque fixe d'invitations. Nous ne routons rien de cela à travers un LLM.
• Infrastructure de consentement — Ember: le document de limites, le binding du mot de sécurité et les check-ins d'aftercare vivent sur des primitives E2E d'Ember — paire de clés séparée, biométrique obligatoire, jamais répliqué vers aucune analytique côté serveur. Le document de limites n'atteint jamais notre pipeline d'IA.
• Masquage personnel + contrôles au niveau de la cellule: quand vous masquez une fonctionnalité pour vous, le BE ne supprime pas les données sous-jacentes — elles restent intactes. Toute opération de marquage permanent qui détruit réellement des données nécessite une porte à deux administrateurs.

Infrastructure de consentement Ember

Les surfaces du niveau adulte n'utilisent pas une simple case « J'accepte » appelée consentement. Ember est structuré autour de trois primitives fondamentales — le document de limites, le safeword et les bilans de soin post-séance — qui vivent sur la même paire de clés E2E que le reste de la zone adulte. Ton traitement à tout moment ; agentivité, pas paternalisme.

• Document de limites : chaque partenaire construit et modifie le sien, visible uniquement par l'autre partenaire dans la même cellule de couple. N'atteint jamais notre pipeline analytique ; jamais lu par une IA ; jamais répliqué côté serveur au-delà du blob chiffré.
• Liaison safeword : une phrase safeword partagée par le couple qui ramène immédiatement toutes les surfaces Ember à Serene + écrit une ligne de journal privée au couple. Les activations sont visibles des deux partenaires uniquement ; les opérateurs de XTZ Group ne peuvent pas les lire.
• Bilans de soin post-séance : planifiés par l'un ou l'autre partenaire après une session Ember, optionnels par partenaire, les réponses restent privées au couple. Pas de compteur d'engagement, pas de série, pas de relance.
• Formulation adulte : le texte et les invites traitent les lecteurs adultes comme des adultes. Nous n'infantilisons pas les surfaces avec des euphémismes ; nous ne jouons pas non plus sur la valeur choc pour paraître transgressifs.

Correspondance de consentement en double aveugle

Lorsque deux partenaires explorent quelles catégories de fantasmes se recoupent, la correspondance s'exécute entièrement sur l'appareil avec deux invariants structurels que nous ne briserons pas : ne-jamais-révéler-un-non (si l'un ou l'autre des partenaires appuie sur non, aucun des deux n'en voit le résultat) et zéro-sortie IA (aucun modèle dans le chemin d'inférence).

• Invariant ne-jamais-révéler-un-non : une paire oui/oui apparaît dans la liste de correspondances partagée. Toute autre combinaison (oui/non, non/oui, non/non) ne renvoie rien — aucun des partenaires ne voit qui a dit non, et aucun ne voit que l'autre a même été montré l'invite. C'est de la conception structurelle anti-pression, pas un paramètre que tu peux désactiver.
• Invariant zéro-sortie IA : le calcul de correspondance est une intersection d'ensembles locale. Pas d'inférence de modèle, pas de recherche d'incorporation, pas de score IA des catégories ou des paires. L'ensemble des catégories lui-même est du contenu éditorial, pas généré.
• Résultats privés au couple : la liste de correspondances est chiffrée de bout en bout sur la paire de clés partagée du couple. Côté serveur nous voyons des compteurs (planification de capacité) mais jamais les catégories elles-mêmes.
• Invariants auditables : les deux invariants ci-dessus sont appliqués dans le chemin de code sur l'appareil sans bascules et sans remplacement administrateur. Un opérateur de plateforme ne peut pas inscrire un couple à la télémétrie sur cette surface — il n'y a pas de télémétrie à activer.

Conformité à la loi TAKE IT DOWN — canal d'avis public

La loi fédérale TAKE IT DOWN Act (2025) exige que les plateformes hébergeant du contenu utilisateur agissent sur les demandes de retrait d'images intimes non consenties dans les 48 heures. Le canal d'avis public de ConKarma + la procédure sont publiés sur /legal/takedown-notice ; cette section est le résumé de la posture de sécurité.

• Canal : legal@conkarma.app (objet : Take It Down notice / DMCA notice / Urgent — CSAM report).
• Engagement : SLA de 48 heures à compter de la réception d'une demande valide jusqu'au retrait ou à la désactivation de l'accès.
• Couverture : NCII (deepfakes réels ou générés par IA), droits d'auteur DMCA, CSAM (priorité élevée + signalement NCMEC), et les rapports de contenu illicite plus généraux.
• Contre-avis : chemin de contre-avis DMCA via le même canal ; fenêtre de restauration légale de 10 à 14 jours ouvrables en l'absence d'une ordonnance de tribunal.
• Audit : chaque avis + chaque action prise est enregistré et conservé pour les durées requises par la loi. Les avis de mauvaise foi peuvent exposer l'expéditeur à une responsabilité civile en vertu de la loi, du §512(f) DMCA et de nos Conditions.

Réglage réglementaire par état

Lorsque des États américains ou d'autres juridictions adoptent des lois qui limitent ce qu'une plateforme peut offrir (régimes de vérification de l'âge, restrictions de catégories de contenu, obligations d'archivage), nous adaptons le comportement régionalement plutôt que de nous retirer du marché. Le compromis honnête : la loi d'un État façonne l'aspect de la surface pour les utilisateurs dans cet État, pas ce que nous pensons être la bonne conception produit.

• Détection de région : basée sur le pays déclaré par l'utilisateur + (pour les États-Unis) l'état qu'il a configuré dans Paramètres, pas uniquement la géolocalisation par IP. Les utilisateurs peuvent remplacer la région inférée si elle est incorrecte.
• Ce qui est ajusté : flux de vérification d'âge (états de style KOSA), restriction d'accès au contenu adulte, fenêtres de conservation là où la loi de l'état les impose, et le texte de divulgation là où l'état exige une formulation spécifique.
• Ce qui N'est PAS ajusté : la posture de chiffrement de bout en bout, les invariants zéro-sortie IA, le paramètre par défaut conforme COPPA pour les moins de 13 ans, et l'invariant de tableau ne-jamais-mélanger-les-lignes-de-contenu-adulte. Ceux-ci sont non négociables dans toutes les juridictions.
• Transparence : la configuration régionale appliquée à ton compte est visible dans Paramètres → Confidentialité → Posture régionale. Si tu penses qu'elle est incorrecte pour ta juridiction, dépose un avis Take It Down ou écris à legal@conkarma.app.

Les enfants ne sont pas un levier de croissance

Les comptes de moins de 13 ans passent par un flux vérifiable de consentement parental avant d'exister. Nous ne montrons pas de pubs sur les comptes enfants, point. Nous ne vendons pas les données des enfants, ne les partageons pas pour la pub, et ne les utilisons pas pour cibler quoi que ce soit.

• Consentement parental vérifiable conforme à COPPA §312.5 (vérification signée par carte de crédit, avec voie alternative pour foyers sans carte).
• Aucune publicité tierce d'aucune sorte sur les comptes de moins de 13 ans.
• Les parents peuvent consulter, exporter et effacer les données du compte de leur enfant à tout moment depuis l'app.

La confiance vient de la Cellule, pas de nous

ConKarma est un produit en cercle fermé. Pas de profils publics, pas de graphe de followers, et pas de moyen de découvrir des inconnus. La plupart de la modération arrive parce que vous et les gens de votre Cellule vous connaissez et vous faites confiance. Là où le modèle a besoin d'aide, nous avons un flux de signalement et une file de modération avec un humain dedans.

• Les Cellules sont fermées par défaut. Pas de découverte publique, pas de profil public, pas de suggestions ami-d'ami.
• Flux de signalement utilisateur sur chaque surface de contenu, routé vers une file de modération opérée par des humains.
• Le scan par hachage du CSAM connu est suivi comme implémentation connue-et-pendante, avec déclencheurs explicites de revisite lorsque nous passerons à un profil de stockage média qui l'exige. Nous ne l'affirmerons pas avant qu'il soit réel.

Ce que nous gardons, où, et comment le récupérer

Nous sur-documentons cela sur /privacy et /legal/subprocessors, mais la version courte pertinente pour la sécurité est: chiffré au repos, stocké là où la paperasse SCC le couvre, exportable et effaçable à la demande, et nous ne gardons pas plus que nécessaire.

• Contrôles d'export et d'effacement GDPR, CCPA et Quebec-25 dans l'app — pas derrière un ticket de support. L'effacement a une fenêtre de grâce de 30 jours en soft-delete au cas où vous changeriez d'avis.
• Chiffrement au repos sur la base Postgres et sur le stockage objet (infrastructure gérée par Supabase).
• Aucune IP brute n'est stockée sur une surface visible à l'utilisateur. La liste des sessions actives ne montre que le code pays sur 2 lettres; les IPs brutes existent brièvement dans les lignes d'événements de sécurité à usage forensique sous une rétention courte.