Skip to main content

America.gov's Login.gov plan highlights a 20-year cookie setting

A browser ID used for a design experiment also enters analytics. The new federal gateway makes its lifetime, opt-out behavior and data-retention rules important.

Pale stone doorway frame around frosted glass, with a dark oval token and a thin blue light line
TechKili · AI-generated illustration with Cloudflare FLUX
Share this article:
In this article

America.gov's September 29 launch comes with a directive to integrate Login.gov as its authentication service. That matters to future users of the federal gateway because public Login.gov code already contains a persistent browser identifier for a design experiment, and includes that ID in analytics.

Biometric Update examined the issue on October 1. The code supports questions about lifetime, data linkage and opt-out behavior. It does not establish that America.gov is already building a twenty-year record of every user's government transactions.

The launch changes the context for the sign-in service

GSA's launch announcement describes an AI-enhanced gateway drawing information from government websites. The September 29 executive order goes further by directing integration with Login.gov.

The order also sets a policy of preserving each agency's custody and control of its records, rather than creating a centralized federal system of records. Those are stated requirements. They do not answer how the authentication layer's own identifiers and analytics are retained or connected.

That distinction matters because a shared sign-in service and an agency's benefit records serve different purposes. A promise about agency records needs to be considered alongside the metadata generated while people access services.

A twenty-year expiry is a setting, not a retention finding

The public application controller checks for a cookie named nds_experiment_uuid. When absent, it generates a random UUID using Rails' permanent cookie mechanism. The ID is used to assign the browser to the National Design Studio interface experiment.

Official Rails documentation explains that this mechanism sets expiry twenty years into the future. That describes the declared cookie lifetime. It does not measure how long a particular browser actually keeps it, or how long related server-side records survive.

The analytics code copies the cookie value into request attributes when a cookie jar is available. This creates a potential link between events carrying the same browser ID. The source-code evidence does not settle who can access those events, their retention period or the production rules for associating them with an authenticated account.

Returning to the old interface keeps the experiment ID

The opt-out controller records the choice of legacy interface against the experiment ID. It deletes a separate override cookie, ui_test_bucket, and records an opt-out analytics event. It does not delete nds_experiment_uuid.

There is a functional reason for remembering an identifier: the service can recognize that browser's preference on a later visit. But opting out of a design experiment and requesting deletion of analytics data are different actions. Readers should not treat the interface switch as a general tracking opt-out.

Ask about linkage and deletion as well as expiry

A public issue opened on September 12 asks about the intended lifetime, the identifier's behavior before sign-in, the opt-out and the relevant privacy assessment. That concern predates the new gateway launch.

For public-service teams, useful answers would specify which events carry the identifier, whether they can be linked to an account or agency context, who has access and when the records are deleted. A documented explanation of those controls would be more informative than either calling the UUID harmless because it is random or treating its expiry as proof of twenty years of surveillance.

For users, the concrete limitation is narrower: choosing the legacy Login.gov design does not remove this browser ID in the reviewed implementation. Assess the authentication service's privacy terms separately from the gateway's presentation and from the agency service being accessed.

Sources