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.

El panel Red permite examinar las solicitudes durante una prueba. La evidencia se limita al contexto del navegador, los canales y el intervalo que captures.

Mantén la captura durante el procesamiento y la descarga. Anota la versión, el estado del navegador y el alcance de la captura. Un registro de DevTools por sí solo no garantiza que incluya todos los canales de red posibles.

• 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 solo la tarea que quieres comprobar con un archivo de prueba preparado para ello. Puede haber solicitudes en segundo plano; examina su contenido antes de atribuirlas a la 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 interfazLos scripts, estilos, fuentes y motores son recursos normales de la página. Una ruta conocida, una extensión o una solicitud pequeña no demuestran que no haya datos del usuario. Examina el destino y el contenido enviado.
• La firma de una subidaLos datos del archivo pueden salir hacia el mismo origen o hacia otro. Revisa los cuerpos POST, PUT y multipart y otros canales de datos. El método, destino o tamaño por sí solos no demuestran una subida.
• Á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 workerEl script público inicia cada escenario en un contexto nuevo con Service Workers bloqueados para reducir la interferencia del estado anterior. Anota también qué recursos se precargaron y cuándo empieza el intervalo medido.

Inserta un marcador único en un archivo de prueba y búscalo en las solicitudes capturadas. La ausencia de coincidencias exactas solo significa que no se encontró el marcador. La codificación, compresión, cifrado, transferencia parcial o captura incompleta pueden ocultarlo.

Combina la búsqueda del marcador con la inspección del contenido enviado y documenta el alcance de la captura. Explica qué observó esta ejecución y qué no pudo descartar.

• 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áficoBusca en las URL, parámetros y cuerpos capturados. Una coincidencia indica que el marcador aparece en una solicitud saliente registrada; comprueba también su estado. Esto no demuestra que se haya transferido todo el archivo. La ausencia de coincidencias tampoco demuestra que ningún dato del archivo saliera del dispositivo.
• 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 Centro de confianza 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 Centro de confianza 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.

El repositorio abierto ofrece un script ejecutable contra el sitio público. Sus comprobaciones cubren las solicitudes y los intervalos registrados. Consulta el informe de cada ejecución para conocer el resultado y sus límites.

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.

• 6 escenarios configuradosEl script configura 6 escenarios: conversión y descarga de imágenes, conversión HEIC, OCR, rotación de PDF, transferencia de CSV y una cadena de herramientas personalizada. Configurar no equivale a superar: comprueba el estado, intervalo y revisión de cada escenario en el informe.
• Tres invariantesLas comprobaciones señalan subidas detectadas, coincidencias de marcadores y solicitudes inesperadas entre orígenes. El proxy de analítica propio declarado se cuenta aparte. Aprobar cubre estas comprobaciones en el intervalo medido, no todas las transferencias posibles.
• Comprueba la versiónHay un flujo programado para capturar el sitio en producción. Revisa la última ejecución completada, su resultado y la revisión de la versión. El recibo del sitio es una muestra archivada que ese flujo no actualiza automáticamente. Una captura fallida o incompleta no demuestra por sí sola una filtración de datos.

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.

Cero solicitudes significa que el registro no observó solicitudes en ese intervalo. Excluye el tráfico de preparación documentado aparte y no demuestra el comportamiento fuera de los canales, versión o sesión capturados.

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