How You're Tracked Online

A cookie is a small name=value the server asks your browser to store, then send back on later requests to that scope. The Set-Cookie response header is the ask. The Cookie request header is the reply. First-party cookies are scoped to the site you typed in the address bar (or its close relatives, depending on cookie rules). They often keep you logged in, remember a language, or hold a shopping cart. They are not automatically evil — a session cookie is how "stay signed in" works. The privacy question is who else gets a durable ID.

Third-party cookies are scoped to a different domain than the page you think you are visiting. A news article can embed a script or iframe from ads.example-network.com. That network sets its own cookie. When you later visit a shop that embeds the same network, the browser may send the same cookie. The news site and the shop never had to talk; the shared third party is the join key. Browsers have been partitioning or blocking third-party cookies, which is why trackers invested in other glues — pixels and fingerprints — rather than giving up cross-site identity.

A tracking pixel is usually a tiny image or a one-pixel request whose URL contains a unique token. Loading it is a GET to a logger: "this inbox opened this campaign" or "this page view belonged to this browser ID." Email pixels work because many clients fetch remote images by default. On the web, the same idea is a beacon or analytics POST. You do not "post" in the social sense. Your client just completed a request the page or message asked it to make. Blocking remote content in mail and using tracker-blocking in the browser cuts a large class of these callbacks — on your client, for your traffic.

A browser fingerprint is a bundle of attributes that are stable enough, in combination, to re-identify a client without a stored cookie. Canvas rendering differs slightly by GPU and font rasterization; the site draws hidden graphics and hashes the pixels. Installed fonts, timezone, language, screen size, platform, and a handful of API quirks add entropy. No single field is a name. Together they can be rare. When you clear cookies, the cookie ID is gone — the fingerprint may still match yesterday's record. That is why "I deleted cookies, so I am a new person" fails as a privacy model.

Incognito / private windows give you a fresh cookie jar and usually skip writing history to disk. They do not give you a new IP as far as the site is concerned (your ISP still NATs you the same way). They do not reset canvas and timezone. They do not hide you if you then log into an account — the account ID re-links the session. They are a shared-computer hygiene tool (less leftover login on a library PC), not a cloak. Treating private mode as anonymity is the most common tracking misconception in this module.

Use the browser you actually browse with. Paths differ (Chrome/Edge: Settings → Privacy → Cookies and site data, or lock icon → Cookies; Firefox: Settings → Privacy & Security; Safari: Settings → Privacy). You are reading, not attacking. The optional curl command talks to the public example.com host — a documentation domain — from a computer you own. Do not point scanners at employers, schools, or strangers.

curl -I https://example.com

You now know why tracking works: cookies re-attach a stateless protocol, third parties join sites, pixels are just requests with IDs, and fingerprints remain when the jar is empty. Incognito is a fresh jar, not a new person. Next — Reducing Your Footprint — you practice shrinking what is already public and slowing how much new glue you accept, without pretending you must go off-grid.