Como verificar se uma ferramenta online não envia seus arquivos

Uma alegação de processamento é testável. Qualquer ferramenta pode dizer que seus arquivos nunca saem do seu dispositivo; a alegação só se torna evidência quando o tráfego de rede durante uma tarefa real é observável e repetível. Este guia ensina um método —observe o que o navegador envia enquanto a ferramenta trabalha— e depois mostra esse mesmo método funcionando como um artefato público permanente, para que alegações sobre a Toolars possam ser conferidas, não apenas acreditadas.

• Promessas vs evidênciaUm rótulo é uma promessa e uma captura é evidência; a diferença é que uma captura pode ser reproduzida, inspecionada e contestada.
• Um método, qualquer ferramentaO método é independente da ferramenta: funciona no painel de rede do próprio navegador, leva cerca de um minuto e serve para qualquer site que você queira testar.
• Testado em nós mesmosEste guia não cita nenhum outro serviço e não afirma nada sobre o comportamento de nenhum outro site; ele ensina a verificação e depois a demonstra na evidência que a Toolars publica sobre si mesma.

Todo navegador desktop inclui um monitor de rede que registra cada requisição de uma página. Usado na ordem certa, ele responde diretamente à pergunta do envio: alguma requisição saiu deste dispositivo carregando meu arquivo?

Conclua o trabalho e baixe o resultado enquanto o painel grava. A unidade de evidência é a sessão completa: um envio só pode acontecer dentro de uma requisição, e uma requisição não pode se esconder de um registro completo.

• Abrir e limpar primeiroAbra primeiro a página da ferramenta e o painel de rede — ferramentas de desenvolvedor, aba Rede —, limpe o registro e mantenha a gravação ligada. Carregar a página sempre produz requisições de HTML, scripts e estilos; esse tráfego da carcaça é esperado.
• Usar um arquivo descartávelExecute a tarefa com um arquivo de teste feito só para isso: converta, gire, comprima. Um registro limpo no início significa que cada requisição visível pertence à sua tarefa.
• Observar a açãoPressione a ação da ferramenta e observe a lista. Uma ferramenta local pode buscar código, fontes ou ativos de motor no primeiro uso — e, após uma execução de aquecimento, idealmente nada.

A habilidade está em separar tráfego da página de tráfego de dados. O tráfego da carcaça entrega a aplicação ao seu navegador; o tráfego de dados leva conteúdo embora. Uma vez que se sabe o que procurar, os dois parecem muito diferentes no painel.

• Requisições da carcaçaRequisições da carcaça são pequenas, passíveis de cache e têm nomes de software — scripts, estilos, fontes e arquivos de motor sob os caminhos do próprio site. Elas trazem o código para o seu dispositivo; não levam seu arquivo a lugar nenhum.
• A assinatura de um envioUm envio parece uma requisição POST, PUT ou multipart cujo corpo tem aproximadamente o tamanho do seu arquivo, enviada a uma origem diferente da da página. Se algo assim dispara ao pressionar converter, o arquivo saiu do dispositivo.
• Abra e olheO tamanho sozinho não prova nada em nenhuma direção: fragmentos comprimidos, sessões retomáveis e WebSockets podem dividir uma transferência. A evidência está no método, no destino e no conteúdo da requisição — abra e olhe.

Um registro de rede mede esta execução neste estado do navegador — e é exatamente esse estado que caches e service workers existem para mudar. Ler bem o registro significa controlar esse estado.

• Aquecimento é normalEm uma visita repetida, um site já aquecido serve sua carcaça do disco ou de um service worker, e o painel mostra muito menos requisições do que na primeira visita. Menos requisições após o aquecimento é a aparência saudável de uma ferramenta local — não é, por si só, prova de nada.
• Começar limpoPara uma leitura limpa, comece de um perfil de navegador novo ou de uma janela privativa, ative a opção de desativar cache do painel e lembre-se de que o modo privativo não bloqueia service workers em todo navegador.
• Bloquear o workerAs capturas mais fortes começam cada execução em um contexto de navegador novo com service workers bloqueados, para que nada seja servido de cache nem interceptado antes de o painel registrar. O harness público abaixo grava exatamente assim.

O salto decisivo além de observar tráfego: dê ao seu arquivo de teste um marcador único — uma canary string — e procure essa string exata nas requisições capturadas. Se os bytes não aparecem em nenhuma requisição, o arquivo não viajou.

É a técnica mais convincente disponível para quem não é especialista, porque testa os bytes em si, e não as intenções da ferramenta.

• Marque o arquivoCrie um arquivo descartável e incorpore um marcador que você mesmo gerou e nunca publicou: um UUID aleatório em uma camada de texto, um comentário de imagem, uma nota de PDF. A unicidade é o que dá significado a uma correspondência.
• Procure no tráfegoApós a tarefa, procure o marcador nas requisições capturadas no painel — URLs, query strings e corpos. Uma correspondência significa que os bytes do seu arquivo saíram do dispositivo; a ausência em toda a sessão é evidência direta e forte de que não saíram.
• RepitaUm canário cobre apenas a sessão observada — é por isso que capturas recorrentes e agendadas importam mais do que uma única verificação manual minuciosa.

A Toolars executa o mesmo método como um artefato público permanente: uma declaração de processamento tipada para cada ferramenta, uma página Privacy proof com tráfego capturado e um recibo legível por máquina que declara seus limites tão claramente quanto seus resultados.

• Hosts declaradosA página Privacy proof lista cada host externo que a carcaça do site pode alcançar, os cabeçalhos de segurança servidos com as respostas e as etapas de autoverificação que você pode executar manualmente no mesmo painel de rede.
• Recibo legível por máquinaUm recibo de verificação legível por máquina em /privacy-proof/verification-receipt.json publica os comandos de verificação, os resultados medidos dos cenários, os hosts externos declarados e a revisão de lançamento para comparar com o cabeçalho de resposta X-Toolars-Release do site.
• Limites honestosO recibo diz o que não prova tão claramente quanto o que prova: a janela medida cobre aquela execução, não uma auditoria de tudo que o serviço poderia um dia fazer.

As mesmas verificações vêm empacotadas como um harness executável no repositório aberto, de modo que a alegação de processamento local pode ser verificada sem pedir nada à Toolars. Ele controla o site publicado, registra cada requisição incluindo as de workers e falha em voz alta quando uma fronteira é cruzada.

O harness vive no repositório público https://github.com/aixtral/toolars-open, sob evidence-harness/. Ele é publicado sob a licença MIT e verifica o site implantado — a coisa sobre a qual a alegação realmente trata — e não uma cópia privada de preparação.

• Quatro cenáriosO harness controla o site publicado em Chromium headless por meio de quatro cenários: uma conversão de imagem com download; uma conversão HEIC cuja execução medida deve emitir zero requisições após o aquecimento do decodificador; uma tarefa de OCR com um segundo pacote de idioma que deve chegar da própria origem do site; e uma rotação de PDF na amostra incluída.
• Três invariantesEm cada janela medida ele exige três invariantes: zero requisições de envio, zero vazamentos de canário — os bytes do arquivo de entrada carregam um marcador aleatório — e zero requisições cross-origin inesperadas além do proxy de análise de primeira parte declarado pelo site, que é contado e nomeado em vez de ignorado.
• Recaptura diáriaUm fluxo agendado recaptura o recibo contra o site publicado todos os dias, e o selo privacy-proof do repositório só fica verde quando o resultado do recibo mais recente é verified; uma execução com falha se lê violation ou inconclusive, nunca verde silencioso.

Um recibo vale tanto quanto sua reprodutibilidade. O harness é construído para ser executado por qualquer pessoa, contra a origem publicada, com resultados gravados em um arquivo que pode ser inspecionado linha a linha.

Como cada cenário começa em um contexto de navegador novo com service workers bloqueados, uma leitura de zero requisições significa o que parece significar: após o aquecimento, a execução medida não tocou a rede de forma alguma.

• Clonar e verificarClone o repositório, entre em evidence-harness/, instale suas dependências e um Chromium do Playwright e execute o script de verificação com o site publicado como origem de destino.
• Os códigos de saída são o veredictoA execução grava privacy-proof-receipt.json e termina com código diferente de zero se algo inesperado cruzar a fronteira — uma requisição com corpo, um canário em uma URL ou um host que não está na lista publicada do site.
• Apenas metadadosO recibo registra apenas metadados de requisição — método, host, caminho, tipo de recurso, se havia corpo —, nunca conteúdo de arquivos, corpos de requisição ou corpos de resposta.

A verificação honesta inclui seus próprios limites. Conhecê-los evita ler um rastro de rede limpo como uma garantia que ele nunca foi.

• Uma janelaUm rastro limpo cobre a sessão observada — aquela execução, aquele navegador, aquele arquivo. Ele não audita os servidores de um provedor, seu pessoal ou seu código futuro.
• Seu dispositivo importaO que sai do seu dispositivo também depende do seu dispositivo: um navegador comprometido, uma extensão maliciosa ou um perfil compartilhado pode mover dados independentemente da arquitetura de qualquer ferramenta.
• Evidência permanenteTrate cada alegação de privacidade — incluindo a deste site — como evidência permanente a ser recapturada, e não como garantia vitalícia. É exatamente por isso que o harness é reexecutado em agenda, em vez de descansar em uma boa captura.