Don't take our word for it.
Every technical claim on this site rests on a public record you can open in a browser. No account, no special access, no permission. Here is how to check the four main ones yourself, what you should expect to find, and just as importantly, what each record does not prove.
THIS GUIDE
We publish under the AltNPS name, not individual bylines. That is a fair reason to be skeptical of us. The answer is not to ask for trust. It is to show you the underlying records so you can check our conclusions yourself and challenge them if they do not hold up.
Start anywhere. Each one stands on its own.
When a certificate for a federal hostname was publicly logged, independent of any announcement.
~3 min2Who owns the domainWhich part of the government registered it, the pairing that gives the certificate records context.
~2 min3The tracking, in your browserWhat a Studio-run site loads and where it sends data. This may no longer reproduce live.
~3 min4The missing filingsHow to search for the System of Records Notices and privacy filings we could not find.
~2 minCheck 3 may no longer reproduce live because the tracking was apparently removed in June 2026. That section explains what you can check instead.
The certificate logs
This is the backbone of the site. Every date we cite for when a federal site came into existence comes from here. When any website obtains an encryption certificate, that certificate is written to public, append-only logs (a security feature of the web, not a leak).
Go to crt.sh in any browser.
In the Identity search box, enter the domain with a wildcard to catch subdomains:
Press search. You will get a table with columns for the logged date, validity dates, the issuer, and the matching identities (the hostnames the certificate covers).
Sort by the logged date and read the matching identities column. This is where the unannounced hostnames appear.
Repeat for passports.gov and note the first entry's date.
Hostnames under previews.ndstudio.gov that were never publicly announced, including staging environments referencing other agencies. A first passports.gov certificate dated May 5, 2026, and two photo-upload subdomains logged within roughly an hour of each other on May 26, 2026.
That a hostname existed and was configured. Not that a site was live, public, or used, and not who created it or why. Raw row counts are meaningless, which is why we don’t use the "979 certificates" figure that circulates elsewhere.
Who owns the domain
Certificate logs tell you a hostname exists. The .gov registry tells you which part of the government registered it. This is the pairing that makes the findings meaningful.
CISA publishes the full list of federal .gov domains as a public CSV. Search for "CISA dotgov data" or go to the get.gov registry data page.
Download or open the current federal domains file.
Search within it for each of the four domains that matter here:
Read the agency and organisation columns for each.
passports.gov and ndstudio.gov both showing the Executive Office of the President in the agency column, where you would expect the State Department or GSA. vote.gov registered to the Election Assistance Commission. That is the contrast, since the preview hostname in the certificate logs is not on EAC infrastructure. For usadf.gov, a security contact address at the ndstudio.gov domain.
Registration shows administrative responsibility, not intent or use. Who registered a domain is not why.
The tracking, in your browser
You don't need any tools for this. Every browser ships with a network inspector that shows what a page loads and where it sends data.
Open a Studio-run site, trumprx.gov is the clearest example.
Open developer tools. F12 on Windows, Cmd+Option+I on Mac, or right-click anywhere and choose Inspect.
Click the Network tab, then reload the page so it captures from the start.
Filter the requests for each of these in turn:
Click an individual request and read the Headers and Payload tabs to see what is being sent and to which host.
Then look at the page source for the analytics initialisation and check whether session recording is enabled, and whether the host is a first-party path or a PostHog domain.
Analytics requests going to a first-party path on the site's own domain instead of directly to a third-party analytics host (the reverse-proxy configuration). Session recording enabled in the initialisation. Payloads containing interaction events, not simple page views.
Your browser shows what leaves it, not what happens to the data afterwards: retention, access, sharing, or where it is stored.
The missing filings
One of our central findings is a negative: we searched for privacy filings tied to the Studio and its programs and could not find them. Negatives are hard to prove, which is why we want you to run the search yourself and tell us if you find something we missed.
Go to federalregister.gov and search for:
Filter the document type to Notice. System of Records Notices are published as notices.
Separately, search for "America by Design" and the individual site names: trumprx, passports.gov, realfood.
For comparison, search for the SAVE notice and find the one published October 31, 2025, at 90 FR 48948. That filing exists and was published after the system it describes was already running.
No System of Records Notice for the Studio or its programs under the names we searched. You should also find the SAVE notice from October 2025, which demonstrates what such a filing looks like and provides an example of one published after a system was already operating.
A Federal Register search that finds nothing is a null result, not proof of absence. A filing could exist under a different name or may not have been published. That gap is the point, not a weakness. The documents that would help close it, including a Privacy Impact Assessment or System of Records Notice, are exactly the ones we have not found.
Public records establish that things exist, when, and who registered them. They do not establish purpose.
Shows administrative responsibility, not intent or use. Who registered a domain is not why.
Shows what leaves it, not what happens to the data afterwards: retention, access, sharing, and storage location.
A Federal Register search that finds nothing is a null result, not proof of absence; a filing could exist under different naming or unpublished.
That gap is the point, not a weakness in it. The documents that would close it are a Privacy Impact Assessment and a System of Records Notice. These are exactly the ones missing.
The script we cannot fully read.
A custom JavaScript file of roughly 540 lines is served from Studio infrastructure and deployed across Studio-run federal sites. It generates persistent session identifiers and posts telemetry to a Studio-controlled endpoint. Unlike PostHog it is not a commercial product with published documentation, so nothing describes what it collects or how long anything is kept.
It is publicly served, which means anyone can fetch and read it. If you write JavaScript, this is the single most useful hour anyone could spend on this story.
What fields are collected and assembled into each payload.
How the session identifier is generated, and whether it persists across visits, across sites, or both.
Whether any identifier survives clearing cookies.
What the endpoint returns, and whether anything is set in response.
Whether behaviour differs across the sites it is deployed on.
We will not publish anything obtained that way.
If we're wrong, tell us, and we'll say so.
If you run these checks and find something different from what we describe, a date that doesn't match, a registration we got wrong, or a filing that exists, send it to [email protected]. We will verify it, correct the site, and log the change with the date.
That is not a courtesy. A site that publishes a verification guide and then ignores people who followed it would be worse than one that never published the guide at all.