Classifying trackers
Why it matters Every defence in this leg starts with a decision: is this site a tracker? Block an honest site and pages break; miss a tracker and you are followed. How a browser makes that decision explains both its strengths and the occasional broken page.
Think of three ways a bouncer could decide who gets into a club. One has a printed list of known troublemakers. One follows rules of thumb: "turned up at every club in town tonight, wearing a disguise". One has watched thousands of nights and learned a feel for it. Browsers use all three.
Classifier: anything that sorts items into groups, here "tracker" or "not a tracker". It can be a list, a set of rules, or a trained model.
1. Lists
People maintain lists of known tracking domains and filter rules. Ad blockers use community filter lists such as EasyList and EasyPrivacy, which you parsed a slice of in Leg 2. Firefox's built-in protection is based on lists maintained by Disconnect (checked October 2026). Lists usually include an entity map: which domains belong to one owner, so a company's own content site and its image server are not treated as third parties to each other.
Lists are precise and easy to explain ("blocked because it is on list X"). But they are only as fresh as their last update, and a tracker can dodge them with a new domain, or by hiding under the site's own name (CNAME cloaking, from Leg 1).
2. Heuristics
Heuristic: a rule of thumb that is usually right, such as "a third party seen on many unrelated sites, setting long random IDs, is probably tracking".
You wrote some in Leg 2: third party on many sites, high-entropy IDs (values too random to be settings), pixel-sized responses. The bounce rule from the last lesson is a heuristic too. Heuristics catch trackers nobody has listed yet, but they make two kinds of mistake, and every heuristic trades one against the other.
False positive: an honest site wrongly called a tracker (a page breaks). False negative: a tracker that slips through (you are followed).
For example, cdn.example serves a library to every shop. "On many sites" says tracker, but it sets no ID: a heuristic that ignores IDs would break all those shops.
3. Machine learning
A model can learn from features, such as how many top-level sites a domain appears under, how often it redirects, and whether you ever interact with it. WebKit has described Intelligent Tracking Prevention in Safari as using an on-device model of this kind (checked October 2026). Done on the device, your browsing statistics never leave it.
Models can weigh many weak signals together and adapt to new tricks. But they are harder to explain, can be wrong in surprising ways, and need careful limits on size and speed inside a browser. You will train a small one in pure Python in Leg 7.
Side by side
| Lists | Heuristics | Machine learning | |
|---|---|---|---|
| Catches new trackers | No, until listed | Often | Often |
| Explainable | Very | Fairly | Less |
| Typical mistakes | Out of date | False positives on shared services | Surprising errors |
| Dodged by | New domains, cloaking | Staying under the thresholds | Looking like ordinary sites |
Deciding, then acting
Classifying is only half of it. Engines also choose a response per class: block the request, allow it but strip or partition cookies, purge storage later, or only report it. A milder response for uncertain cases keeps breakage low. In practice most engines combine approaches: a list for confident blocking, heuristics for bounce and storage rules, and per-site exceptions when something breaks.
A common misconception
"A smarter classifier means no tracking." Every classifier has false negatives, and some tracking (first-party analytics, logins, fingerprinting) does not look like a separate tracker at all. That is why classification is paired with defences that work without it, such as partitioning.
Recap
- Lists are precise and explainable but miss new or cloaked trackers.
- Heuristics catch unlisted trackers but trade false positives against false negatives.
- Machine learning weighs many signals; WebKit has described Safari's ITP as using an on-device model (checked October 2026).
- Engines combine approaches and pick a milder response when unsure.
This lesson is locked
Lessons open one at a time. Finish the previous lesson to unlock this one.