Threat model
Asumimos robo del dispositivo, interceptación de red y exposición accidental vía backup o cloud sync. Asumimos que las credenciales del usuario pueden verse comprometidas. No asumimos adversarios a nivel estatal con acceso físico a dispositivos desbloqueados — Fluera no es una herramienta de sigilo, es una herramienta de estudio.
Dentro de ese modelo, tres garantías:
- Los datos locales son ilegibles sin la clave. Un dispositivo robado produce un blob cifrado.
- Los datos sincronizados son ilegibles para nosotros. La nube guarda solo ciphertext. La derivación ocurre en el dispositivo.
- La telemetría es consensuada y desidentificada. Los analytics no pueden ligar a un usuario con su contenido ni siquiera en caso de breach completo.
En reposo: SQLCipher, AES-256
Cada cuaderno de Fluera vive en una base SQLite local cifrada con SQLCipher — una extensión ampliamente auditada que cifra de forma transparente cada página de la base con AES-256-CBC y verificación de integridad HMAC-SHA512 por página.
La derivación de la clave usa PBKDF2 con SHA-256, 256.000 iteraciones (alineado con OWASP). La passphrase se guarda en el keychain de la plataforma — Keychain en iOS/macOS, Keystore en Android, DPAPI en Windows, libsecret en Linux. Nunca se envía a nuestros servidores.
En tránsito: TLS 1.3, certificate pinning
Todo el tráfico de red es TLS 1.3 con cifras modernas. En iOS y Android hacemos pinning de los certificados a nuestra cadena de CA para evitar man-in-the-middle de proxies corporativos — con override documentado para administradores de red que lo necesiten.
Sincronización entre dispositivos: extremo a extremo
El cloud sync, cuando está activado, usa un conjunto de claves separado derivado en el dispositivo. El servidor de sincronización (Supabase Storage, región UE) guarda ciphertext y no puede descifrar. La sincronización es opt-in por cuaderno — puedes mantener algunos solo en local mientras sincronizas otros.
Rotación de claves: iniciarla desde cualquier dispositivo recifra todos los payloads futuros con una clave nueva. Los ciphertexts antiguos siguen siendo legibles para clientes más antiguos hasta que confirmes la migración en todos los dispositivos.
Colaboración P2P: directa, cifrada
La colaboración en tiempo real usa WebRTC DataChannel con cifrado DTLS-SRTP. Supabase Realtime actúa solo como broker de signaling — setup de la conexión — no como relay del tráfico real del canvas. Tras el handshake, las ediciones del canvas fluyen peer-to-peer. El servidor no las ve.
En NATs restrictivos pasamos vía TURN, en cuyo caso el relay solo ve paquetes DTLS cifrados que no puede descifrar.
Llamadas de IA: vía proxy, nunca directas
Las llamadas a Google Gemini (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) pasan por una Supabase Edge Function que guarda la API key en el servidor. Los dispositivos cliente nunca ven la clave. El proxy aplica rate limit por plan y registra las duraciones de las llamadas para contabilidad — nunca el contenido del canvas.
Si desactivas las funciones de IA en Configuración → Privacidad, ningún contenido del canvas se envía a Gemini, ni siquiera para fallback de OCR on-device.
Telemetría: opt-in, hasheada, allowlisted
Los analytics de producto vienen apagados por defecto. Cuando se activan, los eventos están limitados a una whitelist en el servidor (inicio/fin de sesión, invocación de función, duración de llamada de IA — nunca contenido). El ID del usuario se hashea con SHA-256 en el dispositivo; el ID en texto claro nunca sale del cliente. Los eventos se retienen 180 días, después se agregan o se borran.
Registro de auditoría (cuentas Institucionales)
Cada acceso a los cuadernos compartidos — quién, desde qué dispositivo, cuándo — se escribe en un registro de auditoría append-only. Los administradores pueden exportar el registro en CSV o JSON para controles de compliance. El registro es write-once: la eliminación exige una motivación documentada y queda, ella misma, registrada.
Recovery y pérdida de la clave
Si pierdes la passphrase, los datos cifrados se vuelven irrecuperables. Es intencional — la alternativa sería un camino de recovery que necesariamente debilitaría el modelo de cifrado. Para cuentas Institucionales, es posible configurar una clave de recovery opcional custodiada por el administrador; es un trade-off documentado que la institución elige conscientemente.
Responsible disclosure
Los investigadores de seguridad son bienvenidos. Reporta vulnerabilidades a security@fluera.dev con cifrado PGP (clave publicada en nuestro perfil de GitHub). Damos respuesta en 24 horas, hacemos patch de los problemas críticos en 72, y acreditamos a quien reporta en el hall of fame, salvo solicitud de anonimato.
Alcance: la app Fluera (todas las plataformas), el servicio de sincronización, el proxy de IA y este sitio de marketing. Fuera de alcance: servicios de terceros (Supabase, Google, Apple, Sentry, RevenueCat) — repórtalo a los vendors correspondientes.
Auditorías externas
Fluera no tiene, por el momento, certificaciones SOC 2 ni ISO 27001. Están en el roadmap enterprise y se anunciarán públicamente cuando se completen. Preferimos no declarar controles que no verificamos de forma independiente.
La lista de subencargados es pública y está actualizada. El Data Processing Agreement está disponible bajo solicitud en privacy@fluera.dev.