Sécurité et confidentialité

Où va ce que vous envoyez

Votre requête arrive à la passerelle Babel Mesh, qui choisit un nœud selon la classe de données de la requête et la lui transmet. Le nœud calcule le résultat avec son modèle et le renvoie par la passerelle.

Le nœud qui traite une requête peut la lire. C'est un fait du fonctionnement actuel : un nœud doit lire l'invite pour y répondre. N'envoyez donc ni mots de passe, ni numéros d'identité, ni secrets commerciaux.
Le nœud ne peut pas voir qui vous êtes. La requête reçue par un nœud ne porte ni nom de compte ni clé, seulement une étiquette anonyme.
Babel Mesh ne conserve pas les conversations. Les journaux de la passerelle contiennent l'heure d'une requête, le modèle, le résultat et l'utilisation. Les conversations restent dans votre propre client ou navigateur.
Exception : les règles de contenu. La passerelle vérifie les entrées et les sorties selon des règles de contenu. Une requête qui déclenche une règle laisse un court extrait autour de l'occurrence et le nom du compte, pour lutter contre les abus ; le texte complet n'est pas conservé.
Les contrôles ponctuels rejouent des requêtes. Pour vérifier ce que renvoient les contributeurs, une petite part des requêtes de classe publique est recalculée sur les nœuds propres de l'opérateur et les deux résultats sont comparés.

Classes de données

Chaque compte et chaque requête a une classe de données. Les comptes qui s'inscrivent eux-mêmes commencent en « publique ». Les nœuds des contributeurs ne reçoivent que des requêtes « publiques ». Les classes supérieures vont uniquement aux nœuds propres de l'opérateur. Pour l'instant, les images et la vidéo ne sont aussi servies que par les nœuds de l'opérateur, car leurs résultats ne peuvent pas être contrôlés par sondage comme le texte.

Connexions et clés

Le site web et l'API utilisent HTTPS. Les composants qui sont derrière (contrôleur, passerelle, registre, relais, nœuds) communiquent par des connexions chiffrées avec authentification mutuelle par certificat ; l'identité d'un nœud est dans son certificat.
Les nœuds se connectent uniquement vers l'extérieur. Ils n'ouvrent aucun port entrant et servent via un relais.
Le client conserve votre clé d'API sur votre ordinateur, lisible uniquement par votre compte système. La page du client ne reçoit jamais la clé ; c'est le client qui fait les requêtes pour vous.
Les mises à jour du client sont vérifiées par rapport à un manifeste signé : la clé publique est intégrée au client, et une signature incorrecte ou une version qui n'est pas plus récente n'est jamais installée.

Comptabilité et vérification

Reçus signés par les deux parties. Pour chaque requête, la passerelle et le nœud signent le même reçu, et le registre ne l'enregistre que s'ils concordent. Un reçu contient des empreintes de la requête et du résultat et l'utilisation, pas le contenu.
Contrôles aléatoires. Les nouveaux nœuds sont contrôlés plus souvent, ceux qui ont un long historique irréprochable moins souvent. Un nœud dont les résultats ne concordent pas est mis en quarantaine ; une fois la triche confirmée par l'opérateur, ses gains sont perdus et sanctionnés selon les règles.
Les gains sont retenus. Le revenu d'un contributeur attend quelques jours, pendant lesquels les contrôles continuent.

Ce qu'il ne sait pas faire

Il n'existe pas encore d'environnement d'exécution de confiance (TEE) : on ne peut pas garantir qu'un nœud ne voit pas le contenu, d'où les classes de requêtes.
Il n'a pas fait l'objet d'un audit de sécurité par un tiers.
Aucune promesse de disponibilité : les nœuds peuvent disparaître à tout moment, et une requête est retentée sur un autre nœud, mais le succès n'est pas garanti.
Les règles de contenu ne sont pas parfaites : elles peuvent bloquer par erreur et laisser passer certaines choses.

Cette page décrit ce que le système fait réellement aujourd'hui. Les conditions d'utilisation et la politique de confidentialité formelles sont publiées séparément par l'entité exploitante.