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 protegidos em trânsito e em repouso. A sincronização na nuvem é criptografada em trânsito (TLS) e em repouso na infraestrutura da UE (Supabase, eu-north-1). Ela não é ponta a ponta: o Fluera, como controlador de dados, pode tecnicamente acessar o conteúdo sincronizado — mas nunca o vende nem o usa para publicidade.
- 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
Todo o tráfego de rede é TLS 1.3 com cifras modernas, protegendo os dados contra interceptação na rede.
Sincronização entre dispositivos: na nuvem da UE
O cloud sync, quando ativado, armazena os seus cadernos no servidor de sincronização (Supabase, região UE, eu-north-1). Os dados são criptografados em trânsito (TLS) e em repouso na infraestrutura. A sincronização não é ponta a ponta: o Fluera, como controlador de dados, pode tecnicamente acessar o conteúdo sincronizado — nunca o vende nem o usa para publicidade. A sincronização é opt-in por caderno — você pode manter alguns só locais enquanto sincroniza outros.
Para garantias mais fortes, o conteúdo que nunca sai do dispositivo permanece criptografado localmente com SQLCipher, e a exportação para arquivos .fluera é criptografada com AES-256-GCM — esses sim ilegíveis para nós.
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, processadas na UE
As chamadas de IA (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) usam modelos Google Gemini servidos pelo Google Vertex AI, processados na UE (europe-west4 NL / europe-west1 BE). Passam por um proxy que guarda a credencial no servidor — os dispositivos cliente nunca a veem. 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 serviço de IA, 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 lorenco@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 lorenco@fluera.dev.