Sicherheit und Datenschutz

Wie Babel Mesh Anfragen verteilt, Konten schützt und Knoten prüft und was es nicht kann.

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.
  • Babel Mesh prüft keine Inhalte. Das Gateway prüft, blockiert oder filtert Ein- und Ausgaben nicht anhand von Inhaltsregeln und behält wegen des Inhalts einer Anfrage weder Auszüge noch Kontonamen. Die Verantwortung für die Nutzung der Inhalte liegt bei Ihnen; senden Sie keine rechtswidrigen Inhalte.
  • 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.

  • 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.

Hive: Der Server kann deine Aufgabe nicht sehen

Hive ist ein anderer Weg: Die Aufgaben und Dateien, die du ihm gibst, werden in deinem Browser verschlüsselt, und Dispatcher und Speicher erhalten nur Chiffretext. Das tut es heute, einschließlich dessen, was es nicht kann.

  • Die Verschlüsselung geschieht im Browser. Jede Aufgabe hat einen eigenen Hauptschlüssel; die Aufgabe, ihre Dateien und ihr Ergebnis werden damit versiegelt, und der Hauptschlüssel wird getrennt für jede Maschine versiegelt, die die Aufgabe ausführen darf. Dispatcher, Speicher und Gateway sehen Chiffretext, Größen, Zeiten und deine Konto-ID, nicht den Inhalt.
  • Die Maschine, die eine Aufgabe ausführt, kann sie lesen. Sie muss die Aufgabe öffnen, um zu arbeiten, das lässt sich nicht vermeiden. Deshalb werden Maschinen nach Datenklasse getrennt: öffentliche Aufgaben dürfen an jede zugelassene Maschine; vertrauenswürdige nur an die eigenen Maschinen der Plattform, vertraglich gebundene Institutionen und Maschinen mit bestandener Fernbeglaubigung; vertrauliche nur an die eigenen Maschinen der Plattform und beglaubigte. Deine eigenen Maschinen kommen immer zuerst, und nur sie dürfen deine Aufgaben unabhängig von der Klasse übernehmen.
  • Maschinen laufen isoliert. Eine Aufgabe läuft in einer gVisor-Sandbox, standardmäßig ohne Netzwerk und nur mit Zugriff auf ihren eigenen Arbeitsordner. Eine neue Maschine muss mehrere Prüfungen bestehen, bevor sie echte Aufgaben bekommt, und eine Maschine, die eine Prüfung nicht besteht, wird isoliert oder gesperrt.
  • Ein Einmalschlüssel für das Modell pro Aufgabe. Maschinen bekommen nie deinen Kontoschlüssel; eine Aufgabe nutzt einen eigens für sie erzeugten Schlüssel mit Ausgabenlimit. Der Server widerruft ihn, sobald die Aufgabe endet – ob deine Seite offen ist oder nicht.
  • Wie lange etwas aufbewahrt wird. Eine Aufgabe und ihr Ergebnis (Chiffretext) bleiben 7 Tage auf dem Server und werden dann gelöscht; die Seite zeigt das Datum. Abbrechen löscht sofort. Deine Aufgabenaufzeichnungen und die Schlüssel dazu bleiben nur in deinem Browser: Löschst du dessen Daten oder wechselst den Browser, lassen sie sich nicht mehr öffnen – außer du schaltest die Geräte-übergreifende Synchronisierung ein (verschlüsselt mit einem Passwort, das nur du kennst; vergisst du es, kann es niemand wiederherstellen).
  • Auch „Meine Bibliothek“ wird im Browser verschlüsselt. Dateien werden in Blöcke geteilt und vor dem Hochladen mit einem eigenen Schlüssel verschlüsselt; der Speicher hält Chiffretext, auf mehr als einer Maschine, und der Index ist verschlüsselt. Eine Datei, die du für eine Aufgabe freigibst, ist nur lesbar, zeitlich begrenzt und auf ihre Blöcke beschränkt.
  • Du kannst es prüfen. Der Kerncode soll Open Source werden; Versionen lassen sich bereits reproduzierbar bauen, ihre Hashes sollen in einem Transparenzlog stehen, damit du bestätigen kannst, dass das Programm, das du ausführst, aus dem Quellcode gebaut wurde (dieser Schritt hat noch nicht begonnen); die Kryptografie im Browser ist eine eigene Datei und wird mit gemeinsamen Testvektoren gegen die Implementierung des Servers geprüft.

Was Hive nicht kann: Es kann die Maschine, die eine Aufgabe ausführt, nicht daran hindern zu sehen, was sie verarbeitet (die vertrauliche Klasse stützt sich auf Hardware-Beglaubigung, bisher nur bei den eigenen Maschinen der Plattform); es schützt nicht vor einem kompromittierten Browser oder einem Computer mit bösartiger Erweiterung; der Server kennt weiterhin Metadaten wie „ein Konto hat zu dieser Zeit eine Aufgabe dieser Größe abgegeben“; öffentliche Aufgaben können von Maschinen Fremder verarbeitet werden, lege also nichts Privates hinein; es gab keine Sicherheitsprüfung durch Dritte.

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.

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