Threat Model
Vi antager tyveri af enheden, opsnapning på netværket og utilsigtet eksponering via backup eller cloud-sync. Vi antager, at brugerens credentials kan kompromitteres. Vi antager ikke statslige aktører med fysisk adgang til ulåste enheder — Fluera er ikke et hemmeligholdelsesværktøj, det er et læringsværktøj.
Inden for den model gælder tre garantier:
- Lokale data er ulæselige uden nøglen. En stjålet enhed producerer en krypteret blob.
- Synkroniserede data er ulæselige for os. Cloudet gemmer kun chiffertekst. Udledningen sker på enheden.
- Telemetri er samtykkebaseret og afidentificeret. Analytics kan ikke forbinde en bruger med dennes indhold, ikke engang i tilfælde af et fuldt breach.
I hvile: SQLCipher, AES-256
Hver notesbog i Fluera lever i en lokal SQLite-database krypteret med SQLCipher — en bredt revideret udvidelse, der transparent krypterer hver side af databasen med AES-256-CBC og kontrollerer integriteten pr. side med HMAC-SHA512.
Nøgleudledningen bruger PBKDF2 med SHA-256 og 256.000 iterationer (i tråd med OWASP). Adgangsfrasen opbevares i platformens keychain — Keychain på iOS/macOS, Keystore på Android, DPAPI på Windows, libsecret på Linux. Den sendes aldrig til vores servere.
Under transport: TLS 1.3, certificate pinning
Al netværkstrafik kører over TLS 1.3 med moderne cipher suites. På iOS og Android pinner vi certifikaterne til vores CA-kæde for at forhindre man-in-the-middle gennem enterprise-proxyer — med dokumenteret override for netværksadministratorer, der har brug for det.
Synkronisering mellem enheder: end-to-end
Cloud-sync, når den er aktiveret, bruger et separat nøglesæt udledt på enheden. Sync-serveren (Supabase Storage, region EU) gemmer chiffertekst og kan ikke dekryptere. Synkronisering er opt-in pr. notesbog — du kan holde nogle notesbøger lokalt, mens du synkroniserer andre.
Nøglerotation: når den startes fra en hvilken som helst enhed, krypterer den alle fremtidige payloads med en ny nøgle. Gamle chiffertekster forbliver læsbare for ældre klienter, indtil du bekræfter migreringen på alle enheder.
P2P-samarbejde: direkte, krypteret
Realtidssamarbejdet bruger WebRTC DataChannel med DTLS-SRTP-kryptering. Supabase Realtime fungerer kun som signaling-broker — opbygning af forbindelsen — ikke som relay for selve canvas-trafikken. Efter håndtrykket flyder canvas-redigeringer peer-to-peer. Serveren ser dem ikke.
Ved restriktive NAT'er går trafikken via TURN; i det tilfælde ser relay'et kun krypterede DTLS-pakker, som det ikke kan dekryptere.
AI-kald: via proxy, aldrig direkte
Kaldene til Google Gemini (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) går via en Supabase Edge Function, der holder API-nøglen på serveren. Klient-enhederne ser aldrig nøglen. Proxyen håndhæver rate-limits pr. plan og logger kaldenes varigheder til faktureringsformål — aldrig canvas-indholdet.
Hvis du deaktiverer AI-funktionerne under Indstillinger → Privatliv, sendes intet canvas-indhold til Gemini, heller ikke som fallback for on-device-OCR.
Telemetri: opt-in, hashet, allowlistet
Produkt-analytics er deaktiveret som standard. Når den er aktiveret, er hændelserne begrænset til en server-side whitelist (start/slut på session, kald af en funktion, varighed af et AI-kald — aldrig indhold). Bruger-ID'et hashes på enheden med SHA-256; klartekst-ID'et forlader aldrig klienten. Hændelserne opbevares i 180 dage og aggregeres eller slettes derefter.
Audit-trail (institutionelle konti)
Enhver adgang til delte notesbøger — hvem, fra hvilken enhed, hvornår — skrives til en append-only audit-trail. Administratorer kan eksportere trailet som CSV eller JSON til compliance-kontroller. Trailet er write-once: fjernelse kræver en dokumenteret begrundelse og logges selv.
Recovery og nøgletab
Hvis du mister adgangsfrasen, bliver de krypterede data uigenkaldelige. Det er bevidst — alternativet ville være en recovery-sti, der nødvendigvis ville svække krypteringsmodellen. For institutionelle konti kan en valgfri, administratorforvalt recovery-nøgle konfigureres; det er en dokumenteret afvejning, som institutionen bevidst vælger.
Responsible disclosure
Sikkerhedsforskere er velkomne. Rapportér sårbarheder til security@fluera.dev med PGP-kryptering (nøgle offentliggjort på GitHub-profilen). Vi svarer inden for 24 timer, patcher kritiske problemer inden for 72 og nævner indberettere i Hall of Fame, medmindre anonymitet ønskes.
Scope: Fluera-appen (alle platforme), sync-tjenesten, AI-proxyen og denne marketing-side. Uden for scope: tredjeparter (Supabase, Google, Apple, Sentry, RevenueCat) — rapportér der til de respektive leverandører.
Eksterne audits
Fluera har i øjeblikket hverken SOC-2- eller ISO-27001-certificeringer. De er på enterprise-roadmappen og annonceres offentligt, når de afsluttes. Vi foretrækker ikke at deklarere kontroller, vi ikke kan verificere uafhængigt.
Listen over underdatabehandlere er offentlig og opdateret. Databehandleraftalen er tilgængelig på anmodning hos privacy@fluera.dev.