Segurança e Arquitetura

1. O que significa "Zero-Server"

Zero-Server descreve uma restrição arquitetural: nenhuma etapa do fluxo de dados do usuário depende de um processo executando em infraestrutura operada pelo CofreUtil. O navegador do visitante é o único runtime. O servidor entrega apenas os artefatos estáticos (HTML, JavaScript, WebAssembly, fontes e o motor de OCR em cache) e não participa do processamento. Com isso, não existe camada intermediária que receba, persista, indexe ou reencaminhe o conteúdo do usuário.

Consequência prática: o vetor de ataque na camada do servidor fica restrito à entrega de estáticos e golpes de cadeia de suprimentos dos recursos carregados (CDNs de bibliotecas), nunca ao vazamento de conteúdo tratado pelo usuário — pois esse conteúdo não existe no servidor em momento algum.

2. Isolamento e ciclo de vida na memória RAM

Todos os buffers de arquivo, decodificações, transcodificações e extrações são mantidos exclusivamente na memória volátil (RAM) do navegador. O ciclo de vida é determinístico:

• Ingestão: o arquivo é lido via FileReader → ArrayBuffer sem transmissão de rede.
• Processamento: módulos WebAssembly operam sobre a memória linear isolada; dados sensíveis não são serializados para o DOM nem para o armazenamento persistente.
• Descarte: ao final, as referências são liberadas e os buffers tornam-se elegíveis para coleta pelo garbage collector. Não há escrita em localStorage / IndexedDB / cookies de conteúdo processado (as únicas persistências possíveis são parâmetros não sensíveis de preferência de interface).

É importante distinguir "isolamento de memória" do conceito de memória protegida de sistemas operacionais: aqui o termo refere-se a manter o dado dentro do processo da aba (sandbox do navegador e das Web Workers), impedindo sua materialização fora dele — em disco, na nuvem ou em logs de servidor. A separação real entre abas e processos é responsabilidade do navegador, implementada conforme seus modelos de isolamento (site isolation e fenced frames).

3. Sandboxes WebAssembly

Motores como FFmpeg, Tesseract e as rotinas binárias de PDF são compilados para WebAssembly e executados dentro de Web Workers. A especificação WebAssembly fornece um modelo de execução com memória linear própria, sem acesso direto ao DOM, ao sistema de arquivos do host ou à rede: qualquer operação dessas depende de funções de import/export explicitamente concedidas pelo embarcador. Essa fronteira reduz a superfície de exploração em relação a um binário nativo executado sem contenção.

Para os cenários pesados de mídia e OCR, empregamos Web Workers dedicados com transferência de buffers por transferable objects — sem duplicação de memória entre thread principal e worker. O build de FFmpeg aqui utilizado é single-threaded (@ffmpeg/core), portanto não depende de cross-origin isolation nem dos headers Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy: a execução limita-se ao sandbox da página e das Web Workers. Essa fronteira reduz a superfície de exploração em comparação a um binário nativo executado sem contenção.

4. Riscos de cadeia de suprimentos (SSC)

A arquitetura Zero-Server elimina a exposição do conteúdo do usuário, mas não é imune a vulnerabilidades de cadeia de suprimentos: a aplicação é entregue a partir de uma CDN (Vercel) e carrega bibliotecas e motores WebAssembly. Reconhecemos esses riscos de forma explícita, em vez de tratá-los como "seguros por design".

• Riscos mapeados: comprometimento do deploy/CDN ou do repositório com código malicioso; dependência de bibliotecas de terceiros (npm, GitHub); motores WebAssembly vindos de CDN; e a necessidade de confiar na integridade do código servido no momento da visita.
• Mitigações aplicadas: builds reproduzíveis e versionadas; dependências com versões fixas; atualizações documentadas no changelog; e o fato de o motor WebAssembly ser baixado uma única vez e ficar disponível para reuso local (o que também viabiliza a auditoria offline do binário com ferramentas de inspeção nativas do navegador).
• Limite da mitigação: nenhuma prática de segurança torna uma aplicação client-side infalível; a auditoria é contínua e as bibliotecas são atualizadas quando há correção publicada de segurança.

5. Ausência de telemetria de conteúdo

Preciso sobre telemetria: o CofreUtil não lê nem armazena o conteúdo processado e não opera cookies de rastreamento nem logs de operações com conteúdo. A única telemetria do site é o Cloudflare Web Analytics, que mede métricas agregadas e anônimas de visita (páginas acessadas, origem aproximada, dispositivo) sem correlação com arquivos, textos ou parâmetros das ferramentas, e sem acessar o conteúdo processado. As visitas do próprio desenvolvedor são auto-excluídas por um mecanismo próprio (?ignore=true); a desativação definitiva do recurso só pode ser feita no painel do Cloudflare.

Diferente do que esta documentação afirmava em versões anteriores, este site não declara "ausência total de telemetria": a métrica de visitas existe, é cookieless e é descrita aqui com transparência. O que não existe — e pode ser confirmado pelas instruções de verificação acima — é a transmissão do conteúdo dos arquivos para servidores.

6. Adequação transparente aos princípios da LGPD

A adequação não é declarada como um selo automático; ela é descrita em termos dos dispositivos da Lei nº 13.709/2018 (LGPD) , com orientação complementar da Autoridade Nacional de Proteção de Dados (ANPD) :

• Art. 6º, III (necessidade / minimização): por não coletarmos dados pessoais para processamento, o tratamento é limitado ao estritamente necessário — na prática, caminha para zero.
• Art. 6º, VI (segurança): a segurança da informação é incorporada desde a concepção de cada ferramenta (arquitetura, não remendo posterior), alinhada aos conceitos de Privacy-by-Design e Privacy-by-Default.
• Art. 46 e §2º (segurança e prevenção desde a concepção): o padrão Zero-Server evita a custódia, a transmissão e o armazenamento do dado — três vetores centrais de incidentes de segurança.
• Art. 48 (comunicação de incidente): a ausência de armazenamento por nossa parte reduz o risco do tipo de incidente mais comum em ferramentas do gênero (comprometimento de banco de dados).

Em fluxos onde o usuário é o único operador dos próprios dados dentro de seu dispositivo, dispensamos a custódia ou processamento de dados por terceiros — o que remove a necessidade de bases legais de tratamento de conteúdo, pois não há tratamento realizado por nós.

7. Auditoria e transparência

Todo o projeto é entregue como site estático: não há API back-end, banco de dados ou fila de jobs a auditar. O registro público de manutenção, correções e evoluções de segurança está no changelog , e o detalhamento da responsabilidade técnica está na página do autor . Dúvidas de engenharia ou pedidos de revisão de segurança podem ser enviados ao e-mail corporativo: contato@grupows.com.