Login.gov: la cookie de 20 años detrás de America.gov

Un identificador de 20 años en el corazón del login del gobierno de EE.UU.

El 30 de septiembre, la administración Trump presentó America.gov, un portal con IA que aspira a ser la «puerta digital única» del gobierno federal: asistente conversacional para Medicare, renovación de pasaportes y, en una segunda fase en 2027, gestión de beneficios sociales como el Seguro Social. La promesa de privacidad del sitio es explícita: no usa cookies publicitarias, no retiene el historial de chat, no recaba ubicación precisa y dice no apoyarse en rastreadores de terceros. El problema es que la autenticación que se le ordenó integrar —Login.gov— ya contiene código nuevo con un comportamiento difícil de cuadrar con esa promesa: una cookie con expiración nominal de 20 años que se genera antes de iniciar sesión y termina copiándose a los eventos de analítica del servicio.

Es el clásico caso de «el front matter dice una cosa, el back matter hace otra». Y para los founders que construyen sobre identidad, IA conversacional o govtech, las preguntas que abre son las mismas que deberían hacerse en cualquier producto serio: ¿qué cuenta como dato personal?, ¿qué significa «anonimizar»?, ¿quién audita el pipeline de eventos?

America.gov en 60 segundos: qué se lanzó y qué viene

America.gov fue diseñado por la National Design Studio (NDS) y se ejecuta dentro de la Technology Transformation Services de la GSA. En el evento de lanzamiento, su chief design officer Joe Gebbia (cofundador de Airbnb) explicó que el sitio consulta 29.000 dominios federales para responder preguntas, está potenciado por los modelos Gemini y Grok, y que unos 40 millones de personas visitan webs del gobierno cada día. Trump firmó el mismo día una orden ejecutiva que obliga a las agencias a integrar sus servicios públicos con America.gov y a usar Login.gov como capa de autenticación.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La arquitectura que resulta de la orden ejecutiva divide el trabajo en dos capas:

Capa de presentación: America.gov, donde hoy el usuario hace preguntas anónimas y, a partir de diciembre de 2026, podrá solicitar pasaportes. En 2027 se añadirán solicitudes, seguimiento y envío de documentos (actas de matrimonio, por ejemplo) a agencias como los Centers for Medicare and Medicaid Services (CMS), el Social Security Administration (SSA) y el Department of Veterans Affairs (VA).
Capa de identidad: Login.gov, pensada como la infraestructura reutilizable de sign-in y verificación de identidad sobre la que las agencias pueden apoyarse.

Hasta ahora, la parte de la experiencia que ve el ciudadano parece limpia. La preocupación está más abajo, en el código.

La cookie de 20 años: qué se mergedeó en Login.gov durante septiembre

El código fuente público de Login.gov (alojado en GitHub) muestra que el 4 de septiembre se fusionó un cambio del NDS para un experimento de rediseño de interfaz. El cambio añade una función nds_experiment_uuid al controlador base de la aplicación: si no existe la cookie, genera un UUID aleatorio y lo guarda con cookies.permanent de Ruby on Rails, que según la documentación del framework expira a los 20 años. El identificador decide qué versión del nuevo diseño verá el visitante.

Cinco días después, el 9 de septiembre, otro commit incorporó ese mismo UUID a los atributos de los eventos de analítica que envía el servicio. El 12 de septiembre un contributor abrió un issue público —todavía abierto— preguntando por qué el cookie se crea incluso con el experimento en rollout del 0%, por qué se genera en endpoints públicos, y qué evaluación de privacidad cubre el cambio. El 21 de septiembre se reforzó el mecanismo para que el usuario pueda salirse del diseño NDS, pero el código no borra nds_experiment_uuid: lo usa como discriminador para registrar el opt-out, mientras el cookie sigue en su sitio.

El detalle técnico clave para cualquier founder que trabaje con Rails: cookies.permanent no es lo mismo que un cookie de sesión. Es, literalmente, la primitiva que Rails ofrece cuando quieres que un identificador siga al navegador durante décadas. Es la misma que usarías para reconocer un dispositivo en una app móvil después de un reinicio.

Por qué preocupa más que la promesa de la página de privacidad

El PIA (Privacy Impact Assessment) de Login.gov, revisado el 10 de marzo de 2026, describe un sistema de identidad deliberadamente segmentado: un master UUID interno y un UUID distinto por agencia, este último solo entregado tras consentimiento del usuario. El nds_experiment_uuid no encaja en ese molde: es un identificador de navegador previo al login, pensado para un test de UI, y ahora copiado en los registros de analítica.

Tres preguntas concretas que el código plantea:

¿Por qué 20 años para un test de UI? Un experimento de «look and feel» se mide en semanas. La única razón que sobrevive a 20 años en un cookie es asumir que el mismo navegador volverá.
¿Por qué persistir al opt-out? Si el visitante se sale del nuevo diseño, la cookie sigue y sigue adjunta a eventos de analítica. Cualquier correlación con autenticaciones futuras —que sí tendrán identidad verificada— sale gratis.
¿Por qué generarlo en endpoints públicos? El PIA segmenta cuidadosamente qué UUID llega a qué agencia y cuándo. El UUID del NDS rompe esa frontera: existe antes de cualquier consentimiento.

The Guardian reportó en junio que sitios federales rediseñados por el NDS usaban PostHog y un script de telemetría a medida, y que parte del rastreo se eliminó tras preguntas de la prensa. Que America.gov declare que no usa esas herramientas no resuelve el problema: la cookie vive en Login.gov, que es la capa que se le ordenó integrar.

¿Qué significa esto para tu startup?

Si construyes productos en identidad, autenticación, AI conversacional o datos para gobierno, esta historia es un caso de estudio con tres lecturas prácticas:

1. Elige primitivas de almacenamiento a la altura del dato. Si un identificador de UI va a sobrevivir 20 años, no debería vivir en cookies.permanent ni en ningún cookie de larga vida sin revisión legal previa. Para tests de UI bastan cookies de sesión, localStorage con expiración corta, o un token de un solo uso. En tu roadmap de auth, diferencia siempre entre identificadores de dispositivo, identificadores de cuenta y experiment IDs, y dales tiempos de vida congruentes con su propósito.
2. El «no guardamos X» del front matter se rompe en el back. America.gov repite que no rastrea; sin embargo, el login al que se le obliga a integrarse instala un cookie de 20 años. La auditoría moderna empieza en el repositorio, no en la página de privacidad. Publica o audita un equivalente a un PIA antes de lanzar: qué se genera, qué se copia a eventos, qué sobrevive al opt-out, y qué pasa cuando el visitante no está autenticado.
3. Si vendes a gobierno, la barra se está moviendo. Para 2027 America.gov será el front door único de decenas de agencias, con Login.gov como capa de auth. Founders de govtech y de infraestructura de identidad deberían mapear su integración con Login.gov desde ya, entender qué UUIDs entrega la plataforma hoy, y diseñar sus eventos de analítica asumiendo que ese identificador existe y persiste. Lo que se ve como «infra aburrida» es, en la práctica, la pieza que todos los demás servicios del gobierno van a tener que respetar.

Conclusión

America.gov es, en el papel, el experimento de front office más ambicioso del gobierno de EE.UU. en una década. En el código, su capa de autenticación acaba de fusionar un identificador de 20 años que ningún PIA ha explicado todavía. La distancia entre la promesa pública y la implementación no es nueva —Google, Meta y decenas de consumer apps la han recorrido— pero sí es infrecuente verla en una plataforma que va a manejar pasaportes, Medicare y beneficios sociales. Para los founders que toman a EE.UU. como mercado de referencia, el caso vale como recordatorio: en 2026, la privacidad dejó de ser una cláusula en el footer. Es una propiedad de la arquitectura.