Saltar al contenido principal

El plan de America.gov con Login.gov pone el foco en una cookie con caducidad a 20 años

Un identificador del navegador para un experimento de diseño también entra en la analítica. El nuevo portal federal plantea preguntas sobre duración y exclusión.

Marco de una puerta de piedra clara alrededor de un cristal esmerilado, con una pieza ovalada oscura y una fina línea de luz azul
TechKili · Ilustración generada con IA mediante Cloudflare FLUX
Compartir este artículo:
En este artículo

El lanzamiento de America.gov del 29 de septiembre viene acompañado de una orden para integrar Login.gov como servicio de autenticación. Esto importa a los futuros usuarios del portal federal porque el código público de Login.gov ya contiene un identificador persistente del navegador para un experimento de diseño y lo incorpora a la analítica.

Biometric Update examinó la cuestión el 1 de octubre. El código justifica preguntas sobre duración, vinculación de datos y comportamiento de la exclusión voluntaria. No demuestra que America.gov ya esté construyendo un registro de veinte años de todas las transacciones gubernamentales de cada usuario.

El lanzamiento cambia el contexto del servicio de acceso

El anuncio de GSA describe un portal con búsqueda mejorada mediante IA que recopila información de webs gubernamentales. La orden ejecutiva del 29 de septiembre va más allá al ordenar la integración con Login.gov.

La orden también establece la política de preservar la custodia y el control de los registros de cada agencia, en lugar de crear un sistema federal centralizado de registros. Son requisitos declarados. No responden a cómo se conservan o relacionan los identificadores y la analítica de la propia capa de autenticación.

La distinción importa porque un servicio compartido de acceso y los registros de prestaciones de una agencia cumplen funciones diferentes. Una promesa sobre los registros de las agencias debe considerarse junto con los metadatos generados cuando las personas acceden a los servicios.

La caducidad a veinte años es un ajuste, no una medida de retención

El controlador público de la aplicación comprueba si existe una cookie llamada nds_experiment_uuid. Cuando falta, genera un UUID aleatorio mediante el mecanismo de cookies permanentes de Rails. El identificador asigna el navegador al experimento de interfaz de National Design Studio.

La documentación oficial de Rails explica que ese mecanismo fija la caducidad veinte años en el futuro. Describe la duración declarada de la cookie. No mide cuánto tiempo la conserva realmente un navegador concreto ni cuánto sobreviven los registros relacionados del servidor.

El código de analítica copia el valor de la cookie a los atributos de la petición cuando dispone de un almacén de cookies. Esto crea una posible relación entre eventos que llevan el mismo identificador de navegador. La evidencia del código no determina quién puede acceder a esos eventos, cuánto se conservan ni las reglas de producción para asociarlos con una cuenta autenticada.

Volver a la interfaz anterior conserva el identificador del experimento

El controlador de exclusión registra la elección de la interfaz anterior utilizando el identificador del experimento. Elimina otra cookie de anulación de ajustes, ui_test_bucket, y registra un evento analítico de exclusión. No elimina nds_experiment_uuid.

Hay una razón funcional para recordar un identificador: el servicio puede reconocer la preferencia de ese navegador en una visita posterior. Pero salir de un experimento de diseño y solicitar la eliminación de datos analíticos son acciones distintas. El lector no debería interpretar el cambio de interfaz como una exclusión general del seguimiento.

Preguntar por vinculación y eliminación, además de caducidad

Una incidencia pública abierta el 12 de septiembre pregunta por la duración prevista, el comportamiento del identificador antes del acceso, la exclusión y la evaluación de privacidad correspondiente. Esa inquietud es anterior al lanzamiento del nuevo portal.

Para los equipos de servicios públicos, unas respuestas útiles especificarían qué eventos llevan el identificador, si pueden vincularse con una cuenta o una agencia, quién tiene acceso y cuándo se eliminan los registros. Una explicación documentada de esos controles informaría mejor que calificar el UUID de inocuo porque es aleatorio o tratar su caducidad como prueba de veinte años de vigilancia.

Para los usuarios, la limitación concreta es más acotada: elegir el diseño anterior de Login.gov no elimina este identificador de navegador en la implementación examinada. Conviene evaluar las condiciones de privacidad del servicio de autenticación por separado de la presentación del portal y del servicio de la agencia al que se accede.

Fuentes