Threat Model
Wir nehmen Diebstahl des Geräts, Abfangen im Netzwerk und versehentliche Offenlegung über Backup oder Cloud-Sync an. Wir nehmen an, dass die Anmeldedaten der Nutzer/innen kompromittiert werden können. Nicht annehmen wir staatliche Akteure mit physischem Zugriff auf entsperrte Geräte — Fluera ist kein Geheimhaltungswerkzeug, es ist ein Lernwerkzeug.
Innerhalb dieses Modells drei Garantien:
- Lokale Daten sind ohne den Schlüssel unlesbar. Ein gestohlenes Gerät produziert ein verschlüsseltes Blob.
- Synchronisierte Daten sind für uns unlesbar. Die Cloud speichert nur Ciphertext. Die Ableitung geschieht auf dem Gerät.
- Telemetrie ist einvernehmlich und de-identifiziert. Die Analytik kann eine/n Nutzer/in nicht mit ihrem Inhalt verbinden, nicht einmal im Fall eines vollständigen Breach.
Im Ruhezustand: SQLCipher, AES-256
Jedes Heft in Fluera lebt in einer lokalen, mit SQLCipher verschlüsselten SQLite-Datenbank — einer breit auditierten Erweiterung, die jede Seite der Datenbank transparent mit AES-256-CBC verschlüsselt und pro Seite mit HMAC-SHA512 auf Integrität prüft.
Die Schlüsselableitung verwendet PBKDF2 mit SHA-256 und 256.000 Iterationen (im Einklang mit OWASP). Die Passphrase wird im Keychain der Plattform aufbewahrt — Keychain unter iOS/macOS, Keystore unter Android, DPAPI unter Windows, libsecret unter Linux. Sie wird nie an unsere Server gesendet.
Im Transit: TLS 1.3, Certificate Pinning
Der gesamte Netzwerkverkehr läuft über TLS 1.3 mit modernen Cipher Suites. Unter iOS und Android pinnen wir die Zertifikate auf unsere CA-Kette, um Man-in-the-Middle durch Unternehmens-Proxys zu verhindern — mit dokumentiertem Override für Netzwerkadministratoren, die ihn brauchen.
Synchronisierung zwischen Geräten: Ende-zu-Ende
Cloud-Sync, wenn aktiviert, verwendet einen separaten, auf dem Gerät abgeleiteten Schlüsselsatz. Der Sync-Server (Supabase Storage, Region EU) speichert Ciphertext und kann nicht entschlüsseln. Die Synchronisierung ist pro Heft Opt-in — du kannst manche Hefte nur lokal halten, während du andere synchronisierst.
Schlüsselrotation: Wird sie von einem beliebigen Gerät gestartet, verschlüsselt sie alle zukünftigen Payloads mit einem neuen Schlüssel neu. Alte Ciphertexts bleiben für ältere Clients lesbar, bis du die Migration auf allen Geräten bestätigst.
P2P-Kollaboration: direkt, verschlüsselt
Die Echtzeit-Kollaboration nutzt WebRTC DataChannel mit DTLS-SRTP-Verschlüsselung. Supabase Realtime fungiert nur als Signaling-Broker — Verbindungsaufbau — nicht als Relay des eigentlichen Canvas-Verkehrs. Nach dem Handshake fließen die Canvas-Bearbeitungen Peer-to-Peer. Der Server sieht sie nicht.
Bei restriktiven NATs läuft der Verkehr über TURN; in diesem Fall sieht das Relay nur verschlüsselte DTLS-Pakete, die es nicht entschlüsseln kann.
KI-Aufrufe: über Proxy, niemals direkt
Die Aufrufe an Google Gemini (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) laufen über eine Supabase Edge Function, die den API-Schlüssel auf dem Server hält. Die Client-Geräte sehen den Schlüssel nie. Der Proxy erzwingt Rate-Limits pro Plan und protokolliert die Aufrufdauern zu Abrechnungszwecken — niemals den Canvas-Inhalt.
Wenn du die KI-Funktionen unter Einstellungen → Datenschutz deaktivierst, wird kein Canvas-Inhalt an Gemini gesendet, auch nicht als Fallback für On-Device-OCR.
Telemetrie: Opt-in, gehasht, allowlisted
Die Produkt-Analytik ist standardmäßig deaktiviert. Wenn aktiviert, sind die Ereignisse auf eine serverseitige Whitelist beschränkt (Sitzungsbeginn/-ende, Aufruf einer Funktion, Dauer eines KI-Aufrufs — niemals Inhalt). Die Nutzer-ID wird auf dem Gerät mit SHA-256 gehasht; die Klartext-ID verlässt den Client nie. Die Ereignisse werden 180 Tage aufbewahrt und danach aggregiert oder gelöscht.
Audit-Trail (Institutionelle Konten)
Jeder Zugriff auf geteilte Hefte — wer, von welchem Gerät, wann — wird in einen append-only Audit-Trail geschrieben. Die Administratoren können den Trail als CSV oder JSON für Compliance-Kontrollen exportieren. Der Trail ist write-once: Eine Entfernung erfordert eine dokumentierte Begründung und wird selbst geloggt.
Recovery und Schlüsselverlust
Wenn du die Passphrase verlierst, werden die verschlüsselten Daten unwiederbringlich. Das ist beabsichtigt — die Alternative wäre ein Recovery-Pfad, der das Verschlüsselungsmodell zwangsläufig schwächen würde. Für institutionelle Konten lässt sich ein optionaler, vom Administrator verwahrter Recovery-Schlüssel konfigurieren; das ist ein dokumentierter Trade-off, den die Institution bewusst wählt.
Responsible Disclosure
Sicherheitsforscher/innen sind willkommen. Melde Schwachstellen an security@fluera.dev mit PGP-Verschlüsselung (Schlüssel veröffentlicht im GitHub-Profil). Wir antworten innerhalb von 24 Stunden, patchen kritische Probleme innerhalb von 72 und nennen die Meldenden in der Hall of Fame, sofern keine Anonymität gewünscht wird.
Scope: die Fluera-App (alle Plattformen), der Sync-Dienst, der KI-Proxy und diese Marketing-Website. Außerhalb des Scopes: Drittanbieter (Supabase, Google, Apple, Sentry, RevenueCat) — melde dort den jeweiligen Anbietern.
Externe Audits
Fluera hat derzeit weder SOC-2- noch ISO-27001-Zertifizierungen. Sie stehen auf der Enterprise-Roadmap und werden bei Abschluss öffentlich angekündigt. Wir ziehen es vor, keine Kontrollen zu deklarieren, die wir nicht unabhängig verifizieren.
Die Liste der Auftragsverarbeiter ist öffentlich und aktuell. Das Data Processing Agreement ist auf Anfrage unter privacy@fluera.dev verfügbar.