Sicherheit und Datenschutz

Wohin das Gesendete geht

Ihre Anfrage erreicht das Babel-Mesh-Gateway, das nach der Datenklasse der Anfrage einen Knoten wählt und sie dorthin weiterleitet. Der Knoten berechnet das Ergebnis mit seinem Modell und gibt es über das Gateway zurück.

Der Knoten, der eine Anfrage bearbeitet, kann sie lesen. Das ist eine Tatsache der heutigen Funktionsweise: Ein Knoten muss den Prompt lesen, um zu antworten. Senden Sie daher keine Passwörter, Ausweisnummern oder Geschäftsgeheimnisse.
Der Knoten sieht nicht, wer Sie sind. Die Anfrage, die ein Knoten erhält, trägt weder Kontonamen noch Schlüssel, nur eine anonyme Kennung.
Babel Mesh speichert keine Unterhaltungen. Die Aufzeichnungen des Gateways enthalten Zeitpunkt einer Anfrage, Modell, Ergebnis und Nutzung. Unterhaltungen bleiben in Ihrem eigenen Client oder Browser.
Ausnahme: Inhaltsregeln. Das Gateway prüft Ein- und Ausgaben anhand von Inhaltsregeln. Eine Anfrage, die eine Regel auslöst, hinterlässt einen kurzen Auszug um die Fundstelle und den Kontonamen, um Missbrauch zu bekämpfen; der vollständige Text wird nicht gespeichert.
Stichproben wiederholen Anfragen. Um zu prüfen, was Beitragende zurückliefern, wird ein kleiner Teil der Anfragen der Klasse „öffentlich“ auf den eigenen Knoten des Betreibers noch einmal berechnet und beide Ergebnisse werden verglichen.

Datenklassen

Jedes Konto und jede Anfrage hat eine Datenklasse. Konten, die sich selbst registrieren, beginnen bei „öffentlich“. Knoten von Beitragenden erhalten nur „öffentliche“ Anfragen. Höhere Klassen gehen nur an die eigenen Knoten des Betreibers. Bilder und Video werden vorerst ebenfalls nur von den Knoten des Betreibers bedient, weil sich ihre Ergebnisse nicht wie Text stichprobenartig prüfen lassen.

Verbindungen und Schlüssel

Die Website und die API nutzen HTTPS. Die dahinterliegenden Komponenten (Controller, Gateway, Hauptbuch, Relay, Knoten) kommunizieren über verschlüsselte Verbindungen mit gegenseitiger Zertifikatsauthentifizierung; die Identität eines Knotens steckt in seinem Zertifikat.
Knoten verbinden sich nur nach außen. Sie öffnen keinen eingehenden Port und arbeiten über ein Relay.
Der Client speichert Ihren API-Schlüssel auf Ihrem Computer, nur für Ihr Systemkonto lesbar. Die Seite des Clients erhält den Schlüssel nie; der Client stellt die Anfragen für Sie.
Client-Updates werden gegen ein signiertes Manifest geprüft: Der öffentliche Schlüssel ist im Client eingebaut, und eine fehlerhafte Signatur oder eine nicht neuere Version wird nie installiert.

Abrechnung und Überprüfung

Von beiden Seiten signierte Belege. Für jede Anfrage signieren Gateway und Knoten denselben Beleg, und das Hauptbuch erfasst ihn nur, wenn sie übereinstimmen. Ein Beleg enthält Hashes von Anfrage und Ergebnis sowie die Nutzung, nicht den Inhalt.
Stichprobenprüfungen. Neue Knoten werden häufiger geprüft, Knoten mit langer sauberer Historie seltener. Ein Knoten, dessen Ergebnisse nicht übereinstimmen, wird isoliert; sobald der Betreiber Betrug bestätigt, verfallen seine Einnahmen und werden nach den Regeln bestraft.
Einnahmen werden zurückgehalten. Das Einkommen eines Beitragenden wartet einige Tage, in denen die Prüfungen weiterlaufen.

Was es nicht kann

Es gibt noch keine vertrauenswürdige Ausführungsumgebung (TEE): Sie kann nicht garantieren, dass ein Knoten Inhalte nicht sehen kann, weshalb Anfragen Klassen haben.
Es wurde keiner Sicherheitsprüfung durch Dritte unterzogen.
Kein Verfügbarkeitsversprechen: Knoten können jederzeit wegfallen, und eine Anfrage wird auf einem anderen Knoten wiederholt, aber ein Erfolg ist nicht garantiert.
Inhaltsregeln sind nicht perfekt: Sie können fälschlich blockieren und Dinge übersehen.

Diese Seite beschreibt, was das System heute tatsächlich tut. Formale Nutzungsbedingungen und eine Datenschutzerklärung veröffentlicht die betreibende Stelle gesondert.