Un PDF oficial cambió: cómo probar qué versión se consultó
Una URL oficial puede servir un archivo distinto con el tiempo. Fecha, hash, encabezados y metadatos permiten demostrar qué bytes se consultaron sin confundirlos con autenticidad.
Por Marco Ferreiro ·
Una guía oficial puede mantener la misma dirección web y, sin aviso visible, ofrecer un PDF nuevo. Si sólo se guarda el enlace, meses después resulta imposible saber si otra persona leyó la misma versión. Guardar una copia ayuda, pero todavía falta describir cuándo y cómo se obtuvo.
Una cadena mínima de evidencia combina URL, momento, respuesta HTTP y hash. Cada pieza responde una pregunta distinta y evita adjudicarle al hash propiedades que no tiene.
El problema de una URL estable con contenido variable
En HTTP, una URL identifica un recurso, pero la representación que devuelve puede cambiar. El organismo puede corregir una tabla, reemplazar un anexo o actualizar un formulario sin crear un enlace nuevo. También pueden intervenir cachés o variantes de entrega.
Cuando una nota cita “el PDF disponible en esta URL”, la afirmación queda incompleta si el contenido varía. Para que otra persona pueda auditarla hay que registrar la representación observada: el archivo exacto, no sólo el lugar donde apareció.
Esto es especialmente importante cuando un dato —por ejemplo una lista, fecha, requisito o importe— proviene de una página concreta del documento.
Qué demuestra un hash
Los estándares de hash seguro, como la familia definida en FIPS 180-4, producen un resumen de longitud fija a partir de los bytes. Si un solo byte cambia, el valor esperado cambia. SHA-256 es una opción común para identificar una descarga en una cadena de evidencia.
Dos archivos con el mismo hash SHA-256 pueden considerarse iguales a efectos prácticos de esta comparación. Dos hashes diferentes demuestran que las secuencias de bytes no son idénticas. Sin embargo, la diferencia podría deberse a contenido, metadatos internos, compresión o reempaquetado; no necesariamente a una modificación sustantiva del texto.
El hash no prueba que el organismo creó el PDF. Tampoco que la norma siga vigente ni que lo escrito sea correcto. Es una huella de bytes, no una firma institucional.
Los metadatos que conviene capturar
Por cada descarga, registrá:
- URL solicitada y URL final luego de redirecciones;
- fecha y hora en UTC;
- código de estado HTTP;
- tipo de contenido declarado;
- tamaño exacto en bytes;
- hash SHA-256 del cuerpo recibido;
ETag,Last-ModifiedyContent-Digestsi existen;- herramienta y versión utilizadas;
- estado de validación TLS y dominio oficial observado.
RFC 9110 describe validadores como ETag y fechas de modificación. RFC 9530 define campos de digestión para mensajes HTTP. Esos valores pueden complementar la evidencia, pero no deben inventarse si el servidor no los entrega.
Un ensayo controlado con dos descargas
Imaginemos un documento oficial ficticio descargado el 1 de junio y el 15 de julio desde la misma URL. En el primer intento se obtienen 842.110 bytes y el hash H1; en el segundo, 845.006 bytes y el hash H2. Los valores sintéticos H1 y H2 son distintos.
El resultado permite afirmar: “la representación descargada en julio no es idéntica, byte por byte, a la de junio”. No permite afirmar todavía qué párrafo cambió. Para eso hace falta comparar el contenido extraído o revisar visualmente ambas versiones, conservando el número de página y el contexto.
Si el hash cambia pero el texto parece igual, podrían haber cambiado metadatos, fuentes embebidas o el método de compresión. Esa observación también debe registrarse, en vez de concluir que hubo una modificación normativa.
Procedencia: URL, actividad y archivo
PROV-O del W3C propone distinguir entidades, actividades y agentes. Aplicado de forma simple:
- el PDF recibido es una entidad;
- la descarga y el cálculo del hash son actividades;
- el dominio oficial y la herramienta son agentes o actores de contexto, según el modelo usado;
- la nueva copia puede relacionarse con la anterior como revisión sólo cuando existe evidencia para hacerlo.
Esta separación evita decir “el organismo cambió el archivo” cuando lo único probado es que dos descargas difieren. Para atribuir la modificación se necesita contexto oficial: aviso de actualización, metadatos del acto, historial publicado o confirmación de la autoridad.
Cómo citar una versión dentro de una nota
Una cita auditables puede indicar título del documento, organismo, URL, fecha de acceso, página y hash. Si el material se actualiza con frecuencia, resulta útil publicar una tabla de versiones:
| Fecha UTC | Tamaño | SHA-256 | Observación |
|---|---|---|---|
| 2026-06-01 | valor registrado | hash completo | primera captura |
| 2026-07-15 | valor registrado | hash completo | bytes diferentes |
Los datos de la tabla deben provenir de capturas reales. Los valores de esta nota son únicamente una demostración y no identifican un documento existente.
Cuando el contenido citado cambie, la corrección editorial debería explicar qué afirmación se actualizó y conservar el rastro de la versión anterior, sin mantener información obsoleta como si siguiera vigente.
Cómo almacenar sin exponer de más
No siempre corresponde redistribuir el PDF completo. Puede contener datos personales, estar sujeto a condiciones particulares o haber sido accesible sólo bajo una sesión autorizada. En esos casos se conserva de forma privada con controles de acceso y se publica únicamente el hash, los metadatos permitidos y el método.
El nombre del archivo no debería contener patentes, documentos o nombres personales. La copia debe estar protegida contra sobrescritura: una nueva descarga se guarda como otra versión, no encima de la anterior.
También es importante registrar errores. Una página HTML de mantenimiento descargada con extensión .pdf no es un PDF válido aunque la URL termine así. Verificá firma de archivo, tipo real y que el documento pueda abrirse.
Qué no prueban ETag y Last-Modified
Un ETag puede funcionar como validador de una representación, pero su formato y fortaleza dependen del servidor. No debe confundirse con un hash criptográfico del archivo si el sitio no lo define de esa manera. Last-Modified tampoco es la fecha de redacción ni de aprobación del acto.
Estos encabezados sirven para revalidar y detectar señales de cambio. Si el servidor los omite, la descarga sigue pudiendo identificarse mediante tamaño, hash y momento. Si aparecen pero contradicen el archivo observado, se conserva la contradicción para investigar.
Método y límites de esta guía
El procedimiento combina estándares públicos de NIST, IETF y W3C. Se enfoca en la reproducibilidad técnica de una descarga, no en certificar la vigencia jurídica del documento. Los ejemplos usan tamaños y hashes sintéticos.
La frase precisa ante dos resultados distintos es: “los archivos descargados en estas fechas no son idénticos”. A partir de ahí, una comparación de páginas y una fuente oficial adicional permiten explicar el cambio sin convertir la misma URL en una falsa garantía de versión.
Metodología
- Alcance
- Aplicación de estándares de hash, semántica HTTP y procedencia a descargas repetidas de documentos oficiales que conservan una misma URL.
- Unidad de análisis
- Una representación PDF identificada por URL, hora UTC, estado HTTP, encabezados, tamaño, tipo declarado y hash SHA-256.
- Cobertura
- Estándares vigentes y portales oficiales consultados el 14 de agosto de 2026; el método registra bytes observados, no la intención del publicador.
Limitaciones
- Un hash permite comparar archivos, pero no certifica la autoridad, exactitud jurídica ni integridad del sitio desde el cual se descargaron.
- Encabezados como ETag o Last-Modified pueden faltar o cambiar de significado según la configuración del servidor.
Fuentes
- FIPS 180-4 — Secure Hash Standard — National Institute of Standards and Technology (consultada el )
- RFC 9530 — Digest Fields — RFC Editor (consultada el )
- RFC 9110 — HTTP Semantics — RFC Editor (consultada el )
- PROV-O — The PROV Ontology — World Wide Web Consortium (consultada el )
- Portal Andino — acceso a información pública — Argentina.gob.ar (consultada el )
Preguntas frecuentes
¿Dos PDFs con el mismo hash son necesariamente auténticos?
El mismo hash permite afirmar con enorme confianza que los bytes comparados son iguales. No demuestra por sí solo quién publicó el archivo ni si el contenido es correcto; la procedencia debe registrarse por separado.
¿El encabezado Last-Modified prueba cuándo se redactó el documento?
No. Es un metadato HTTP sobre la representación servida y depende del servidor. Puede orientar la revalidación, pero no reemplaza la fecha interna, el acto administrativo ni el hash obtenido al descargar.
¿Hay que publicar una copia completa del PDF para demostrar el cambio?
No necesariamente. Puede publicarse el procedimiento, la URL, las fechas y los hashes. La redistribución del documento depende de sus condiciones, sensibilidad y reglas de acceso.
Notas relacionadas
Qué significa “última verificación” en una fuente de multas
La fecha indica cuándo se consultó una fuente y qué respuesta dio en ese momento. No es la fecha del acta, del pago ni una garantía de que no existan novedades en procesamiento.
Cómo verificamos que un portal de multas sea realmente oficial
Un diseño convincente, un candado HTTPS o aparecer primero en Google no prueban oficialidad. Verificamos dominio, cadena institucional, trámite publicado y canales antes de confiar datos.
De fuente oficial a resultado: el recorrido de una consulta en multas.ar
Entre ingresar una patente y mostrar un resultado hay decisiones sobre alcance, respuesta de cada fuente, normalización y trazabilidad. Documentarlas evita que un error parezca un cero.