First-party vs third-party cookies (and why "first-party" still tracks you)

"We only use first-party cookies" shows up in a lot of privacy policies as though it settles the question of tracking. It doesn't. First-party and third-party describe where a cookie is set from, not who ends up with the data, and the gap between those two things is where a fair amount of current tracking lives.

The technical definition

A cookie is first-party if its domain matches the site in your browser's address bar. A cookie is third-party if its domain belongs to someone else — an ad network, an analytics vendor, a social widget — loaded as a resource on that page.

The distinction exists because browsers treat the two differently. Third-party cookies are sent along with requests to that third party's domain on every site that embeds it, which is what let ad networks build cross-site profiles for years: the same doubleclick.net cookie shows up whether you're reading a news site or shopping, letting the network connect the two visits to one browser. That's exactly the behavior Safari's Intelligent Tracking Prevention, Firefox's Enhanced Tracking Protection, and Chrome's phased-out third-party cookie support were all built to stop. A first-party cookie, by contrast, is only ever sent back to the site that set it, so it can't by itself be used to follow you across unrelated sites — which is why browsers don't block it by default, and why "first-party" gets used as a synonym for "not tracking" in marketing copy.

That reasoning is correct as far as it goes, but it only rules out cross-site tracking by that particular cookie. It says nothing about whether the site itself, or a vendor it hired, is building a profile of what you personally do on that one domain — which is still tracking, just not the cross-site kind the first/third-party split was designed to catch.

Why "first-party" often means "third-party, relabeled"

Several common techniques turn what looks like first-party analytics into something that behaves like a third party in every way that matters:

CNAME cloaking. A site can point a subdomain it controls, like metrics.example.com, at a third-party analytics vendor's infrastructure using a CNAME DNS record. The browser sees a request to example.com's own subdomain and treats any cookie it sets as first-party — bypassing third-party cookie blocking entirely — while the actual request is served, and the data collected, by the outside vendor the whole time. Several browser vendors and ad-blocking lists have added detection for known CNAME-cloaking setups precisely because it was being used to defeat tracking protection.

Server-side tagging. Instead of a visitor's browser talking directly to google-analytics.com or a similar vendor, the site can run its own server (often a thin proxy, e.g. Google Tag Manager's server-side container) that receives the tag call first, then forwards the data to the vendor from server to server. The cookie the visitor's browser deals with is set by the site's own domain — genuinely first-party by the technical definition — but the data still flows to the same third party. This is a legitimate technique with real, non-tracking-related benefits (adblocker resilience, performance), and it doesn't itself make the underlying purpose any less "third-party analytics"; it just changes which request carries the cookie.

_ga and Google Analytics. _ga is the cookie that best illustrates the gap. Google Analytics sets it, by default, as a first-party cookie under the site's own domain — it genuinely can't be read by other sites, and it isn't the classic cross-site tracking cookie the first/third-party split targets. But the data it enables — a persistent identifier tied to your visits, page views, time on site and (depending on configuration) demographic and interest signals — is still collected by and shared with Google, a third party in every ordinary sense of the word, and can still be linked with other data Google holds when a site owner enables Google Signals or similar features. Under GDPR and the ePrivacy Directive, what matters for consent is what the cookie does and who receives the data, not what domain it's parked under — see what counts as valid cookie consent.

Partitioned cookies: a newer, narrower fix

Chrome and some other browsers have introduced a Partitioned cookie attribute (sometimes called CHIPS, Cookies Having Independent Partitioned State) as a more targeted alternative to blocking third-party cookies outright. A partitioned cookie is still, technically, a third-party cookie — but the browser stores a separate copy of it for each top-level site that embeds it, so the same embedded widget can't use the cookie to recognize you across two different sites, even though it still works normally on any one of them. It's aimed at embeds with a legitimate, single-site reason to remember state (a chat widget, an embedded checkout) without also being usable to build a cross-site profile — the specific abuse that made browsers block third-party cookies in the first place. It doesn't change anything about first-party cookies like _ga, which were never blocked to begin with.

What this means when you're checking a site

When you're looking at a site's cookies yourself (see how to check what a site loads), "first-party" is a useful technical fact, but not a verdict. Ask instead:

• Who receives the data? Look at the requests in the Network tab, not just the cookie's domain. A first-party cookie next to a request to google-analytics.com or facebook.net tells you where the information is actually going.
• What company is behind the domain, even a first-party-looking one? The company directory lists the outside companies our scans have identified, including ones set up to look first-party.
• What category is it? Analytics and advertising cookies get flagged the same way in the cookie dictionary whether they happen to be first- or third-party — CookieTosser records a cookie's party as first, third, or both (many trackers, like _ga and _fbp, show up as both across different sites, depending on each site's setup).

First-party status changes how a browser treats a cookie automatically. It doesn't change whether loading it before you've consented needs your consent in the first place, or what category of tracker it is — see what the tracker categories mean for that part.