Fluera

Architecture

How Fluera protects your notebook.

This page describes the security model at the level a technical reader — a security officer, a university CISO, a curious developer — would need. For the non-technical summary, start at /security.

Threat model

We assume device theft, network interception, and accidental exposure via backups or cloud sync. We assume the user's account credentials may be compromised. We do not assume state-level adversaries with physical access to unlocked devices — Fluera is not a secrecy tool, it is a study tool.

Within that model, three guarantees:

  • Local data is unreadable without the key. A stolen device yields an encrypted blob.
  • Synced data is unreadable to Fluera. The cloud holds ciphertext. Derivation happens on device.
  • Telemetry is consented and de-identified. Analytics cannot link a user to their content even if fully breached.

At rest: SQLCipher, AES-256

Every Fluera notebook lives in a local SQLite database encrypted with SQLCipher — a widely-audited extension that transparently encrypts every page of the database with AES-256-CBC and HMAC-SHA512 page integrity.

Key derivation uses PBKDF2 with SHA-256, 256,000 iterations (OWASP-aligned). The passphrase is held in the platform keychain — Keychain on iOS/macOS, Keystore on Android, DPAPI on Windows, libsecret on Linux. It is never sent to our servers.

In transit: TLS 1.3, certificate pinning

All network traffic is TLS 1.3 with modern ciphers only. On iOS and Android we pin certificates to our own CA chain to prevent man-in-the-middle attacks from corporate proxies — with a documented override for network administrators who need one.

Cross-device sync: end-to-end encrypted

Cloud sync, when enabled, uses a separate set of keys derived on the device. The sync server (Supabase Storage, EU region) holds ciphertext and cannot decrypt. Sync is opt-in per notebook — you can keep some local-only while syncing others.

Key rotation: initiating a rotation on any device re-encrypts all future sync payloads under a new key. Old ciphertext is kept readable for recovery by older clients until you confirm all devices have migrated.

P2P collaboration: direct, encrypted

Real-time collaboration uses WebRTC DataChannels with DTLS-SRTP encryption. Supabase Realtime acts as a signalling broker only — connection setup — not a relay for the actual canvas traffic. After handshake, canvas edits flow peer-to-peer. The server does not see them.

On restrictive NATs we fall back to a TURN relay, in which case the relay sees only encrypted DTLS packets it cannot decrypt.

AI calls: proxied, never direct

Calls to Google Gemini (Socratic mode, Ghost Map, LaTeX OCR, Exam Session) transit a Supabase Edge Function that holds the API key server-side. Client devices never see the API key. The proxy enforces per-plan rate limits and logs call durations for accounting — never the content of the canvas.

If you opt out of AI features in Settings → Privacy, no canvas content is ever sent to Gemini, even for on-device OCR fallbacks.

Telemetry: opt-in, hashed, allowlisted

Product analytics are disabled by default. When enabled, events are restricted to a server-side allowlist (session start/end, feature invocation, AI call duration — never content). The user ID is hashed SHA-256 on the device; the raw ID never leaves. Events are retained for 180 days then aggregated or deleted.

Audit log (Education accounts)

Every access to shared notebooks — who opened it, from which device, when — is written to an append-only audit log. Administrators can export the log as CSV or JSON for compliance reviews. The log is write-once: deletion requires a documented business reason and is itself logged.

Recovery and key loss

If you lose your passphrase, the encrypted data becomes unrecoverable. This is by design — the alternative is a recovery path that necessarily weakens the encryption model. For Education accounts, an optional administrator-held recovery key can be configured; this is a documented trade-off that institutions opt into knowingly.

Responsible disclosure

Security researchers are welcome. Report vulnerabilities to security@fluera.dev with PGP encryption (key published on the GitHub profile). We acknowledge within 24 hours, patch critical issues within 72, and credit reporters in our hall of fame unless anonymity is requested.

Scope: the Fluera app (all platforms), the sync service, the AI proxy, and this marketing site. Out of scope: third-party services (Supabase, Google, Apple, Sentry, RevenueCat) — report those to the respective vendors.

External assessments

Fluera does not currently hold SOC 2 or ISO 27001 certification. These are on the Enterprise roadmap and will be announced publicly when complete. We prefer not to claim controls we have not independently verified.

The sub-processor list is published and kept current. The Data Processing Agreement is available on request via privacy@fluera.dev.