US state privacy laws and Global Privacy Control: a guide for engineers

Global Privacy Control (GPC) is a browser signal, sent as the HTTP request header Sec-GPC: 1 and readable by scripts as navigator.globalPrivacyControl, that tells a website its visitor does not want their personal data sold or shared. Several US state privacy laws require the businesses they cover to treat a signal like this as a valid opt-out request, so for an engineering team GPC is a requirement with a header and a deadline, not a preference in a cookie banner.

I build and review web platforms for US teams from Mumbai, and the opt-out plumbing is where I most often find a gap between the privacy policy and what the code actually does. This guide covers which regulators say what about the signal, what honouring it means in code, and the request-handling machinery around it. It is engineering guidance from the regulators' own pages, not legal advice: which laws apply to your business, and what they require of it, are questions to confirm with your counsel.

Which states require honouring the signal?

Each state describes it in its own words: California's privacy agency speaks of an "opt-out preference signal", Colorado's Attorney General of a "universal opt-out mechanism". The three regulators below say plainly that a business they cover must honour one, and name GPC.

I've listed only the three regulators whose own pages I checked for this guide; other state laws may carry similar duties with their own dates, so don't read the table as complete. Each law also has its own applicability tests (revenue, the number of residents whose data you process, or the share of revenue from selling data), so the first question is which laws reach you at all. That list comes from your counsel; the engineering below works for all of them.

Colorado adds one documentation duty worth copying everywhere: its Attorney General's page notes that a business must explain in its privacy policy how it processes requests made through a universal opt-out mechanism, including GPC.

What is the signal, exactly?

The GPC specification is a W3C Working Draft (the version I read is dated 24 September 2026). The parts an engineer needs:

• The header. A browser with GPC turned on sends Sec-GPC: 1 on its requests. The value is exactly the character "1"; a server must ignore any other value. If a request somehow carries several Sec-GPC headers and at least one is exactly "1", the server treats the request as carrying the signal.
• The script property. navigator.globalPrivacyControl is true when the header would be sent and false otherwise. It exists on Navigator and WorkerNavigator, so service workers can read it too.
• The support resource. A site may publish /.well-known/gpc.json, a JSON object whose gpc member is true if the site intends to honour the signal at least where it is legally required to, with a lastUpdate date. It states awareness and intent; it does not prove what a given page does.

The header is the one to trust, because it arrives before any of your JavaScript runs.

What does honouring it mean in code?

Read the signal on the server, as early as you can, and make it part of the request's context:

// The Fetch API joins repeated headers with ", ", so check every value.
export function sendsGpc(headers: Headers): boolean {
  const raw = headers.get('sec-gpc') ?? ''
  return raw.split(',').some((value) => value.trim() === '1')
}

Then decide, before the page renders, what the opt-out switches off. In the US laws the signal is about selling or sharing personal data and, in Colorado and Connecticut, targeted advertising. In practice that usually means:

1. Third-party tags that sell or share. Advertising pixels, cross-site retargeting, data-broker scripts. Don't load them for a request with the signal, rather than loading them and asking them to behave. Server-side rendering makes this simple: the decision is made before the tag manager ever reaches the browser.
2. Server-side flows that sell or share. Conversion APIs, audience uploads and data feeds to partners need the same flag, because they never pass through the browser at all.
3. The record. Store that the signal was received and honoured: on the session, and on the account when the visitor is signed in, so the next server-side export respects it. Your counsel decides how far an opt-out must follow a known person across devices; the data model should make either answer easy.
4. The privacy policy. Say what the site does with the signal, in words that match the code.

Two edge cases come up every time. A signed-in user without the signal, who opted out earlier, stays opted out: the stored choice wins. And a site that can't tell where a visitor is should not assume they're outside every state that requires the signal; honouring it for everyone is usually simpler and cheaper than geolocating, which is a call for your counsel and your product team together.

Where does consent fit?

GPC is an opt-out signal. It sits beside consent, not in place of it. Some state laws require consent before certain processing: the Colorado Privacy Act before collecting and processing sensitive data, for example, and the Connecticut law before processing sensitive data too. That needs a recorded yes before the processing starts, whatever the browser sends. I build both on one small piece of plumbing:

• one server-side function that answers "may this request do X?", reading the signal, the stored choices and the consent records;
• every tag, export and job asks that function rather than reading cookies on its own;
• each consent stores its text, version and time, so you can show what someone agreed to.

That keeps the rules in one place, testable, and changeable when a new state's law takes effect.

How do you answer data-subject requests on time?

The rights to know, delete and correct come with deadlines. The California Privacy Protection Agency states them plainly: confirm receipt of a request to delete, correct or know within 10 business days and respond substantively within 45 calendar days, extendable by another 45 with notice; comply with a request to opt out of sale or sharing, or to limit the use of sensitive personal information, as soon as feasibly possible and within at most 15 business days. Other states set their own windows.

Deadlines like these are met by a pipeline, not by an inbox:

1. Intake through a form and an email address, each request getting an ID and a clock that starts on receipt.
2. Verification proportionate to the request: an opt-out needs none, deleting an account needs proof that the requester owns it.
3. A data map of every system and vendor that holds personal data, kept in the repository and updated with the code, so the request reaches every copy.
4. Fan-out to each system as a job (export, delete, correct), with the result recorded, including the vendors you must instruct.
5. A response generated from those results, and a log you can show a regulator.

Backups and logs need a written policy: what is deleted, what ages out, and how a restored backup is cleaned before it goes live.

A short checklist

• The server reads Sec-GPC on every request and puts the result in the request context.
• No sale-or-share tag loads for a request with the signal; server-side exports check the same flag.
• The opt-out is stored on the session and, when known, on the account.
• /.well-known/gpc.json says what the site does, with a date.
• The privacy policy describes how the signal is processed.
• Requests have IDs, clocks and a data map behind them; deletion reaches vendors and backups.
• An automated test sends Sec-GPC: 1 and asserts that no advertising tag appears in the page.

How I do this

A security audit of a US-facing product includes the privacy plumbing: I send the signal and watch what the page and the server actually do, read the data map against the code, and report the gaps with fixes. When I build the platform myself, under web platform development, the request context, the consent function and the request pipeline go in from the first sprint. The market page for the United States has the working hours, contracts and the other rules I design for there.