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.

O painel Rede permite inspecionar solicitações durante um teste. A evidência se limita ao contexto do navegador, aos canais e ao intervalo que foram capturados.

Continue gravando durante o processamento e o download. Anote versão, estado do navegador e escopo da captura. Um registro do DevTools sozinho não garante a captura de todos os canais de rede possíveis.

• 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 apenas a tarefa que deseja verificar, usando um arquivo de teste preparado para isso. Ainda pode haver solicitações em segundo plano; examine o conteúdo antes de atribuí-las à 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çaScripts, estilos, fontes e mecanismos são recursos normais da página. Um caminho conhecido, uma extensão ou uma solicitação pequena não provam a ausência de dados do usuário. Examine o destino e o conteúdo enviado.
• A assinatura de um envioDados do arquivo podem sair para a mesma origem ou para outra. Inspecione corpos POST, PUT e multipart e outros canais de dados. Método, destino ou tamanho sozinhos não provam um upload.
• 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 workerO script público inicia cada cenário em um contexto novo com Service Workers bloqueados, reduzindo a interferência do estado anterior. Registre também quais recursos foram pré-carregados e quando começa o intervalo medido.

Insira um marcador exclusivo em um arquivo de teste e procure-o nas solicitações capturadas. Nenhuma correspondência exata significa apenas que o marcador não foi encontrado. Codificação, compressão, criptografia, transferência parcial ou captura incompleta podem ocultá-lo.

Combine a busca do marcador com a inspeção do conteúdo enviado e documente o escopo da captura. Explique o que esta execução observou e o que não conseguiu descartar.

• 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áfegoPesquise nas URLs, parâmetros e corpos capturados. Uma correspondência indica que o marcador aparece em uma solicitação de saída registrada; confira também seu estado. Isso não prova que o arquivo inteiro foi transferido. A ausência de correspondência também não prova que nenhum dado do arquivo saiu do dispositivo.
• 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 Central de confiança 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 Central de confiança 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.

O repositório aberto oferece um script executável no site público. As verificações cobrem as solicitações e os intervalos registrados. Consulte o relatório de cada execução para conhecer os resultados e limites.

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.

• 6 cenários configuradosO script configura 6 cenários: conversão de imagem com download, conversão HEIC, OCR, rotação de PDF, transferência de CSV e cadeia personalizada de ferramentas. Configurado não significa aprovado: confira cada status, intervalo medido e revisão no relatório.
• Três invariantesAs verificações apontam uploads detectados, correspondências de marcadores e solicitações inesperadas entre origens. O proxy próprio de análise declarado é contado separadamente. Aprovar cobre essas verificações no intervalo medido, não todas as transferências possíveis.
• Confira a versãoUm fluxo agendado está configurado para capturar o site em produção. Confira a última execução concluída, seu resultado e a revisão da versão. O recibo no site é uma amostra arquivada e não é atualizado automaticamente por esse fluxo. Uma captura que falhou ou ficou incompleta não comprova, por si só, um vazamento de dados.

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.

Zero solicitações significa que o registro não observou solicitações naquele intervalo. O tráfego de preparação documentado à parte fica excluído; isso não comprova o comportamento fora dos canais, versão ou sessão capturados.

• 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.