Pitch: Privacidade por padrão: Como manipulei PDFs e fiz OCR sem enviar um único byte para o servidor

Com certeza, você tem toda razão em pontuar isso. Eu tenho total ciência dessa limitação e esse é, inclusive, um dos meus maiores focos no momento.

Eu estou trabalhando na versão mobile, que está sendo desenhada para ser ainda mais leve e acessível, permitindo que quem não tem um PC potente consiga realizar as tarefas direto pelo celular com agilidade.

O objetivo é que a tecnologia seja uma facilitadora, e não uma barreira por causa do equipamento.

Sobre "resolve só parte do problema":

O processamento client-side resolve exatamente a parte que 99% das alternativas do mercado não resolvem: custódia de dados pelo operador. Quando um PDF é enviado para iLovePDF, SmallPDF, Adobe Online etc., o arquivo passa por servidores de terceiros com logs, backups, funcionários com acesso, obrigações legais de retenção (Marco Civil, LGPD, subpoena internacional) e uma superfície de ataque considerável. Eliminar essa custódia não é parte pequena do problema — é o vetor principal de vazamento de documentos em serviços SaaS. 100% dos vazamentos de OCR/PDF dos últimos anos (MyHeritage, Dropbox, etc.) foram server-side.

Sobre performance do Tesseract WASM:

Correto. WASM é ~3-5x mais lento que um worker nativo no servidor. Trade-off consciente e explícito. Para documentos de 1-20 páginas a diferença em segundos é aceitável. Para OCR em 500+ páginas, a recomendação apropriada é solução desktop (Tesseract CLI, OCRmyPDF local). A ferramenta não se propõe a ser a mais rápida — se propõe a não transferir custódia.

Sobre Spectre/Meltdown em buffers do browser:
Argumento desatualizado. Desde 2018, navegadores implementam:

• Site Isolation (Chrome) — cada origem em processo separado, impedindo leakage cross-origin
• COOP/COEP — necessários para habilitar SharedArrayBuffer, que é o vetor crítico
• Timer precision reduction — performance.now() degradado para 100µs, inviabilizando timing attacks práticos
• Cross-Origin-Resource-Policy — isolamento de recursos

Para um PWA estático, sem scripts de terceiros, sem ads, sem trackers, com CSP restritivo, o vetor Spectre é teoricamente interessante mas praticamente inexplorado há 6+ anos. Em comparação, um servidor processando o mesmo arquivo tem CVEs ativos anuais em libpng, libjpeg, pdfium, poppler, tesseract-server e todo o stack de rede.

Sobre limpeza segura de buffer:
JS não tem memset_s explícito, mas:

• Buffers são garbage-collected ao sair de escopo
• Canvas é invalidado com canvas.width = 0 (libera backing store)
• ArrayBuffers são rehidratados pelo alocador do V8, que zera páginas antes de remapear
• Não há persistência: tudo vive apenas enquanto a aba está aberta (sem localStorage, sem IndexedDB para arquivos, sem cookies de estado)

Um servidor que processa o mesmo PDF possui logs, swap, core dumps, backups de disco, snapshots de VM e métricas com samples de payload — nenhum desses vetores existe no client-side. Zeroização explícita é feature de sistemas críticos (HSM, kernels militares), não baseline de SaaS de OCR.

Sobre transferir custo computacional para o hardware do usuário:

Esse é o modelo padrão de software local desde 1985 (Word, Photoshop, VLC, IDEs, compiladores). A alternativa é devolver o custo ao servidor — e junto com ele, o controle, a visibilidade e a confiança. No modelo client-side, o browser é uma sandbox conhecida e auditável, o código é estático e inspecionável (Ctrl+U), e não há estado persistente server-side.

Nenhuma ferramenta é perfeita, mas "processa no device e some quando a aba fecha" é um modelo de ameaça substancialmente mais simples de auditar do que "confie que o backend não guarda nada". O código-fonte está na página — verificação é trivial.