First-Party vs Third-Party Cookies
Chapter 3
First-Party vs Third-Party Cookies
Why the distinction exists, how cross-site tracking actually worked, and why every major browser is now restricting it
SameSite, from Chapter 2, exists specifically because of the distinction this chapter covers. Understanding first-party vs third-party cookies — and why they became a privacy problem serious enough that browsers rewrote their entire cookie-handling behaviour — is the direct setup for Chapter 4's explanation of bounce tracking and the real warning that prompted this course.
What Makes a Cookie "First-Party" or "Third-Party"
The distinction is simple: it's about whether the cookie belongs to the site shown in the address bar, or to some other domain whose content is embedded within that page.
First-Party Cookie
Set by the domain you're actually visiting. Visit
Universally considered legitimate and necessary; no browser restricts these.
osztromok.com, and a cookie set by osztromok.com itself — a login session, a theme preference — is first-party.
Universally considered legitimate and necessary; no browser restricts these.
Third-Party Cookie
Set by a different domain than the one in the address bar — typically an embedded resource: an ad network's tracking pixel, a "Like" button widget, an embedded video player, an analytics script.
This is the category browsers have spent years restricting.
This is the category browsers have spent years restricting.
How Cross-Site Tracking Actually Worked
ad-network.com sets the SAME third-party cookie on both sites — letting it recognise "this is the same visitor" across completely unrelated domains
Because the ad network's tracking pixel was embedded on both sites, and the same third-party cookie was sent with both embedded requests, the ad network could build a profile of which sites a specific browser visited — entirely invisible to the user, and without either news-site.com or shopping-site.com needing to cooperate or even know it was happening.
This was the original, "classic" cross-site tracking mechanism
Before SameSite restrictions and the broader privacy crackdown covered in this chapter, third-party cookies were the standard way ad networks tracked users across the web for behavioural advertising — visit a product on one site, see ads for it on a completely unrelated site days later. That experience is the direct, visible result of exactly this mechanism.
The Browser Response — A Timeline
2017
Safari introduces Intelligent Tracking Prevention (ITP) — the first major browser to actively restrict third-party cookie behaviour using heuristics to detect tracking-like patterns.
2019
Firefox enables Enhanced Tracking Protection by default, blocking known tracker domains using curated lists.
2020
Chrome makes SameSite=Lax the default for cookies with no explicit attribute (Chapter 2) — a deliberate step that quietly broke many third-party cookie use cases that hadn't set SameSite=None explicitly.
2024+
Chrome's long-announced plan to phase out third-party cookies entirely continues in stages, alongside newer, more aggressive heuristics like bounce-tracking detection (Chapter 4) catching tracking-like patterns that don't even rely on traditional third-party cookies at all.
How Browsers Decide What Counts as "Tracking-Like"
| Approach | How it works | Used by |
|---|---|---|
| Blocklists | A maintained list of known tracker domains; cookies/requests from listed domains are restricted automatically | Firefox (Enhanced Tracking Protection), many ad blockers |
| Heuristics | Behavioural pattern detection — no fixed list, instead watching for patterns that resemble tracking techniques (rapid redirects, storage access patterns) | Safari (ITP), increasingly Chrome |
| Default-deny + opt-in | Third-party cookies blocked unless a site explicitly requests access via a dedicated API, with user-visible permission prompts | The general direction all major browsers are converging toward |
Heuristic detection can produce false positives on entirely legitimate sites
Because heuristic approaches (Safari's ITP in particular) look for patterns rather than checking against a fixed list, a legitimate site doing something that incidentally resembles a tracking technique — certain redirect sequences, certain storage-access patterns — can get flagged and have its storage purged, even with zero actual tracking intent. This is exactly the situation Chapter 4 unpacks for the real warning that prompted this course.
What This Means for Building a Site Today
- Don't rely on third-party cookies for anything important. Increasingly inconsistent across browsers, and Chrome's continued phase-out makes them an unreliable foundation for new features.
- First-party cookies remain fully reliable. Nothing in this chapter's crackdown affects ordinary first-party login sessions, preferences, or any cookie set by the site the user is actually visiting.
- Be deliberate about embedded third-party content. Every embed (ad, widget, video player, analytics script) is a potential third-party cookie source — worth knowing what's actually embedded on your own site and why.
Chapter 3 Quick Reference
- First-party cookie — set by the site in the address bar; never restricted
- Third-party cookie — set by an embedded domain different from the address bar; the target of years of browser restrictions
- Classic tracking mechanism: the same embedded tracker on multiple sites recognises the same visitor across them via a shared third-party cookie
- Timeline: Safari ITP (2017) → Firefox ETP (2019) → Chrome SameSite=Lax default (2020) → ongoing third-party cookie phase-out and heuristic detection
- Blocklists vs heuristics: heuristics can produce false positives on legitimate sites — directly relevant to Chapter 4
- First-party cookies are unaffected by all of this — only cross-site/embedded cookie behaviour is restricted
- Next chapter: bounce tracking and Intelligent Tracking Prevention — the actual mechanism behind the real osztromok.com warning