Perito Tacho: el software pericial donde los datos del expediente no salen del equipo

Lo construimos con cero peticiones de red, porque por él pasan el DNI de un conductor y material probatorio bajo cadena de custodia. Lo que aprendimos sirve para cualquier web que maneje datos de otras personas.

Hay un tipo de requisito que no aparece casi nunca en un encargo de software: que el programa no se conecte a internet. Ni una vez. Ni para comprobar si hay actualizaciones.

Nos lo impusimos a nosotros mismos en Perito Tacho, la herramienta con la que Pedro Mulero trabaja sus expedientes periciales. Es de uso interno: no está a la venta ni lo estará. Y resultó que casi todo lo que obligó a pensar sirve para una web comercial corriente. Esta entrada va de eso: de lo que se aprende cuando no te puedes permitir que un dato salga del ordenador.

Qué pasa por dentro

Un peritaje de tacógrafo no maneja «datos de usuario». Maneja el nombre y el DNI de un conductor concreto, la hora exacta a la que arrancó el camión cada día de los últimos dos meses, dónde cruzó una frontera y a veces su parte médico. El fichero descargado de una tarjeta de conductor es, además, material probatorio: se aporta a un procedimiento judicial con una cadena de custodia detrás.

Que ese binario salga del equipo no es un detalle de configuración. Es un incidente.

Puesto así, la pregunta deja de ser «¿cuántas peticiones hacemos?» y pasa a ser «¿por qué hacemos alguna?». Que es una pregunta mucho mejor, también para una web.

Qué significa «sin red» cuando se dice en serio

Lo fácil es escribir «la aplicación es local» en un folleto. Lo que hubo que quitar de verdad:

Ninguna CDN. Ni para una librería de gráficos, ni para un icono. Una etiqueta que apunta a un dominio ajeno es una petición desde el ordenador del usuario a un tercero, con su dirección IP y la hora. Todo se descargó una vez, se revisó, se guardó en el repositorio.

Ninguna fuente remota. Las tipografías de Google son el caso más común y el más invisible: cada visita a una página con una fuente cargada desde fonts.googleapis.com es una conexión del navegador de esa persona a Google, antes de que la página termine de dibujarse.

Ninguna telemetría. Ni anónima, ni «para mejorar el producto».

Ninguna actualización automática. Esta cuesta más de lo que parece, porque implica que actualizar una dependencia es una decisión que alguien toma, mira y firma. Es más trabajo. También es la única forma de saber qué código se está ejecutando.

El efecto secundario es curioso: al no poder tirar de nada externo, el programa pesa menos y arranca antes. La privacidad y el rendimiento suelen ir del brazo, aunque se vendan como cosas distintas.

Las dos excepciones, por escrito

Decir «cero conexiones» y luego hacer una es la forma más rápida de que la regla deje de valer. Así que hay exactamente dos excepciones, cada una escrita con su alcance, su fecha de autorización y su límite. Lo que no esté ahí, no sale.

La primera: el sello de tiempo. Cuando se emite un documento, su huella digital (un SHA-256, sesenta y cuatro caracteres) viaja a una autoridad de sellado que devuelve un sello firmado. Sale la huella. No sale el documento, ni el expediente, ni el nombre del cliente, ni un solo dato del caso. Una huella no se puede revertir: de esos sesenta y cuatro caracteres no se reconstruye nada.

La segunda: la captura sellada de una página web. Sirve para dejar constancia de que un anuncio de venta decía lo que decía antes de que el vendedor lo edite. Y aquí viene lo incómodo, que es justo lo que hay que escribir: en esta sí sale la dirección completa, porque la autoridad de sellado tiene que visitar la página. Si esa dirección lleva un identificador en la query, eso sale del equipo.

Por eso esa segunda excepción solo se lanza a mano, desde su propio comando, una dirección cada vez. No es automática, no va encadenada a la emisión de ningún documento, avisa en pantalla antes de enviar nada y pide conformidad. Una dirección con usuario o contraseña dentro se rechaza sin preguntar.

La lección, que es la parte aprovechable: una excepción que no está escrita no es una excepción, es una puerta abierta que nadie recuerda haber dejado así.

Qué prueba un sello de tiempo. Y qué no

Conviene ser exacto, porque aquí se exagera mucho.

El artículo 41.1 del Reglamento (UE) 910/2014, el que llaman eIDAS, impide negar admisibilidad como prueba a un sello de tiempo electrónico por no ser cualificado. Pero el 41.2 reserva la presunción de exactitud de la fecha y de la integridad de los datos a los sellos cualificados, que son los emitidos por un prestador sometido a supervisión.

Traducido: un sello de una autoridad gratuita es admisible y prueba que un documento con esa huella exacta existía en esa fecha y que no ha cambiado desde entonces. No tiene la presunción legal del sello cualificado. En un juicio suele bastar. Decir que «está certificado notarialmente» sería mentira.

Preferimos la frase larga y cierta a la corta y vendedora. Aquí también.

Reproducible o no vale

La otra regla es que el mismo fichero de entrada produzca el mismo resultado, byte a byte, en ejecuciones distintas y en ordenadores distintos. Eso prohíbe dos cosas dentro del motor de cálculo: la fecha del sistema y los números aleatorios.

Suena a manía de programador hasta que se piensa en la escena: el perito contrario coge el mismo fichero, lo procesa con la misma herramienta y le sale otra cosa. Un dictamen que no se puede reproducir no se puede defender. Así que las marcas de tiempo se inyectan desde fuera, nunca se leen desde dentro.

Hay un equivalente web de esto, menos dramático pero real: si tu web se construye cada vez de una forma, nadie puede saber qué se publicó el martes pasado.

Qué tiene que ver con tu web

Más de lo que parece, porque la pregunta de fondo es la misma: ¿sabes qué datos de tus visitantes salen de tu web hacia terceros?

Una página corriente de pyme suele enviar, sin que nadie lo haya decidido conscientemente:

  • La IP de cada visitante a Google, por las fuentes tipográficas.
  • La IP, la página visitada y la hora a una herramienta de analítica, a menudo antes de que el visitante toque el banner de cookies.
  • Los mismos datos a Facebook, si alguien pegó un píxel hace tres años para una campaña que ya no existe.
  • Todo lo anterior otra vez a YouTube si hay un vídeo incrustado. También a Google Maps si hay un mapa.

Un mapa de contacto y un vídeo de presentación pueden suponer más conexiones a terceros que todo el resto de la web junta.

El artículo 5.1.c del RGPD exige que los datos personales sean «adecuados, pertinentes y limitados a lo necesario». Es difícil sostener que mandar la IP de alguien a tres empresas distintas antes de que haya leído tu teléfono encaja ahí. Y el 5.2 añade la parte que se olvida: el responsable no solo tiene que cumplir, tiene que poder demostrarlo.

Casi nadie puede, porque casi nadie sabe qué carga su propia web.

Cómo lo hacemos en lo que entregamos

Sin heroicidades y sin renunciar a nada visible:

Las fuentes se sirven desde tu propio dominio. Se descargan una vez, se suben con la web, se acabó la conexión a Google. El visitante ve exactamente la misma tipografía. Como viaja con el resto de la página, suele cargar antes.

Nada de terceros antes del consentimiento. La analítica, el mapa y el vídeo no se cargan hasta que la persona acepta. Si no acepta, el mapa se sustituye por una dirección y un enlace, que para ir a tu taller funciona igual de bien.

Cada script externo tiene que justificarse. Si nadie recuerda para qué se puso, se quita. Es sorprendente la cantidad de webs que arrastran píxeles de campañas terminadas hace años.

Lo que se dice en la política de privacidad es lo que de verdad ocurre. Un documento legal que enumera proveedores que ya no usas es peor que no tenerlo: demuestra que nadie lo ha mirado. Sobre esto escribimos en otra entrada.

Esto no convierte una web en una fortaleza. La convierte en una web que sabes explicar, que es lo que te van a pedir el día que alguien pregunte.

Por qué lo contamos

Porque es nuestra forma de trabajar y conviene que se vea antes de contratar, no después.

Tarraco App Lab nació de un gabinete pericial, no de una agencia de marketing. Eso explica estas manías mejor que cualquier declaración de principios: cuando has tenido que defender un dato delante de un juez, se te quitan las ganas de poner en una web cosas que no sabes explicar.

Si quieres ver el resto de lo que hacemos, está todo reunido en el contenedor de enlaces. Y si lo tuyo es el transporte, Perito Camión es la parte pericial, Carretera Nacional publica información laboral del sector sin vender nada, y Oriana Mail es el gestor de correo que usamos a diario, construido con las mismas reglas que esta entrada describe.

Y si tienes una web y no sabes qué está enviando por ahí, es una pregunta razonable para hacernos.

← Volver al blog

Comentarios