Summary

  • Der MIMI-Protokollentwurf, Revision 07, vom 2. November 2026 beschreibt verschlüsselte Anhänge auf externen Servern. Ein ExternalPart in der Nachricht enthält ihre HTTPS-Adresse.
  • Beim direkten Abruf sieht der Dateiserver IP-Adresse und Zeitpunkt des Lesers. Beim Hub-Proxy verschwinden diese Daten für den Dateiserver, doch der empfangende Anbieter kann URL, Nutzer und Raum weiterhin zusammenführen.
  • Oblivious HTTP trennt Relay und Gateway. Der Entwurf verlangt ein Gateway beim Hub und empfiehlt Relay-Funktion bei anderen Anbietern.

Ein Bild liegt verschlüsselt auf einem Dateiserver. Die Gruppe, die es teilt, besteht aus Nutzern mehrerer Messenger. In der Nachricht steht die Adresse des Bildes. Sobald ein Empfänger es öffnet, läuft neben dem geschützten Gespräch ein Netzabruf an. Er hat einen Absender, ein Ziel und einen Zeitpunkt. Wer diese drei Daten erhält, hängt von der Infrastruktur ab, nicht vom Verschlüsselungszeichen im Chatfenster.

Der MLS-Standard RFC 9420 schützt Gruppeninhalte. MIMI organisiert die Kommunikation zwischen Anbietern und führt Anhänge als eigenständige verschlüsselte Objekte. Im begleitenden Entwurf zur Raumpolitik legt asset_policy fest, welche Speicherdomänen zugelassen sind. Eine scheinbar technische Liste entscheidet damit, welcher Betreiber überhaupt eine Chance erhält, Abrufe zu beobachten.

Direkt heißt: Der Dateiserver bekommt den Leser

Der kürzeste Weg führt vom Gerät unmittelbar zum Dateiserver. Nach Abschnitt 5.10 des MIMI-Entwurfs sieht dieser die IP-Adresse des Empfängers und die Abrufzeit. Wiederholte Anfragen für dasselbe Objekt können Anwesenheit oder gemeinsame Raumzugehörigkeit nahelegen. Für Abrufe über Anbietergrenzen nennt der Entwurf den Direktweg NOT RECOMMENDED. Der Server muss die Datei dafür nicht entschlüsseln. Seine Zugriffsprotokolle genügen.

Die zweite Variante schickt den Abruf über den Anbieter des Empfängers und den Hub des Raums. Der Anbieter ruft beim Hub GET /proxyDownload/{downloadUrl} auf; der Hub holt die Datei. Dem Dateiserver erscheint der Hub als Gegenstelle. Auch der Hub erhält bei diesem Abruf nicht die Client-IP. Er sieht den anfragenden Anbieter und die Ziel-URL, aber keine ausdrückliche Nutzer- oder Raumkennung. So wird eine Beobachtung beim Dateiserver tatsächlich entfernt.

Der empfangende Anbieter ist näher am Leser. Er kennt dessen Konto und die angeforderte URL. Der Entwurf beschreibt, dass er URLs Nutzern zuordnen und daraus auf Räume schließen kann. Er kann außerdem Zeitpunkte eingehender Raumnachrichten mit ausgehenden Proxy-Anfragen vergleichen. Zwischenspeicher beim Anbieter oder Hub können solche Zuordnungen erschweren, weil nicht jeder Klick einen neuen Abruf auslöst. Der Hub muss den Proxy anbieten und das Ziel auf konfigurierte Dateiserverdomänen der Partner beschränken. Andernfalls würde aus dem Anhangdienst ein offener Proxy.

OHTTP verteilt die Sicht auf zwei Betreiberrollen

Im dritten Weg sendet der Client eine OHTTP-Anfrage an ein Relay beim empfangenden Anbieter. Das Gateway beim Hub öffnet die geschützte Zielanfrage und holt die Datei. RFC 9458 definiert die Arbeitsteilung: Das Relay sieht die clientseitige Verbindung, aber nicht das geschützte Ziel; das Gateway sieht das Ziel, aber nicht die ursprüngliche Clientverbindung, sofern die Rollen getrennt bleiben. MIMI verlangt das Hub-Gateway, empfiehlt Relays bei den übrigen Anbietern und begrenzt Gateway-Ziele auf konfigurierte Partnerdomänen.

Der ausdrücklich genannte Gewinn: Der Anbieter des Empfängers erfährt nicht mehr direkt jede Domäne, von der seine Nutzer Anhänge holen. Das Gateway kennt das Ziel weiterhin. Das Relay kennt den Nutzer und den Zeitpunkt. Gemeinsame Protokolle oder eng abgestimmte Zeiten können die getrennten Beobachtungen wieder zusammenbringen. Wer eine solche Architektur betreibt, muss daher benennen, wer Relay und Gateway kontrolliert, wer Protokolle speichern darf und wer sie zusammenführen könnte.

Für einen realen Einsatz liefert der Entwurf keine gemessene Trefferquote bei der Erkennung von Raumzugehörigkeit. Ein Versuch mit demselben Anhang über alle drei Wege, jeweils mit und ohne Cache, würde die tatsächlichen Sichten der Beteiligten zeigen. Bis dahin ist die konkrete Entscheidung klar: Wer nur die Datei verschlüsselt, hat den Abrufweg noch nicht gestaltet. Über ihn wird entschieden, bei welchem Anbieter die Gästeliste landet.

MIMI-Entwurf · RFC 9458 · RFC 9420 · MIMI-Raumpolitik