Eine App, die Familienkommunikation und Aufsicht verbindet, muss erklären können, wer was sehen kann – und warum das technisch so ist. Hier stehen die Entscheidungen, die das festlegen.
Der naheliegende, falsche Weg wäre, den Server mitlesen und Inhalte an die Eltern weiterreichen zu lassen. Fluegge macht das Gegenteil: Das Elterngerät ist ein zusätzliches legitimes Endgerät in derselben verschlüsselten Gruppe. Es entschlüsselt mit eigenen Schlüsseln – der Server sieht in keinem Fall Klartext.
Genau dafür ist MLS (Messaging Layer Security, RFC 9420) gebaut: Gruppen mit vielen Geräten pro Person, sauberes Hinzufügen und Entfernen, und Nachrichtenschlüssel, die sich fortlaufend erneuern. Ein klassischer Zwei-Personen-Ratchet würde bei Klassengruppen mit Eltern- und Kindgeräten unhandlich.
Schlüsselverwaltung, Ver- und Entschlüsselung, Kopplungs-Handshake, Protokoll, verschlüsselte lokale Datenbank und Zustell-Queue liegen in einer gemeinsamen Bibliothek in Kotlin, die beide Android-Apps einbinden. Eine zweite Plattform gibt es nicht.
Der Grund ist unspektakulär und wichtig: Zwei Implementierungen desselben Krypto-Protokolls sind zwei Stellen, an denen ein Fehler stecken kann – und eine davon fällt garantiert später auf als die andere. Die Oberfläche darf pro App verschieden sein, der sicherheitskritische Teil nicht.
Der Server leitet verschlüsselte Pakete weiter, weckt Geräte mit einer leeren Push-Nachricht und hält verschlüsselte Mediendateien vor, bis sie abgeholt sind – mehr nicht. Die Benachrichtigung mit Absender und Text entsteht erst auf dem Gerät. Der Server ist nie die Instanz, die über Regeln entscheidet.
Die Infrastruktur steht bei europäischen Anbietern. Das ist keine Marketing-Zeile, sondern eine gesetzte Rahmenbedingung des Projekts.
Keine der beiden Apps lädt zur Laufzeit Code nach. Eine neue Fassung kommt als ganze App: geladen, gegen ihre Prüfsumme geprüft und über den Installationsdialog von Android bestätigt – nie still im Hintergrund.
Schlüssel und Verlauf liegen verschlüsselt auf dem Gerät, je Kind ein eigenes Profil, geschützt durch PIN oder Bildfolge. Die Sperre nach fünf Fehlversuchen, die nur ein Guardian aufhebt, ist beschrieben, aber noch nicht gebaut.
Fluegge verlangt kein blindes Vertrauen in einen Server. Schutz entsteht Schritt für Schritt auf den Geräten – dort, wo Nachrichten geschrieben und gelesen werden.
Ein neues Kindgerät kommt nur über einen fünf Minuten gültigen, einmal verwendbaren Kopplungscode hinzu. Der Code öffnet keine Nachrichten und enthält keine geheimen Schlüssel.
Gemeinsam vor OrtJedes Gerät erzeugt seine privaten Schlüssel selbst. Sie bleiben im geschützten Gerätespeicher und werden weder im Kopplungscode noch an den Server geschickt.
Nur auf dem GerätBerechtigte Geräte werden als eigene Teilnehmer aufgenommen. Auch das Elterngerät entschlüsselt mit einem eigenen Schlüssel – nicht über einen geheimen Zugang des Servers.
Nachprüfbare MitgliedschaftEine Nachricht wird vor dem Verlassen des Geräts verschlüsselt. Der Server befördert nur den verschlossenen Umschlag; öffnen kann ihn erst ein berechtigtes Empfängergerät.
Server ohne Nachrichtenschlüsselkönnen Nachrichten lesen und schreiben.
sieht Zustellinformationen wie Ziel, Zeitpunkt und Größe – aber keinen Inhalt. Und keine Kennung trägt eine E-Mail-Adresse, Telefonnummer oder einen geprüften Namen – nur einen frei gewählten Anzeigenamen: Ein Guardian ist eine zufällige Kennung mit einem Schlüssel, der auf dem Gerät bleibt.
erhalten keinen Nachrichtenschlüssel.
Aufsicht ist bei Fluegge kein heimliches Mitlesen: Das Kind sieht jederzeit, welche Freigabestufen für es gelten – ob mitgelesen wird, was es senden darf und ob Medien vorher kontrolliert werden. Alle Guardians einer Familie sind dabei gleichberechtigt; jede Änderung wird protokolliert und an alle verteilt.
Ebenso wichtig: Spiegelung ist an die Freigabestufe „Mitlesen“ gebunden und auf dem Kindgerät erkennbar – heimliche Überwachung ist ausdrücklich nicht das Ziel.
Impressum und Datenschutzerklärung gelten für alle Bereiche dieser Seite.
