Cómo verificar que una herramienta online no sube tus archivos

Una afirmación de procesamiento es comprobable. Cualquier herramienta puede decir que tus archivos jamás salen de tu dispositivo; la afirmación solo se convierte en evidencia cuando el tráfico de red durante una tarea real es observable y repetible. Esta guía enseña un método —observa lo que el navegador envía mientras la herramienta trabaja— y luego muestra ese mismo método funcionando como un artefacto público permanente, para que las afirmaciones sobre Toolars se puedan comprobar en vez de creerse.

• Promesas vs evidenciaUna etiqueta es una promesa y una captura es evidencia; la diferencia es que una captura se puede reproducir, inspeccionar y contestar.
• Un método, cualquier herramientaEl método es independiente de la herramienta: funciona en el panel de red del propio navegador, toma un minuto y sirve para cualquier sitio que quieras probar.
• Probada en nosotros mismosEsta guía no nombra ningún otro servicio ni afirma nada sobre cómo se comporta ningún otro sitio; enseña la comprobación y la demuestra con la evidencia que Toolars publica sobre sí misma.

Cada navegador de escritorio incluye un monitor de red que registra cada petición que hace una página. Usado en el orden correcto, responde directamente a la pregunta de la subida: ¿salió alguna petición de este dispositivo llevándose mi archivo?

Termina el trabajo y descarga el resultado mientras el panel graba. La unidad de evidencia es la sesión completa: una subida solo puede ocurrir dentro de una petición, y una petición no puede esconderse de un registro completo.

• Abrir y borrar primeroAbre primero la página de la herramienta y el panel de red —herramientas de desarrollador, pestaña Red—, borra el registro y déjalo grabando. Cargar la página siempre genera peticiones de HTML, scripts y estilos; ese tráfico de la interfaz es esperado.
• Usar un archivo sacrificableEjecuta la tarea con un archivo de prueba que hayas creado solo para esto: conviértelo, gíralo, comprímelo. Un registro limpio al inicio significa que cada petición que ves pertenece a tu tarea.
• Observar la acciónPulsa la acción de la herramienta y observa la lista. Una herramienta local puede pedir código, fuentes o motores en el primer uso — y, tras una ejecución de calentamiento, idealmente nada.

La habilidad está en distinguir el tráfico de la página del tráfico de datos. El tráfico de la interfaz entrega la aplicación a tu navegador; el tráfico de datos se lleva contenido. Una vez sabes qué buscar, se ven muy distintos en el panel.

• Peticiones de la interfazLas peticiones de la interfaz son pequeñas, cacheables y llevan nombres de software —scripts, estilos, fuentes y motores bajo rutas propias del sitio—. Traen el código a tu dispositivo; no llevan tu archivo a ninguna parte.
• La firma de una subidaUna subida parece una petición POST, PUT o multiparte cuyo cuerpo tiene aproximadamente el tamaño de tu archivo, enviada a un origen distinto del de la página. Si algo así aparece al pulsar convertir, el archivo salió del dispositivo.
• Ábrela y miraEl tamaño por sí solo no prueba nada en ningún sentido: los fragmentos comprimidos, las sesiones reanudables y los WebSockets pueden dividir una transferencia. La evidencia está en el método, el destino y el contenido de la petición: ábrela y mira.

Un registro de red mide esta ejecución en este estado del navegador — y ese estado es exactamente lo que las cachés y los service workers existen para cambiar. Leer bien el registro significa controlar ese estado.

• El calentamiento es normalEn una visita repetida, un sitio ya caliente sirve su interfaz desde el disco o un service worker, y el panel muestra muchas menos peticiones que la primera vez. Menos peticiones tras el calentamiento es el aspecto sano de una herramienta local; por sí solo no prueba nada.
• Empezar limpioPara una lectura limpia, empieza desde un perfil de navegador nuevo o una ventana privada, activa la opción de desactivar la caché del panel y recuerda que la ventana privada no bloquea los service workers en todos los navegadores.
• Bloquear el workerLas capturas más sólidas comienzan cada ejecución en un contexto de navegador nuevo con los service workers bloqueados, para que nada se sirva desde caché ni se intercepte antes de que el panel lo registre. El harness público que verás abajo graba exactamente así.

El salto decisivo respecto a mirar tráfico: da a tu archivo de prueba una marca única —un canary string— y busca esa cadena exacta en las peticiones capturadas. Si los bytes no aparecen en ninguna petición, el archivo no viajó.

Es la técnica más convincente disponible para quien no es especialista, porque pone a prueba los bytes mismos y no las intenciones de la herramienta.

• Marca el archivoCrea un archivo sacrificable y empotra una marca que hayas generado tú y nunca hayas publicado: un UUID aleatorio en una capa de texto, un comentario de imagen, una nota de PDF. La unicidad es lo que da significado a una coincidencia.
• Busca en el tráficoTras la tarea, busca la marca en las peticiones capturadas del panel —URLs, cadenas de consulta y cuerpos—. Una coincidencia significa que los bytes de tu archivo salieron del dispositivo; la ausencia en toda la sesión es evidencia directa y sólida de que no salieron.
• RepiteUn canario solo cubre la sesión observada, y por eso las capturas periódicas y repetidas importan más que una sola comprobación manual minuciosa.

Toolars ejecuta el mismo método como artefacto público permanente: una declaración de procesamiento con tipos para cada herramienta, una página de prueba de privacidad con tráfico capturado y un recibo legible por máquina que expresa sus límites tan claramente como sus resultados.

• Hosts declaradosLa página de prueba de privacidad lista cada host externo que puede alcanzar la interfaz del sitio, los encabezados de seguridad servidos con las respuestas y los pasos de autoverificación que puedes ejecutar a mano en el mismo panel de red.
• Recibo legible por máquinaUn recibo de verificación legible por máquina en /privacy-proof/verification-receipt.json publica los comandos de verificación, los resultados medidos de cada escenario, los hosts externos declarados y la revisión de publicación a cotejar con el encabezado de respuesta X-Toolars-Release del sitio.
• Límites honestosEl recibo declara con la misma claridad lo que no prueba: la ventana medida cubre esa ejecución, no una auditoría de todo lo que el servicio podría hacer jamás.

Las mismas comprobaciones vienen empaquetadas como un harness ejecutable en el repositorio abierto, de modo que la afirmación de procesamiento local se puede verificar sin pedirle nada a Toolars. Conduce el sitio en vivo, registra cada petición incluidas las de los workers y falla con estruendo cuando se cruza una frontera.

El harness vive en el repositorio público https://github.com/aixtral/toolars-open, bajo evidence-harness/. Se publica bajo la licencia MIT y verifica el sitio desplegado —lo que la afirmación realmente trata—, no una copia privada de ensayo.

• Cuatro escenariosEl harness conduce el sitio en vivo en Chromium sin cabecera a través de cuatro escenarios: una conversión de imagen con descarga; una conversión HEIC cuya ejecución medida debe emitir cero peticiones tras el calentamiento del descodificador; una tarea OCR con un segundo paquete de idioma que debe llegar desde el propio origen del sitio; y una rotación de PDF con el ejemplo incluido.
• Tres invariantesEn cada ventana medida exige tres invariantes: cero peticiones de subida, cero fugas de canario —los bytes del archivo de entrada llevan una marca aleatoria— y cero peticiones cross-origin inesperadas más allá del proxy de analítica de primera parte declarado por el sitio, que se cuenta y se nombra en vez de ignorarse.
• Recaptura diariaUn flujo de trabajo programado recaptura el recibo contra el sitio en vivo cada día, y la insignia de prueba de privacidad del repositorio solo es verde cuando el resultado del recibo más reciente es verified; una ejecución fallida se lee violation o inconclusive, nunca verde en silencio.

Un recibo vale lo mismo que su reproducibilidad. El harness está construido para que cualquiera lo ejecute contra el origen en vivo y obtenga resultados en un archivo que puede inspeccionarse línea a línea.

Como cada escenario empieza en un contexto de navegador nuevo con los service workers bloqueados, una lectura de cero peticiones significa lo que parece: tras el calentamiento, la ejecución medida no tocó la red en absoluto.

• Clona y verificaClona el repositorio, entra en evidence-harness/, instala sus dependencias y un Chromium de Playwright, y ejecuta el script de verificación con el sitio en vivo como origen de destino.
• Los códigos de salida son el veredictoLa ejecución escribe privacy-proof-receipt.json y termina con código distinto de cero si algo inesperado cruza la frontera —una petición con cuerpo, un canary en una URL o un host que no está en la lista publicada del sitio—.
• Solo metadatosEl recibo registra solo metadatos de las peticiones —método, host, ruta, tipo de recurso y si había cuerpo—, jamás contenidos de archivos, cuerpos de peticiones ni cuerpos de respuestas.

La verificación honesta incluye sus propios límites. Conocerlos evita sobreinterpretar una traza de red limpia como si fuera una garantía que nunca fue.

• Una ventanaUna traza limpia cubre la sesión observada —esa ejecución, ese navegador, ese archivo—. No audita los servidores del proveedor, su personal ni su código futuro.
• Tu dispositivo importaLo que sale de tu dispositivo también depende de tu dispositivo: un navegador comprometido, una extensión maliciosa o un perfil compartido pueden mover datos con independencia de la arquitectura de cualquier herramienta.
• Evidencia permanenteTrata cada afirmación de privacidad —incluida la de este sitio— como evidencia permanente que se recaptura, no como una garantía de por vida. Exactamente por eso el harness se reejecuta según un calendario en vez de descansar en una buena captura.