El Informe de Infraestructura Nexun: Como Siete Comprobaciones Automatizadas Y Un JSON Firmado Demuestran Nuestra Politica Sin Registros Cada Semana

La mayoria de "informes de transparencia" de los VPN son PDFs anuales escritos por el mismo departamento de marketing que hizo la pagina de ventas. El nuestro es diferente. Cada semana, una tarea programada en nuestra infraestructura de produccion ejecuta siete comprobaciones automatizadas contra el sistema real, escribe el resultado como payload JSON firmado en una fila de base de datos y lo publica en nexun.io/transparency/infrastructure. El resultado es una atestacion criptograficamente verificable de como esta realmente el backend de Nexun ahora mismo — y puedes comparar dos semanas cualesquiera para ver que nada ha cambiado por debajo.

Lo que muestra la tarjeta del informe de un vistazo

Arriba de /transparency/infrastructure esta la tarjeta del informe. Contiene cuatro cosas: un Report ID como 2026-W16-093318 (ano ISO, semana ISO, timestamp), una fecha de generacion al segundo, una pildora de estado global ("Todas las comprobaciones superadas" o "Revision necesaria"), y un hash de contenido SHA-256 de 64 caracteres. Ese hash se calcula sobre el payload JSON canonico del informe. Cambia un solo byte del payload y el hash se vuelve una cadena completamente distinta. Asi sabes que la pagina que lees no ha sido alterada.

Las siete comprobaciones, explicadas

Bajo la cabecera hay un bloque de resumen con siete filas, cada una marcada como pass o fail. Cada fila la genera una sonda automatizada distinta que corre contra la maquina real — no un archivo de configuracion estatico. Esto es lo que prueba cada una:

• Sin archivos de log en disco — la sonda escanea /var/log/wireguard, /var/log/nexun y /var/log/openvpn. Si alguna de esas carpetas existe o contiene archivos, la comprobacion falla. Un resultado correcto significa que no hay ningun sitio en disco donde los logs de conexion puedan aterrizar.
• Superficie API enumerada — FastAPI introspecciona su propia tabla de rutas y lista cada prefijo montado con sus metodos HTTP (/admin 33 endpoints, /beta 62, /transparency 5). No se trata de los numeros — se trata de que la forma completa de la API es publica. Ninguna ruta oculta.
• Inventario de datos documentado — la sonda lee el esquema PostgreSQL en vivo para vpn_users, vpn_subscriptions, vpn_support_tickets y billing_events y clasifica cada columna (identifier, contact, payment, operational, timestamp, credential, unknown). Si se anade una nueva columna en produccion y no esta documentada en el inventario, la comprobacion falla.
• Las tablas de usuario no tienen columnas IP — la sonda busca en cada tabla de usuario columnas llamadas client_ip, ip_address, ip, remote_ip, created_ip, last_ip o source_ip. Una sola coincidencia haria fallar la comprobacion. El resultado correcto significa que la base de datos literalmente no tiene columna donde pueda guardarse una IP.
• Query logging de base de datos desactivado — los ajustes de PostgreSQL se leen en vivo: log_duration=off, log_statement=none, log_connections=off, log_disconnections=off, log_min_duration_statement=-1. Si alguien encendiera alguno de esos flags "para depurar algo", el informe lo capturaria en 7 dias.
• Sin SDKs analiticos en dependencias — la sonda analiza los paquetes Python instalados exactos (22 paquetes) y los compara con una deny-list: sentry-sdk, datadog, newrelic, mixpanel, segment-analytics-python, posthog, rollbar, bugsnag, google-analytics, amplitude, heap, fullstory. Un resultado correcto significa que ninguna de las bibliotecas de fuga silenciosa habituales esta en el entorno.
• Sin extensiones de auditoria o log instaladas — la sonda consulta pg_extension contra una deny-list: pgaudit, pg_stat_statements, pg_qualstats, auto_explain. Son extensiones de Postgres que registran historia de consultas silenciosamente. Solo pgcrypto y plpgsql estan instaladas — ambas necesarias, ninguna registra nada.

Las aclaraciones de esquema — por que mostramos las columnas "preocupantes"

El informe tambien incluye una breve seccion de aclaraciones. Algunos de nuestros nombres de columna parecen alarmantes junto a una promesa "sin registros", y en vez de ocultarlos en un backoffice los explicamos todos en la misma pagina. Ocultarlos destruiria el proposito de la pagina.

• vpn_support_tickets.log_data — un paquete de depuracion que un usuario puede adjuntar voluntariamente a un ticket de soporte. Condicionado por el booleano include_logs en la misma fila. Nunca se escribe para trafico VPN normal; solo se rellena cuando alguien marca "incluir logs" en el formulario de soporte.
• vpn_users.test_password — una contrasena en texto plano para las cuentas de revisores de App Store y Google Play. Apple y Google exigen un login de prueba funcional para aprobar actualizaciones. Una restriccion CHECK de la base (chk_test_password_only_for_test) hace fisicamente imposible escribir esta columna en cualquier fila donde is_test_account sea false.
• vpn_users.notes — un campo libre para notas del operador (contexto de reembolso, seguimiento de soporte). Nunca visible para otros usuarios; solo legible por admins nivel 9. Toda solicitud de acceso RGPD incluye este campo en el export.
• vpn_subscriptions.raw — el payload webhook exacto que recibimos de Stripe / Apple / Google para cada evento de suscripcion, guardado al pie de la letra para reconciliar disputas de facturacion. No contiene informacion mas alla de lo que el proveedor de pago ya tiene sobre la misma transaccion.

El payload JSON completo y como verificarlo tu mismo

Al final de la pagina del informe renderizamos el documento JSON exacto sobre el que se calculo el SHA-256. Cualquiera puede recorrerlo: las comprobaciones, los arrays de findings, cada tabla y columna del inventario de datos, los ajustes de Postgres, las extensiones instaladas, la lista de dependencias y el resumen. El formato es estable (schema_version: 2) para que dos informes de semanas distintas puedan compararse directamente. Para verificar el hash canonizas el JSON (claves ordenadas, sin whitespace extra) y calculas un SHA-256 sobre los bytes. Si tu resultado coincide con el hash en la cabecera, el informe esta intacto. Si no coincide, algo va mal y queremos saberlo.

Lo que cambia entre semanas

Como el informe se genera automaticamente desde el sistema vivo, cambiara cuando el sistema cambie de verdad. Una semana normal puede ver total_packages moverse un poco cuando actualizamos dependencias, o endpoint_count bajo /beta cambiar cuando anadimos o retiramos funciones beta. Lo que nunca deberia cambiar es el conjunto de categorias ("sin columnas IP", "sin query logging", "sin SDKs analiticos", "sin extensiones de auditoria") — cualquier cambio ahi dejaria overall_pass en false y mostraria una pildora roja "Revision necesaria" en vez de verde. Si eso llegara a pasar, te deberemos una explicacion, y el informe esta disenado para hacer la explicacion inevitable.

Por que esto es mas honesto que un PDF anual

Un PDF anual es una instantanea escrita por humanos. Puede reeditarse, reformularse y resubirse silenciosamente. Una atestacion firmada semanal generada por la maquina no. La fila de base de datos de cada informe se indexa por semana ISO; el hash queda fijo en el momento de creacion; y cada linea del payload es una lectura directa de la infraestructura. Si alguna vez tuvieramos que suavizar silenciosamente una afirmacion, las comprobaciones fallarian y la pagina lo mostraria. Esa es la diferencia real entre prometer privacidad y demostrarla.

Como usar el informe como usuario

Abre nexun.io/transparency para ver la semana actual de un vistazo: color del canary, pildora de estado de infraestructura, huella SHA-256. Haz clic hacia /transparency/infrastructure para leer cada comprobacion. Guarda la pagina y vuelve a abrirla una semana despues — el Report ID (2026-Wxx-...) y el hash deben haber cambiado, demostrando que la atestacion es en vivo. Si algo cambia en la seccion "never-log" o la lista de comprobaciones sin anuncio publico por nuestra parte, tratalo como razon para preguntar. Para eso existe este informe.