Threat model
Assumimos roubo do dispositivo, interceptação de rede e exposição acidental via backup ou cloud sync. Assumimos que as credenciais do usuário podem ser comprometidas. Não assumimos adversários de nível estatal com acesso físico a dispositivos desbloqueados — Fluera não é uma ferramenta de sigilo, é uma ferramenta de estudo.
Dentro desse modelo, três garantias:
- Os dados locais são ilegíveis sem a chave. Um dispositivo roubado produz um blob criptografado.
- Os dados sincronizados são ilegíveis para nós. A nuvem guarda apenas ciphertext. A derivação acontece no dispositivo.
- A telemetria é consensual e desidentificada. Os analytics não conseguem ligar um usuário ao seu conteúdo nem mesmo em caso de breach completo.
Em repouso: SQLCipher, AES-256
Cada caderno do Fluera vive em um banco SQLite local criptografado com SQLCipher — uma extensão amplamente auditada que criptografa de forma transparente cada página do banco com AES-256-CBC e checagem de integridade HMAC-SHA512 por página.
A derivação da chave usa PBKDF2 com SHA-256, 256.000 iterações (alinhado ao OWASP). A passphrase é guardada no keychain da plataforma — Keychain no iOS/macOS, Keystore no Android, DPAPI no Windows, libsecret no Linux. Nunca é enviada aos nossos servidores.
Em trânsito: TLS 1.3, certificate pinning
Todo o tráfego de rede é TLS 1.3 com cifras modernas. No iOS e Android fazemos pinning dos certificados na nossa cadeia de CA para evitar man-in-the-middle de proxies corporativos — com override documentado para administradores de rede que precisem.
Sincronização entre dispositivos: ponta a ponta
O cloud sync, quando ativado, usa um conjunto de chaves separado derivado no dispositivo. O servidor de sincronização (Supabase Storage, região UE) guarda ciphertext e não consegue descriptografar. A sincronização é opt-in por caderno — você pode manter alguns só locais enquanto sincroniza outros.
Rotação de chaves: iniciá-la a partir de qualquer dispositivo recriptografa todos os payloads futuros com uma chave nova. Os ciphertexts antigos continuam legíveis para clientes mais antigos até você confirmar a migração em todos os dispositivos.
Colaboração P2P: direta, criptografada
A colaboração em tempo real usa WebRTC DataChannel com criptografia DTLS-SRTP. O Supabase Realtime atua apenas como broker de signaling — setup da conexão — não como relay do tráfego real do canvas. Depois do handshake, as edições do canvas fluem peer-to-peer. O servidor não as vê.
Em NATs restritivos passamos via TURN, caso em que o relay vê apenas pacotes DTLS criptografados que ele não consegue descriptografar.
Chamadas de IA: via proxy, nunca diretas
As chamadas ao Google Gemini (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) passam por uma Supabase Edge Function que guarda a API key no servidor. Os dispositivos cliente nunca veem a chave. O proxy aplica rate limit por plano e loga as durações das chamadas para contabilidade — nunca o conteúdo do canvas.
Se você desativa as funções de IA em Configurações → Privacidade, nenhum conteúdo do canvas é enviado ao Gemini, nem mesmo para fallback de OCR on-device.
Telemetria: opt-in, hasheada, allowlisted
Os analytics de produto vêm desligados por padrão. Quando ativados, os eventos são limitados a uma whitelist no servidor (início/fim de sessão, invocação de recurso, duração de chamada de IA — nunca conteúdo). O ID do usuário é hasheado em SHA-256 no dispositivo; o ID em texto claro nunca sai do cliente. Os eventos ficam retidos por 180 dias, depois agregados ou apagados.
Trilha de auditoria (contas Institucionais)
Cada acesso aos cadernos compartilhados — quem, de qual dispositivo, quando — é escrito em uma trilha de auditoria append-only. Os administradores podem exportar a trilha em CSV ou JSON para controles de compliance. A trilha é write-once: a remoção exige uma motivação documentada e é, ela mesma, logada.
Recovery e perda da chave
Se você perde a passphrase, os dados criptografados se tornam irrecuperáveis. É intencional — a alternativa seria um caminho de recovery que necessariamente enfraqueceria o modelo de criptografia. Para contas Institucionais, é possível configurar uma chave de recovery opcional guardada pelo administrador; é um trade-off documentado em que a instituição escolhe conscientemente.
Responsible disclosure
Pesquisadores de segurança são bem-vindos. Reporte vulnerabilidades para security@fluera.dev com criptografia PGP (chave publicada no perfil do GitHub). Damos retorno em 24 horas, fazemos patch dos problemas críticos em 72, e creditamos quem reporta no hall of fame, salvo solicitação de anonimato.
Escopo: o app Fluera (todas as plataformas), o serviço de sincronização, o proxy de IA e este site de marketing. Fora de escopo: serviços de terceiros (Supabase, Google, Apple, Sentry, RevenueCat) — reporte aos vendors correspondentes.
Avaliações externas
Fluera não tem, no momento, certificações SOC 2 nem ISO 27001. Estão no roadmap enterprise e serão anunciadas publicamente quando concluídas. Preferimos não declarar controles que não verificamos de forma independente.
A lista de suboperadores é pública e está atualizada. O Data Processing Agreement está disponível sob solicitação em privacy@fluera.dev.