Skip to content
https://rgearshop.com/

Resistance Kitty

The sassiest cat fighting fascism

  • Home
  • About
  • News
  • Comics
  • Survival Guides
  • EpsteinWiki
  • Resistance Directory
  • The Butterfly Bureau
  • Merch & Mayhem
  • Toggle search form

RSG #315: How To Audit Government Websites for Hidden Tracking

Posted on July 23, 2026July 22, 2026 Dr. Harmony By Dr. Harmony No Comments on RSG #315: How To Audit Government Websites for Hidden Tracking

Resistance Survival Guide #315

Government websites are supposed to serve the public. However, every visit can generate technical information about the visitor. That information can include an internet address, browser details, device characteristics, referral sources, searches, clicks, form interactions, and the amount of time spent on a page.

Analytics can help agencies understand whether a website works properly. However, undisclosed or excessive tracking creates serious privacy and accountability concerns. The risk becomes greater when a website involves voting, immigration, passports, health care, public benefits, taxes, whistleblower reports, or criminal justice services.

A recent Guardian investigation reported that several redesigned federal websites appeared to use commercial visitor analytics without the public privacy documentation normally associated with federal systems. The White House denied wrongdoing and said its personnel followed applicable legal requirements. The reporting nevertheless demonstrated why the public needs a reliable method for examining government websites.

A website audit can reveal which domains receive information, which cookies appear in a browser, which scripts load during a visit, and whether observable behavior matches the government’s published privacy statements.

Why Government Website Tracking Matters

A routine website visit can reveal more than many people realize. An internet address may expose an approximate location. Browser and device characteristics can help distinguish one visitor from another. Referral information may reveal which website or search brought someone to a government service.

More detailed analytics can record page navigation, mouse activity, scrolling, searches, clicks, and form interactions. Some session recording tools can reconstruct how a visitor moved through a website.

Tracking technology is not automatically evidence of surveillance or unlawful conduct. Some external requests are needed to load fonts, maps, videos, accessibility tools, or security services. The important questions concern what information is collected, why it is collected, where it travels, how long it is retained, who can access it, and whether the agency disclosed those practices accurately.

Understand the Federal Privacy Rules

Section 208 of the E Government Act requires federal agencies to conduct a Privacy Impact Assessment when they develop or purchase certain information technology that handles identifiable information. An assessment may also be required when an agency makes a substantial change to an existing system.

The Department of Justice explanation of the E Government Act describes a Privacy Impact Assessment as an examination of how identifiable information is collected, stored, protected, shared, and managed.

A Privacy Impact Assessment is different from a general privacy policy. A privacy policy tells visitors about the agency’s overall practices. A Privacy Impact Assessment examines a particular system, collection, or technology. It should describe the system’s purpose, information flows, privacy risks, sharing practices, retention rules, access controls, and safeguards.

The Privacy Act may apply when an agency maintains information about people in a system of records that can be retrieved through a name or another personal identifier. The Department of Justice Privacy Act overview explains the standards federal agencies must follow.

Not every cookie or analytics request automatically creates a Privacy Act system of records. Investigators should never describe a tracker as illegal based only on its presence.

The Office of Management and Budget has also issued federal guidance for web measurement and customization technology. The guidance addresses public notice, privacy review, data use, and agency responsibility when federal websites measure visitor activity.

Tools for Auditing a Government Website

Mozilla Firefox includes network and storage inspection tools that allow an ordinary user to examine website requests, cookies, scripts, headers, and browser storage. The Firefox Developer Tools guide explains how these features work.

Blacklight is a free privacy inspection tool originally created by the nonprofit newsroom The Markup. It can identify common advertising trackers, session recording tools, tracking cookies, canvas fingerprinting, and possible key logging behavior.

Webbkoll provides another independent website privacy check. It can help identify external requests, cookie practices, encryption settings, and privacy protections.

Automated tools can miss tracking conducted through government servers. They can also misidentify a legitimate service or produce different findings depending on the page, browser, location, and time of the test. Treat every automated result as an investigative lead that requires verification.

Step by Step Guide

Step 1: Define the Audit

Select one government website and record its exact address, agency, program, date, time, and public purpose. Choose several pages with different functions. Include the home page, privacy policy, contact page, search page, form page, and any page connected to a sensitive service.

Record whether the website uses a government domain, a contractor domain, or a redirect. A government program can operate through a commercial address, so the domain alone does not establish who owns or controls the system.

Create a short audit statement explaining what you plan to examine. A defined scope helps another investigator reproduce the work and prevents unrelated internet traffic from contaminating the findings.

Step 2: Preserve the Public Disclosures

Save the website’s privacy policy, terms, cookie notice, accessibility statement, and any linked Privacy Impact Assessment. Record the publication or revision date shown on each page. Capture screenshots and save copies as PDF files.

Search the agency website for the program name together with “Privacy Impact Assessment,” “privacy notice,” “web measurement,” “analytics,” and “System of Records Notice.”

Search the Federal Register for the agency, program, vendor, and system name. System of Records Notices and other privacy disclosures may appear there even when the agency website makes them difficult to locate.

Create a disclosure table containing the technology named, information collected, stated purpose, recipients, retention period, visitor choices, and responsible agency office. Leave the field blank when the disclosure does not provide an answer.

Step 3: Create a Clean Test Session

Open a private Firefox window. Clear cookies, cached files, and site storage before each major test. Sign out of government accounts and other services before beginning.

Run one test without interacting with the page. Then run another test after using ordinary public features such as searching, scrolling, opening a form, or playing a video. This comparison can reveal technology that activates only after a particular action.

Never enter a real Social Security number, passport number, immigration identifier, medical record, banking detail, confidential tip, or authentication code during an audit. Do not submit invented information through an official government form.

Step 4: Run Independent Privacy Scans

Enter the exact website address into Blacklight. Save the report as a screenshot or PDF. Record the scan date, testing location, device setting, page address, and reported findings.

Repeat the test with Webbkoll. Compare the two results. Look for external analytics, session recording, tracking cookies, canvas fingerprinting, advertising technology, and possible monitoring of typed information.

A scanner result is not proof that every available feature is active. A script may be present while a particular function remains disabled. A scanner can also miss technology that activates only after a specific action or operates through the government’s own domain.

Step 5: Inspect the Network Requests

Open Firefox Developer Tools and select the Network panel before loading the government page. Reload the page and wait for it to finish.

The Network panel will display resources contacted during the visit. Sort the requests by domain. Separate requests connected to the government website from requests sent to other organizations.

Record unfamiliar domains, analytics services, content delivery providers, embedded media, identity services, error reporting systems, security vendors, and website hosting providers.

Select an individual request and review its address, method, initiator, headers, parameters, and response. Look for page addresses, referral information, timestamps, device characteristics, event names, search terms, unique identifiers, and form field labels.

Do not publish complete request files or raw headers without reviewing them carefully. They can contain cookies, session tokens, account identifiers, or other sensitive information.

Step 6: Examine Cookies and Browser Storage

Open the Storage panel in Firefox Developer Tools. Record every cookie created by the website. Include the cookie name, domain, expiration date, and whether it remains after the browsing session ends.

Check local storage and session storage for identifiers, analytics settings, consent choices, and event information. A long random value may be a visitor identifier, but its appearance alone does not prove its purpose.

Search the cookie name, script name, vendor documentation, agency privacy policy, and Privacy Impact Assessment. Record only what the evidence supports.

If the website offers an option to accept or reject tracking, test both choices in separate clean sessions. Document whether rejecting optional tracking changes the cookies, scripts, or network requests.

Step 7: Identify Every Outside Organization

Investigate each external domain contacted by the website. Determine which company, nonprofit organization, contractor, or government office controls it.

Begin with the domain, the organization’s privacy policy, public technical documentation, agency procurement records, and relevant Privacy Impact Assessments.

Search USAspending and SAM.gov for agreements involving the agency, program, website, vendor, analytics service, hosting provider, or redesign project.

A service may be provided through a subcontractor, another agency, or a government wide purchasing agreement. The absence of an obvious contract does not prove that no agreement exists.

Distinguish verified ownership from a possible connection. A shared hosting provider or similar domain name does not prove that two organizations share visitor information.

Step 8: Compare the Evidence With the Privacy Policy

Place the privacy policy and Privacy Impact Assessment beside your technical findings. Determine whether the disclosures identify the observed analytics provider, information categories, purposes, recipients, retention practices, and visitor choices.

Check the dates of the privacy documents. An assessment written before a website redesign may not describe the current technology or information flow.

Classify each result as disclosed and consistent, disclosed but unclear, observed but not located in public disclosures, or unresolved.

This language helps prevent an investigator from presenting uncertainty as proof of misconduct.

Step 9: Determine What Information Leaves the Browser

A request to an outside domain proves that the browser contacted that domain. It does not automatically prove that the organization identified the visitor, retained the information, or used it for enforcement.

Examine the information contained in each visible request. Look for unique identifiers, page addresses, event descriptions, referral sources, search terms, timestamps, and device details.

Session recording technology deserves particular scrutiny because it may capture detailed interactions. Possible key logging behavior also requires careful verification. Some tools monitor input events without collecting the words a person types.

Determine what information was actually transmitted before claiming that typed content or personal information was collected.

Step 10: Look for Server Based Tracking

Some tracking operates through a government domain rather than sending information directly from the browser to a visible outside domain. The government server may receive the information first and forward it to another system or contractor.

This arrangement can make a commercial analytics service appear to be part of the government website. Browser inspection alone may not reveal the final recipient.

Look for unusual collection addresses, analytics event names, vendor specific script language, proxy services, and changes in domain ownership. Then search contracts, privacy assessments, data flow diagrams, technical documentation, and procurement records.

Describe this as possible server based collection unless records confirm the information flow.

Step 11: Compare the Website Over Time

Repeat the audit on a fixed schedule and after every announced redesign. Use the same pages, browser, settings, and interaction sequence whenever possible.

Compare privacy policies, screenshots, cookie lists, external domains, scripts, and network requests. Record when a tracker appears, disappears, changes ownership, or begins collecting new information.

The Internet Archive can help establish when public language or website content changed. Archived pages may not preserve every script or network request, so they should not replace a live technical examination.

Step 12: Request the Missing Records

If the audit reveals an unexplained vendor or collection method, submit a focused public records request. Ask for the current Privacy Impact Assessment, initial privacy review, data flow diagram, analytics configuration, data retention schedule, vendor agreement, statement of work, data processing terms, security review, approval memorandum, and records identifying every organization authorized to access the information.

Define the website, technology, vendor, and date range. Avoid requesting every record related to website tracking. A precise request is easier to process and harder to reject as overly broad.

An agency may withhold legitimate security details. However, it may still be able to release vendor names, retention rules, privacy reviews, policy documents, and portions of relevant contracts.

Warning Signs That Require More Investigation

A government website deserves closer examination when it contacts an undisclosed commercial analytics provider, creates a persistent identifier without clear notice, or continues optional tracking after a visitor rejects it.

Other warning signs include detailed interaction recording on a sensitive service page, an outdated Privacy Impact Assessment, an unexplained change in website infrastructure, and a privacy policy that mentions only basic server logs while the website uses more detailed analytics.

A missing contract, absent disclosure, or unexpected domain does not prove unlawful activity. It establishes a specific question that the agency should answer.

Build a Defensible Evidence Record

The final audit file should include exact page addresses, dates, times, browser information, test conditions, screenshots, scanner reports, cookie tables, external domain tables, disclosure comparisons, archived policies, and government records.

Assign a simple identifier to every piece of evidence. Record who collected it and when. Preserve the original file separately from any redacted copy.

If you calculate a cryptographic hash for a file, record the algorithm and resulting value in the evidence log. This can help demonstrate that the file has not changed since collection.

Never publish session tokens, private account information, personal identifiers, or technical details that could create a genuine security risk. Accountability reporting should expose public data practices without exposing individual visitors or weakening the website.

Report Findings Responsibly

Lead with what you directly observed. Identify the page, date, request, cookie, domain, script, or disclosure. Explain how the test was conducted and describe its limitations.

Write that the website contacted a domain, placed a cookie, transmitted a parameter, or lacked a disclosure you could locate. Do not claim that officials created a surveillance program unless the evidence establishes collection, purpose, access, retention, and use.

Before publishing, send the agency a concise list of findings and questions. Ask what the technology collects, why it is used, how long the information is retained, who can access it, which contractors receive it, and which public privacy document covers it.

Include the agency response in context. If the agency does not respond, state that clearly without suggesting that silence proves wrongdoing.

Protect Yourself During the Investigation

Do not sign into a personal government account while conducting the test. Do not enter false information into an official form. Do not bypass authentication, evade access controls, flood a government server, exploit a vulnerability, or attempt to access private records.

Limit the investigation to information delivered to an ordinary website visitor and records legally available to the public.

If you discover an apparent security vulnerability, stop testing. Locate the agency’s vulnerability disclosure policy and follow its reporting instructions.

Why This Work Matters

Government websites can collect information before a visitor submits a form or knowingly shares personal details. A careful audit makes that invisible process more visible by combining privacy policies, browser observations, independent scans, procurement research, and public records.

The goal is not to label every analytics tool as malicious. The goal is to determine whether public agencies collect only what they need, explain the collection accurately, protect the information, and remain accountable to the people they serve.

When technical behavior and public disclosure do not match, a documented audit provides a foundation for public records requests, Inspector General complaints, legislative questions, independent reporting, and sustained public oversight.

Sources

  • The Guardian Investigation Into Federal Website Tracking
  • Blacklight Website Privacy Inspector
  • CalMatters Report on Blacklight
  • Webbkoll Privacy Inspection Tool
  • Electronic Privacy Information Center Privacy Impact Assessment Guide
  • Department of Justice E Government Act Guidance
  • Department of Justice Privacy Act Agency Requirements
  • Office of Management and Budget Web Measurement Guidance
  • National Archives Privacy Impact Assessments
  • Environmental Protection Agency Web Measurement Procedure
  • Mozilla Firefox Developer Tools
  • Federal Register
  • USAspending
  • SAM.gov
  • Internet Archive

Kitty’s Resistance Projects

  • Resistance Directory
  • EpsteinWiki
  • The Butterfly Bureau

Support Resistance Kitty’s Work

  • Merch & Mayhem
  • Buy Resistance Kitty a Treat

R – We Tread On Tyrants Light Style Unisex Long Sleeve Tee
Resistance Survival Guide Tags:browser network requests, digital accountability, federal website analytics, government contractors, government website tracking, Privacy Impact Assessment, public records investigation, tracking cookies, website privacy audit

Post navigation

Previous Post: Day 547 Another Epstein Associate Dies

Related Posts

  • #195 How to Build a Rapid Response Community Network Before a Crisis Hits Resistance Survival Guide
  • RSG #239: Emergency Communication When Everything Goes Quiet Resistance Survival Guide
  • #32 How to Break the Algorithm Before It Breaks You Resistance Survival Guide
  • #163 Digital & Community Organizing Under Pressure Resistance Survival Guide
  • RSG #26 How to Build a Guerrilla Supply Cache Resistance Survival Guide
  • #112 Defending Free Speech from Fascist Censorship Games Resistance Survival Guide

More Related Articles

#43 How to Build a Street Art Crew That Paints Over Propaganda and Sticks Like Hell Resistance Survival Guide
#125 Protecting LGBTQ+ Youth from “Conversion Therapy” Cruelty Resistance Survival Guide
#140 Creating a Voting Plan Resistance Survival Guide
How to Use Court Records to Investigate Public Officials Resistance Survival Guide
RSG #273: Emergency Financial Survival Systems During Political Crackdowns Resistance Survival Guide
#186 How to Stay Safe During ICE Encounters and Street Detentions Resistance Survival Guide

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

RSS FEED

Categories

  • Call to Action
  • Civic Mischief HQ
  • Executive Orders
  • Featured Resisters
  • Knives Out Activities
  • Resistance Kitty Comics
  • Resistance Survival Guide
  • Resistance Wins
Sign Up To Get Resistance Kitty in your inbox!

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.

Recent Posts

  • RSG #315: How To Audit Government Websites for Hidden Tracking
  • Day 547 Another Epstein Associate Dies
  • RSG #314: How To Investigate Hidden Changes In Federal Data Collection
  • Day 547 Resistance Update and Agenda
  • Day 546 Duck Hunt™

Recent Comments

  1. Dr. Harmony on RSG#199 Creating a Personal Legal Emergency Card
  2. Dr. Harmony on RSG#199 Creating a Personal Legal Emergency Card
  3. Monica on RSG#199 Creating a Personal Legal Emergency Card
  4. Monica on How to Prepare for War-Related Disruption Without Panicking
  5. Dr. Harmony on Request for Emergency Medical and Constitutional Review of Presidential Fitness

Copyright © 2026 Resistance Kitty.