Ich achte auf die Privatsphäre von @OpenGradient Chat und beginne nicht mit „Es verspricht, keine Daten zu sehen“. Was mich viel mehr interessiert, ist genau dieser Moment: Der Nutzer tippt den Prompt, drückt auf „Senden“, und die Anfrage verlässt gerade den Browser. In diesem Augenblick ist es am gefährlichsten. Viele Lecks passieren nicht beim Modellantworten, sondern unterwegs.
Diese Aussage wird erst einmal lokal eingekapselt. Was HPKE tut, ist sehr direkt: Es verpackt den Prompt in einen Umschlag, den nur das Ziel-Enclave öffnen kann. Der Relay sieht, dass das Paket kommt, sieht die Zeit und vielleicht sogar, wie groß es ist, aber sieht nicht den Klartext. Es schützt vor neugierigen Blicken auf der Routing-Ebene. Und was nicht gehalten werden kann, ist ebenfalls klar: Wenn der öffentliche Schlüssel des Ziels ausgetauscht wird oder der Nutzer sich mit einem falschen Einstiegspunkt verbindet, kann der Umschlag an die falsche Tür gehen.
Weiter geht es mit OHTTP. Der Name ist hart, aber im Grunde ist es, als würde man das Versandetikett in zwei Hälften reißen. Der Relay erhält die Informationen des Absenders, bekommt aber den Inhalt nicht; das Gateway schickt die Sache weiter, sollte jedoch nicht wissen, wer der ursprüngliche Absender war. Das Unintuitive daran ist genau hier: Die Privatsphäre von OpenGradient Chat verlässt sich nicht darauf, dass eine einzige Ebene sauber ist, sondern darauf, dass sich ein einzelner „Schmutz“ nicht vollständig zusammensetzen lässt. Wenn der Relay kompromittiert ist, hat der Angreifer nur IP, Zeit und Paketlänge; wenn das Gateway kompromittiert ist, weiß es nur, dass es irgendwohin einen Chiffretext gibt.
Erst nachdem der Chiffretext in ein TEE gelangt, wird er geöffnet. Das TEE ist ein hardwareisoliertes kleines Zimmer, das verhindert, dass der Host den Speicher ausliest oder den Ausführungscode willkürlich verändert. Hier geht es nicht darum, dass „der Server behauptet, sicher zu sein“, sondern dass das Enclave ein Attestation ausgibt: Es zeigt, dass Zimmer, Code und Ausführungsidentität zusammenpassen. Es gibt aber auch Grenzen: Wenn der Enclave-Code Sicherheitslücken hat oder eine externe Modell-Schnittstelle Klartext-Logs speichert, kann die Privatsphäre durch eine Seitentür entweichen.
Am nützlichsten ist diese Mechanik dort, wo sie typische Risiken in kleine Bruchstücke zerlegt. Der Betrieb will den Prompt sehen, kommt aber nur an den Chiffretext. Der Relay möchte Nutzer und Problem zuordnen, bekommt jedoch nur die halbe Seite. Die Plattform möchte, dass du der Umgebung direkt vertraust; Attestation macht aus „Glaub mir“ ein „prüf mich“. Aber ich beobachte noch eine Grauzone: Wenn der Relay langfristig Paketlänge und Zeit speichert, das Gateway Zielaufzeichnungen speichert und auch das externe Modell die Aufrufzeit festhält, können sich dann innerhalb eines Sekundenfensters aus drei Logbüchern die Nutzerhandlung rekonstruieren lassen? Das ist der Punkt, an dem die OpenGradient-Privatsphäre zwar schon freundlich ist, aber dort sollte sie wirklich weiter untersucht werden.$OPG #OPG @OpenGradient #opg $OPG
Diese Aussage wird erst einmal lokal eingekapselt. Was HPKE tut, ist sehr direkt: Es verpackt den Prompt in einen Umschlag, den nur das Ziel-Enclave öffnen kann. Der Relay sieht, dass das Paket kommt, sieht die Zeit und vielleicht sogar, wie groß es ist, aber sieht nicht den Klartext. Es schützt vor neugierigen Blicken auf der Routing-Ebene. Und was nicht gehalten werden kann, ist ebenfalls klar: Wenn der öffentliche Schlüssel des Ziels ausgetauscht wird oder der Nutzer sich mit einem falschen Einstiegspunkt verbindet, kann der Umschlag an die falsche Tür gehen.
Weiter geht es mit OHTTP. Der Name ist hart, aber im Grunde ist es, als würde man das Versandetikett in zwei Hälften reißen. Der Relay erhält die Informationen des Absenders, bekommt aber den Inhalt nicht; das Gateway schickt die Sache weiter, sollte jedoch nicht wissen, wer der ursprüngliche Absender war. Das Unintuitive daran ist genau hier: Die Privatsphäre von OpenGradient Chat verlässt sich nicht darauf, dass eine einzige Ebene sauber ist, sondern darauf, dass sich ein einzelner „Schmutz“ nicht vollständig zusammensetzen lässt. Wenn der Relay kompromittiert ist, hat der Angreifer nur IP, Zeit und Paketlänge; wenn das Gateway kompromittiert ist, weiß es nur, dass es irgendwohin einen Chiffretext gibt.
Erst nachdem der Chiffretext in ein TEE gelangt, wird er geöffnet. Das TEE ist ein hardwareisoliertes kleines Zimmer, das verhindert, dass der Host den Speicher ausliest oder den Ausführungscode willkürlich verändert. Hier geht es nicht darum, dass „der Server behauptet, sicher zu sein“, sondern dass das Enclave ein Attestation ausgibt: Es zeigt, dass Zimmer, Code und Ausführungsidentität zusammenpassen. Es gibt aber auch Grenzen: Wenn der Enclave-Code Sicherheitslücken hat oder eine externe Modell-Schnittstelle Klartext-Logs speichert, kann die Privatsphäre durch eine Seitentür entweichen.
Am nützlichsten ist diese Mechanik dort, wo sie typische Risiken in kleine Bruchstücke zerlegt. Der Betrieb will den Prompt sehen, kommt aber nur an den Chiffretext. Der Relay möchte Nutzer und Problem zuordnen, bekommt jedoch nur die halbe Seite. Die Plattform möchte, dass du der Umgebung direkt vertraust; Attestation macht aus „Glaub mir“ ein „prüf mich“. Aber ich beobachte noch eine Grauzone: Wenn der Relay langfristig Paketlänge und Zeit speichert, das Gateway Zielaufzeichnungen speichert und auch das externe Modell die Aufrufzeit festhält, können sich dann innerhalb eines Sekundenfensters aus drei Logbüchern die Nutzerhandlung rekonstruieren lassen? Das ist der Punkt, an dem die OpenGradient-Privatsphäre zwar schon freundlich ist, aber dort sollte sie wirklich weiter untersucht werden.$OPG #OPG @OpenGradient #opg $OPG