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 im Transit (TLS) und im Ruhezustand auf EU-Infrastruktur verschlüsselt. Cloud-Sync ist nicht Ende-zu-Ende-verschlüsselt; als Verantwortlicher kann Fluera technisch auf synchronisierte Inhalte zugreifen — wir verkaufen sie nie und nutzen sie nicht für Werbung.
- 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
Der gesamte Netzwerkverkehr läuft über TLS 1.3 mit modernen Cipher Suites.
Synchronisierung zwischen Geräten
Cloud-Sync, wenn aktiviert, überträgt deine Hefte verschlüsselt im Transit (TLS) zum Sync-Server (Supabase Storage, Region EU, eu-north-1), wo sie verschlüsselt im Ruhezustand auf EU-Infrastruktur gespeichert werden. Cloud-Sync ist nicht Ende-zu-Ende-verschlüsselt: Als Verantwortlicher kann Fluera technisch auf synchronisierte Inhalte zugreifen. Wir verkaufen diese Inhalte nie und nutzen sie nicht für Werbung. Die Synchronisierung ist pro Heft Opt-in — du kannst manche Hefte nur lokal halten, während du andere synchronisierst.
Wenn du ein Heft nur lokal hältst, bleibt es ausschließlich in der mit SQLCipher verschlüsselten On-Device-Datenbank und wird nie an unsere Server übertragen. Für maximale Vertraulichkeit kannst du ein Heft als verschlüsselte .fluera-Datei (AES-256-GCM) exportieren.
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 KI-Funktionen (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) nutzen Google-Gemini-Modelle, die über Google Vertex AI bereitgestellt und in der EU verarbeitet werden (europe-west4 NL / europe-west1 BE). Die Aufrufe laufen über einen Proxy, der 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 die KI 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 lorenco@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 lorenco@fluera.dev verfügbar.