Threat model
We gaan uit van diefstal van het apparaat, netwerkonderschepping en accidentele blootstelling via backup of cloud sync. We gaan ervan uit dat gebruikersgegevens gecompromitteerd kunnen raken. We gaan niet uit van statelijke tegenstanders met fysieke toegang tot ontgrendelde apparaten — Fluera is geen geheimhoudingstool, het is een studietool.
Binnen dat model gelden drie garanties:
- Lokale data zijn onleesbaar zonder de sleutel. Een gestolen apparaat levert een versleutelde blob op.
- Gesynchroniseerde data zijn voor ons onleesbaar. De cloud bewaart alleen ciphertext. De afleiding gebeurt op het apparaat.
- Telemetrie is consensueel en gedeïdentificeerd. De analytics kunnen een gebruiker zelfs bij een volledige breach niet aan zijn content koppelen.
In rust: SQLCipher, AES-256
Elk Fluera-notitieboek leeft in een lokale SQLite-database, versleuteld met SQLCipher — een breed geaudit ed extensie die elke pagina van de database transparant versleutelt met AES-256-CBC en HMAC-SHA512-integriteitscontroles per pagina.
De sleutelafleiding gebruikt PBKDF2 met SHA-256, 256.000 iteraties (conform OWASP). De passphrase wordt bewaard in de keychain van het platform — Keychain op iOS/macOS, Keystore op Android, DPAPI op Windows, libsecret op Linux. Het wordt nooit naar onze servers gestuurd.
In transit: TLS 1.3, certificate pinning
Al het netwerkverkeer is TLS 1.3 met moderne ciphers. Op iOS en Android pinnen we de certificaten aan onze CA-keten om man-in-the-middle door corporate proxies te voorkomen — met gedocumenteerde override voor netwerkbeheerders die dat nodig hebben.
Synchronisatie tussen apparaten: end-to-end
Cloud sync, indien ingeschakeld, gebruikt een aparte set sleutels die op het apparaat wordt afgeleid. De sync-server (Supabase Storage, EU-regio) bewaart ciphertext en kan niet ontsleutelen. De synchronisatie is opt-in per notitieboek — je kunt sommige alleen lokaal houden terwijl je andere synchroniseert.
Sleutelrotatie: vanaf elk apparaat starten versleutelt alle toekomstige payloads opnieuw met een nieuwe sleutel. Oude ciphertexts blijven leesbaar voor oudere clients totdat je de migratie op alle apparaten bevestigt.
P2P-samenwerking: direct, versleuteld
Realtime samenwerking gebruikt WebRTC DataChannel met DTLS-SRTP-versleuteling. Supabase Realtime fungeert alleen als signaling-broker — voor het opzetten van de verbinding — niet als relay van het werkelijke canvasverkeer. Na de handshake stromen canvasbewerkingen peer-to-peer. De server ziet ze niet.
Bij restrictieve NAT's gaan we via TURN; in dat geval ziet de relay alleen versleutelde DTLS-pakketten die hij niet kan ontsleutelen.
AI-aanroepen: via proxy, nooit direct
Aanroepen naar Google Gemini (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) lopen via een Supabase Edge Function die de API key op de server bewaart. Cliënt-apparaten zien de sleutel nooit. De proxy past rate limiting toe per plan en logt de duur van de calls voor accounting — nooit de inhoud van het canvas.
Als je de AI-functies uitschakelt in Instellingen → Privacy, wordt geen canvasinhoud naar Gemini gestuurd, ook niet als fallback voor on-device OCR.
Telemetrie: opt-in, gehasht, allowlisted
Productanalytics staan standaard uit. Wanneer ze ingeschakeld zijn, zijn de events beperkt tot een server-side whitelist (sessie start/einde, aanroep van een functie, duur van AI-call — nooit inhoud). De gebruikers-ID wordt op het apparaat met SHA-256 gehasht; de plaintext-ID verlaat de client nooit. Events worden 180 dagen bewaard, daarna geaggregeerd of verwijderd.
Audittrail (institutionele accounts)
Elke toegang tot gedeelde notitieboeken — wie, vanaf welk apparaat, wanneer — wordt geschreven naar een append-only audittrail. Beheerders kunnen de trail exporteren als CSV of JSON voor compliance-controles. De trail is write-once: verwijderen vereist een gedocumenteerde motivatie en wordt zelf ook gelogd.
Recovery en sleutelverlies
Als je je passphrase verliest, worden de versleutelde data onherstelbaar. Dat is opzettelijk — het alternatief zou een herstelpad zijn dat het versleutelingsmodel noodzakelijkerwijs zou verzwakken. Voor institutionele accounts kan een optionele recovery-sleutel worden geconfigureerd die de beheerder bewaart; het is een gedocumenteerde trade-off die de instelling bewust kiest.
Responsible disclosure
Beveiligingsonderzoekers zijn welkom. Meld kwetsbaarheden aan security@fluera.dev met PGP-versleuteling (sleutel gepubliceerd op het GitHub-profiel). We reageren binnen 24 uur, patchen kritieke issues binnen 72 uur, en crediteren melders in de hall of fame, tenzij om anonimiteit wordt gevraagd.
Scope: de Fluera-app (alle platformen), de sync-service, de AI-proxy en deze marketingsite. Buiten scope: third-party services (Supabase, Google, Apple, Sentry, RevenueCat) — meld die bij de betreffende vendors.
Externe audits
Fluera heeft op dit moment geen SOC 2- of ISO 27001-certificering. Beide staan op de enterprise roadmap en worden publiekelijk aangekondigd zodra ze afgerond zijn. We verklaren liever geen controles die we niet onafhankelijk hebben geverifieerd.
De lijst met subverwerkers is openbaar en up-to-date. De Data Processing Agreement is op aanvraag beschikbaar via privacy@fluera.dev.