The Trump administration has launched America.gov as a single AI-powered gateway to federal information and services with an unusually explicit privacy promise. But the authentication system the new portal is ordered to use already contains recently added Login.gov code supporting a National Design Studio experiment (NDS) that creates a long-lived browser identifier and incorporates it into Login.gov analytics.

Architecturally, America.gov is becoming the presentation and service-access layer for federal government services, while Login.gov is being positioned as the reusable identity and authentication layer underneath it.

Users may encounter government through a single America.gov interface, but Login.gov is intended to provide common sign-in and identity verification infrastructure that participating agencies and services can reuse.

America.gov itself does not currently require users to identify themselves. Its privacy materials say it does not use advertising cookies or third-party trackers, does not retain chat history and uses only approximate location rather than precise GPS data.

That is only the first stage.

An executive order President Donald Trump signed Tuesday directs the General Services Administration (GSA) to make America.gov the federal government’s single digital point of entry and specifically orders GSA to integrate Login.gov and use it as America.gov’s authentication service.

Federal agencies are also directed to connect covered services, digital forms, and application programming interfaces to the platform.

The administration says the integrations are to occur in a “secure and privacy-preserving manner.” The order also states that it does not authorize anyone other than an originating agency to access that agency’s records about an individual, except as permitted by the Privacy Act or other law.

But public Login.gov source code shows that the National Design Studio’s work on the authentication platform has already introduced an identifier whose privacy implications have not been publicly explained.

On September 4, Login.gov merged code for the National Design Studio’s new “look and feel” experiment that added a function called nds_experiment_uuid to Login.gov’s base application controller.

The code runs the function as a before_action and checks for an existing nds_experiment_uuid cookie. If one does not exist, it generates a random universally unique identifier (UUID) and stores it using Ruby on Rails’ cookies.permanent cookie jar. The same identifier is then used to determine which version of the NDS interface the visitor receives.

The framework’s documentation says cookies.permanent sets a cookie to expire in 20 years.

The code provides at least one technical reason for retaining the identifier. Login.gov records the opt-out assignment using nds_experiment_uuid as the discriminator, allowing the application to recognize that browser as having opted out on later visits.

An open GitHub issue notes that clearing the UUID causes the browser to lose that opt-out status. The privacy question is why the implementation gives that identifier a 20-year expiration and attaches it to analytics events.

Because the NDS experiment code places the function in Login.gov’s base application controller rather than waiting until a user authenticates, the identifier can be generated before the visitor signs in.

The code’s own tests show the UUID being stored on the first page load for visitors assigned either the NDS design or the legacy interface.

On September 9, five days after Login.gov merged the code that created the nds_experiment_uuid, it merged another change that added the identifier to the attributes attached to analytics events generated by the service.

The cookie is part of Login.gov, not the America.gov chatbot. Nevertheless, it creates a persistent pseudonymous identifier that can distinguish one browser from another across repeated Login.gov visits for potentially many years.

Once the identifier is also included in analytics events, the privacy question becomes what other event attributes can be associated with it, how long those records are retained, and whether authentication or agency context can be correlated with them.

Those questions have surfaced publicly inside Login.gov’s own GitHub repository.

An open issue filed September 12 asks why the identifier was created even when the NDS experiment is set to a zero-percent rollout, why it is apparently generated on public Login.gov endpoints, and whether a 20-year lifetime is intentional.

It also asks what privacy assessment covers the cookie and the related analytics records.

The issue remains open.

Subsequent NDS code makes another aspect of the implementation notable.

Login.gov provides a mechanism that lets users opt out of the NDS interface and switch to the legacy design. A change merged September 21 strengthened that opt-out mechanism and explicitly deletes a separate ui_test_bucket cookie that can force the NDS interface.

However, the code does not delete nds_experiment_uuid. Instead, it records the opt-out using that identifier as the experiment discriminator, while the long-lived browser identifier remains in place.

The same open GitHub issue highlights that behavior, noting that the UUID continues to attach to analytics events after the interface opt-out.

There may be a legitimate engineering reason to preserve an experiment identifier after someone leaves an experiment. Developers commonly need to determine whether the same browser returns and to calculate experiment and opt-out statistics.

The privacy question, though, is why such an experiment requires an identifier designed to survive for two decades, particularly on a federal identity platform that is about to become the authentication layer for a much broader government services portal.

Login.gov already has a detailed Privacy Impact Assessment (PIA). GSA’s currently posted Login.gov PIA, revised March 10, 2026, principally addresses retention and use of information by Login.gov’s anti-fraud team.

That was nearly six months before the nds_experiment_uuid changes were merged.

The PIA describes a deliberately segmented identity system. Login.gov assigns a user a master UUID that remains internal to Login.gov and then creates a different agency-specific UUID for each participating agency.

The agency identifier and whatever minimum account information the agency requires are provided only after the user consents.

The NDS experiment UUID is something different. It is a browser identifier created for an interface experiment rather than the authenticated master or agency-specific UUIDs described in the PIA.

GSA’s published PIA index, checked after America.gov’s launch, continues to list the March Login.gov assessment but does not list a separate America.gov PIA.

An early-2027 phase is expected to allow people to apply for, enroll in, and track federal benefits directly through America.gov.

Demonstrations at the launch showed users transmitting marriage certificates to selected agencies, accessing Medicare-related services, and using Login.gov to verify their identities for agencies including the Centers for Medicare and Medicaid Services, Social Security Administration, and Department of Veterans Affairs.

A passport service using Login.gov authentication is scheduled to begin in December.

GSA says America.gov will be housed within its Technology Transformation Services operation and was engineered in partnership with the National Design Studio.

The National Design Studio was established by executive order in August 2025 inside the White House Office to redesign federal digital and physical services, and its handling of website analytics has previously drawn scrutiny.

The Guardian reported in June that NDS-built federal sites used PostHog and a custom telemetry script, with some tracking removed after inquiries about it were made.

There is no public evidence that America.gov is currently running those systems, and its policy says the new portal does not use tracking technologies.

The question is what happens when the anonymous chatbot becomes an authenticated transaction layer through Login.gov through which people obtain passports, manage benefits, submit government documents, and interact with multiple agencies from the same interface.

The White House order attempts to preserve a crucial boundary by saying agencies retain control of their own records rather than transferring them into one centralized America.gov database.

But centralizing the interface can still generate information authentication events, agency destinations, transaction metadata, document activity, and other records showing how an individual interacts with government.

Login.gov’s new NDS identifier illustrates why those details matter.

A randomly generated UUID used to test a redesigned webpage is not, by itself, a national tracking system.

But a browser identifier with a nominal 20-year lifespan, generated before authentication and copied into analytics events on the identity service that sits in front of America.gov, warrants a clearer public explanation of what it records, how it is used, and how long the resulting data survives.

GSA and the National Design Studio should be able to answer whether the nds_experiment_uuid is intended to persist for 20 years, why opting out of the NDS interface does not delete it, which analytics records contain it, whether those events can be associated with authenticated users or the agencies they are visiting, and what privacy review authorized the September changes.

As the site evolves into an authenticated gateway to federal services, the more important privacy question will be whether the architecture behind that promise is designed to prevent the government’s new digital front door from also becoming a durable record of who walked through it and where they went.

Article Topics

America.gov  |  authentication  |  data privacy  |  device fingerprinting  |  digital government  |  digital identity  |  Login.gov  |  U.S. Government