Threat model
Assumiamo furto del dispositivo, intercettazione di rete ed esposizione accidentale via backup o cloud sync. Assumiamo che le credenziali dell'utente possano essere compromesse. Non assumiamo avversari di livello statale con accesso fisico a dispositivi sbloccati — Fluera non è uno strumento di segretezza, è uno strumento di studio.
Dentro quel modello, tre garanzie:
- I dati locali sono illeggibili senza la chiave. Un dispositivo rubato produce un blob cifrato.
- I dati sincronizzati sono illeggibili per noi. Il cloud tiene solo ciphertext. La derivazione avviene sul dispositivo.
- La telemetria è consensuale e de-identificata. Gli analytics non possono collegare un utente ai suoi contenuti nemmeno in caso di breach completo.
At-rest: SQLCipher, AES-256
Ogni quaderno Fluera vive in un database SQLite locale cifrato con SQLCipher — un'estensione ampiamente verificata che cifra trasparentemente ogni pagina del database con AES-256-CBC e integrity check HMAC-SHA512 per pagina.
La derivazione della chiave usa PBKDF2 con SHA-256, 256.000 iterazioni (allineato a OWASP). La passphrase è custodita nel keychain della piattaforma — Keychain su iOS/macOS, Keystore su Android, DPAPI su Windows, libsecret su Linux. Non viene mai inviata ai nostri server.
In transito: TLS 1.3, certificate pinning
Tutto il traffico di rete è TLS 1.3 con cifrari moderni. Su iOS e Android facciamo pinning dei certificati sulla nostra catena di CA per prevenire man-in-the-middle di proxy aziendali — con override documentato per gli amministratori di rete che ne hanno bisogno.
Sync tra dispositivi: end-to-end cifrato
Il cloud sync, quando attivato, usa un set di chiavi separato derivato sul dispositivo. Il server di sync (Supabase Storage, regione UE) tiene ciphertext e non può decifrare. Il sync è opt-in per quaderno — puoi tenerne alcuni solo locali mentre ne sincronizzi altri.
Rotazione delle chiavi: avviarla da qualsiasi dispositivo re-cifra tutti i payload futuri con una nuova chiave. I ciphertext vecchi restano leggibili per i client più vecchi finché non confermi la migrazione su tutti i dispositivi.
Collaborazione P2P: diretta, cifrata
La collaborazione real-time usa WebRTC DataChannel con cifratura DTLS-SRTP. Supabase Realtime fa solo da broker di signaling — setup della connessione — non da relay per il traffico vero del canvas. Dopo l'handshake, gli edit del canvas fluiscono peer-to-peer. Il server non li vede.
Su NAT restrittivi passiamo via TURN, nel qual caso il relay vede solo pacchetti DTLS cifrati che non può decrittare.
Chiamate AI: via proxy, mai dirette
Le chiamate a Google Gemini (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) passano attraverso una Supabase Edge Function che custodisce la API key lato server. I dispositivi client non vedono mai la chiave. Il proxy applica i rate limit per piano e logga le durate delle chiamate per la contabilità — mai il contenuto del canvas.
Se disattivi le funzioni AI in Impostazioni → Privacy, nessun contenuto del canvas viene inviato a Gemini, nemmeno per fallback OCR on-device.
Telemetria: opt-in, hashata, allowlisted
Gli analytics di prodotto sono disattivati di default. Quando attivati, gli eventi sono limitati a una whitelist lato server (inizio/fine sessione, invocazione feature, durata chiamata AI — mai contenuto). L'ID utente è hashato SHA-256 sul dispositivo; l'ID in chiaro non lascia mai il client. Gli eventi sono conservati 180 giorni, poi aggregati o eliminati.
Audit log (account Istituzionali)
Ogni accesso ai quaderni condivisi — chi, da quale dispositivo, quando — viene scritto in un audit log append-only. Gli amministratori possono esportare il log in CSV o JSON per i controlli di compliance. Il log è write-once: la cancellazione richiede una motivazione documentata ed è a sua volta loggata.
Recovery e perdita della chiave
Se perdi la passphrase, i dati cifrati diventano irrecuperabili. È intenzionale — l'alternativa sarebbe un percorso di recovery che indebolirebbe necessariamente il modello di cifratura. Per gli account Istituzionali, si può configurare una chiave di recovery opzionale custodita dall'amministratore; è un trade-off documentato su cui l'istituzione sceglie consapevolmente.
Responsible disclosure
I security researcher sono benvenuti. Segnala le vulnerabilità a security@fluera.dev con cifratura PGP (chiave pubblicata sul profilo GitHub). Riceviamo riscontro entro 24 ore, patch dei problemi critici entro 72, e citiamo chi segnala nella hall of fame salvo richiesta di anonimato.
Scope: l'app Fluera (tutte le piattaforme), il servizio di sync, il proxy AI e questo sito marketing. Fuori scope: servizi terzi (Supabase, Google, Apple, Sentry, RevenueCat) — segnala ai vendor corrispondenti.
Valutazioni esterne
Fluera non ha attualmente certificazioni SOC 2 o ISO 27001. Sono sulla roadmap enterprise e saranno annunciate pubblicamente a completamento. Preferiamo non dichiarare controlli che non abbiamo verificato in modo indipendente.
La lista sub-processor è pubblica e aggiornata. Il Data Processing Agreement è disponibile su richiesta a privacy@fluera.dev.