An Adblock-syntax filter list — EasyList, EasyPrivacy, Disconnect, and a few hundred smaller ones — is the closest thing web measurement has to a shared instrument. It is free, comparable across papers, and reviewable rule by rule, which is why 198 papers in this corpus used or produced one and why almost every claim about advertising or tracking on the web ultimately rests on one.

It is also a moving, crowd-maintained, anglophone artefact with a known and large error rate in both directions, and the field uses it simultaneously as the instrument that produces a measurement and as the ground truth that the measurement is scored against. That circularity is this page's subject.

This page is about the list itself: what it is, which ones exist, how to record which one you used, how to apply it, where its coverage runs out, and how to say something defensible when your labels came from it. What to do with the requests once they are labelled is on Classifying web requests; that page carries the ML lineage, the request-unit ladder and the link-decoration material, and this page carries the list.

• Who Filters the Filters? [2Snyder, Peter; Vastel, Antoine; Livshits, Ben (2020): "Who Filters the Filters: Understanding the Growth, Usefulness and Efficiency of Crowdsourced Ad Blocking", Proc. ACM Meas. Anal. Comput. Syst. 4(2). (DOI) (Link)] — the measurement of how much of EasyList is dead weight: 90.16% of its resource-blocking rules provided no benefit in common browsing. Published at SIGMETRICS, outside this corpus's seven venues, and still the reference for “the list grows and never shrinks”.
• Missed by Filter Lists [3Fouad, Imane; Bielova, Nataliia; Legout, Arnaud; Sarafijanovic-Djukic, Natasa (2020): "Missed by Filter Lists: Detecting Unknown Third-Party Trackers with Invisible Pixels", in: Proceedings on Privacy Enhancing Technologies, pp. 499-518. (DOI)] — the reference for what a list does not catch, measured behaviourally rather than against another list.
• From Syntactic Matching to Taint Tracking and Back [1Calzavara, Stefano; Casarin, Samuele; Squarcina, Marco; Maffei, Matteo (2026): "From Syntactic Matching to Taint Tracking and Back: A Comparative Study of Web Tracking Detection Techniques", in: Proceedings on Privacy Enhancing Technologies. (Link)], PoPETs 2026 — the only head-to-head evaluation of list matching against an independent detector, and the source of the false-positive estimate above. One study, one taint-tracking browser, 7,614 sites: read it as the best available number, not as a settled one.
• Understanding Regional Filter Lists [4Böttger, Christian; Demir, Nurullah; Hörnemann, Jan; Acharya, Bhupendra; Pohlmann, Norbert; Holz, Thorsten; Grosse-Kampmann, Matteo; Urban, Tobias (2025): "Understanding Regional Filter Lists: Efficacy and Impact", in: Proceedings on Privacy Enhancing Technologies, pp. 309-325. (DOI)], PoPETs 2025 — the only systematic study of what the non-anglophone lists add, and the reason the section below exists.
• Blocking Tracking JavaScript at the Function Granularity [5Amjad, Abdul Haddi; Munir, Shaoor; Shafiq, Zubair; Gulzar, Muhammad Ali (2024): "Blocking Tracking JavaScript at the Function Granularity", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], CCS 2024 — read §4.4 specifically. It states the precision assumption the whole field runs on (“a network request labeled as tracking by filter lists is actually tracking — as experts vet each rule”) and then, in its evaluation, gets list authors to confirm on GitHub that some tracking scripts are deliberately not blocked because blocking them breaks pages. Absence from a list is sometimes a policy decision, not an oversight — which is the deepest reason “not on the list” cannot mean “not a tracker”.

Three properties decide whether a list can answer your question at all. None of them is about syntax; the syntax is documented by the list maintainers and there is no reason to restate it here.

Rules split into network rules (stop the request), cosmetic rules (hide an element that already loaded, expressed as a CSS-superset selector) and exception rules (@@, un-block something a network rule would have caught). Only network rules can answer “would this request have been blocked”, and the split is not what people assume.

Measured live on 2026-08-29 by the script in Recording Which List You Used (its unedited output is in that section):

Exception rules are the part people silently drop. EasyList carries 758 and EasyPrivacy 836. An engine that evaluates them and a script that greps for rule strings will not agree, and the grep will over-count blocks with no error message.

$third-party, $domain=, the resource-type options ($script, $image, $xmlhttprequest, $sub_frame, …) and @@ exceptions all depend on where the request came from and what kind of thing it is. Brave's engine says so in its own constructor signature — Request::new(url, source_url, request_type, method).¹⁾

So a crawl that logged only request URLs cannot be post-processed with a list, and it will fail silently rather than error. Record, per request:

• the request URL;
• the initiator or document URL of the frame that issued it — without this every $third-party and $domain= modifier evaluates against nothing;
• the resource type, which CDP and Playwright both expose (resourceType());
• the redirect chain, because a rule may match a hop you did not keep;
• and then actually evaluate the exception rules.

The crawler page compares which libraries expose each of these. Cosmetic filters are a separate matter: modern cosmetic syntax is a superset of CSS — procedural filters such as `:has-text()`, and HTML filtering (##^) — so do not try to evaluate them with your automation library's selector engine. Use the cosmetic API of the Ghostery or Brave engine to resolve selectors for a hostname first, then query with those.

EasyList publishes both a Version: and the exact Commit: that produced the file, and it changes several times an hour. Two fetches of the same URL on 2026-08-29, three minutes apart, returned two different builds:

Note the order. The later fetch returned the older build: easylist.to is behind a CDN and two requests minutes apart are not guaranteed to agree, let alone two requests days apart. This is why recording the Version: and Commit: is necessary but archiving the bytes is what actually makes you reproducible.

Seventeen days earlier the same list carried 52,557 network rules — +4.1% in 17 days.²⁾ “We used EasyList” identifies nothing.

Status checked 2026-08-29 against the primary source in each row — the list's own canonical URL, or the GitHub API for repository state. Nothing here comes from a vendor blog or a listicle. Filter lists die quietly, and a dead list in a live crawl is a silent measurement error, so re-run external_checks_filter_lists.sh (on the provenance page, with its unedited output) rather than trusting this table's date.

Two papers in the whole 5,859-paper corpus are about regional lists. That is the finding: this is a systematically under-studied dependency of a very large literature.

• Sjösten et al. [7Sjösten, Alexander; Snyder, Peter; Pastor, Antonio; Papadopoulos, Panagiotis; Livshits, Benjamin (2020): "Filter List Generation for Underserved Regions", in: Proceedings of the ACM Web Conference. (DOI)], TheWebConf 2020, generated rules automatically for three under-served regions and produced 1,310 new rules identifying 1,771 advertising URLs missed by existing lists, blocking 27.1% more advertising resources than the existing lists alone.
• Böttger et al. [4Böttger, Christian; Demir, Nurullah; Hörnemann, Jan; Acharya, Bhupendra; Pohlmann, Norbert; Holz, Thorsten; Grosse-Kampmann, Matteo; Urban, Tobias (2025): "Understanding Regional Filter Lists: Efficacy and Impact", in: Proceedings on Privacy Enhancing Technologies, pp. 309-325. (DOI)], PoPETs 2025, is the efficacy study. Across their crawl profiles, of 122,548 distinct rules in the regional lists they tested, only 8,163 (6.6%) identified at least one tracking request — the Snyder result, reproduced on regional lists five years later. A “master list” rebuilt from just those 8,163 rules identified 9,650,332 (83%) more trackers than their baseline list.⁵⁾

The regional lists are real, maintained, and roughly the size you would want. Measured 2026-08-29 with the same script as above:

Note that EasyList China carries more than five times EasyList Germany's network rules; these are not interchangeable increments on a common base, and there is no reason to expect them to behave alike. The full index is at easylist.to (HTTP 200, 2026-08-29).

What to do about it. If your crawl visits sites in languages other than English, load the matching regional lists, say which, and report your results both with and without them. If you cannot, say that the anglophone lists are your instrument and treat non-English results as a lower bound — that is an honest limitation and reviewers accept it. What is not defensible is a per-country tracking comparison built on EasyList alone, because the instrument's sensitivity varies with the thing being compared.

The four that got it right, and the form to copy:

A version is not enough on its own — archive the bytes. A Version: string is only resolvable while the maintainers keep the history; the .txt you actually matched against is the artefact. Run this at the start of the crawl, not when you write the paper, and put the JSON and the raw lists in your artefact.

filterlist_provenance.py

#!/usr/bin/env python3
"""Record exactly which filter list you used, so your crawl is reproducible.
 
Filter lists change several times a day. "We used EasyList" is not a method;
"EasyList, Version 202608291151, commit 3a4485aa, 54,722 network rules" is. Every
Adblock-Plus-syntax list carries that metadata in its own header comments --
this script extracts it, counts the rules by kind, and writes a JSON record you
can archive next to your crawl data and paste into your methodology section.
 
Run it at the START of a crawl, not when you write the paper.
 
    python3 filterlist_provenance.py > filterlists.json
    python3 filterlist_provenance.py --save lists/   # also archive the raw .txt
"""
 
import argparse
import hashlib
import json
import pathlib
import re
import sys
import urllib.request
from datetime import datetime, timezone
 
# The lists a tracking measurement usually wants. The anglophone core is the
# first block; if your crawl visits sites in any other language, the second
# block is not optional -- see the regional-lists section of the page.
LISTS = {
    "easylist": "https://easylist.to/easylist/easylist.txt",
    "easyprivacy": "https://easylist.to/easylist/easyprivacy.txt",
    "easylist-cookie": "https://secure.fanboy.co.nz/fanboy-cookiemonster.txt",
    "adguard-url-tracking": "https://filters.adtidy.org/windows/filters/17.txt",
    "peter-lowe": "https://pgl.yoyo.org/adservers/serverlist.php"
    "?hostformat=adblockplus&showintro=0&mimetype=plaintext",
    # Regional. Add the ones your population needs and delete the rest; the
    # full index is at easylist.to/pages/other-supplementary-filter-lists-and-
    # easylist-variants.html
    "easylist-china": "https://easylist-downloads.adblockplus.org/easylistchina.txt",
    "easylist-germany": "https://easylist.to/easylistgermany/easylistgermany.txt",
    "liste-fr": "https://easylist-downloads.adblockplus.org/liste_fr.txt",
}
 
# Header fields Adblock-syntax lists publish about themselves. Not every list
# sets every field; a missing field is reported as None rather than guessed.
HEADER_FIELDS = ("Version", "Last modified", "TimeUpdated", "Expires", "Commit", "Title")
 
# A cosmetic rule hides an element that has already loaded; a network rule stops
# the request. Only network rules answer "would this request have been blocked".
# Note the order in classify(): a cosmetic *exception* (`site.com#@#.ad`) is
# counted as cosmetic, not as an exception, because the question this count
# answers is "how much of this list is about requests at all".
COSMETIC = re.compile(r"#[@?$]?#|#\$#")
 
 
def classify(line):
    if not line.strip() or line.startswith("!") or line.startswith("["):
        return "comment"
    if COSMETIC.search(line):
        return "cosmetic"
    if line.startswith("@@"):
        return "exception"
    return "network"
 
 
def describe(name, url):
    req = urllib.request.Request(url, headers={"User-Agent": "filterlist-provenance/1.0"})
    with urllib.request.urlopen(req, timeout=60) as resp:
        raw = resp.read()
    text = raw.decode("utf-8", errors="replace")
    lines = text.split("\n")
 
    header = {}
    for field in HEADER_FIELDS:
        m = re.search(rf"^!\s*{re.escape(field)}:\s*(.+)$", text[:8000], re.M)
        header[field] = m.group(1).strip() if m else None
 
    counts = {"comment": 0, "cosmetic": 0, "exception": 0, "network": 0}
    for line in lines:
        counts[classify(line)] += 1
 
    return {
        "name": name,
        "url": url,
        "fetched_at": datetime.now(timezone.utc).isoformat(timespec="seconds"),
        "sha256": hashlib.sha256(raw).hexdigest(),
        "bytes": len(raw),
        "header": header,
        "rules": counts,
    }, raw
 
 
def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--save", metavar="DIR", help="also write the raw list files here")
    args = ap.parse_args()
 
    out = []
    for name, url in LISTS.items():
        try:
            record, raw = describe(name, url)
        except Exception as exc:
            # Fail loud: a list you could not fetch is a hole in your method,
            # not something to paper over with a stale local copy.
            print(f"FAILED {name} <{url}>: {exc}", file=sys.stderr)
            raise
        out.append(record)
        if args.save:
            d = pathlib.Path(args.save)
            d.mkdir(parents=True, exist_ok=True)
            (d / f"{name}.txt").write_bytes(raw)
        # Not every list sets `Version:`; EasyList Cookie List and Peter Lowe's
        # list only set `Last modified:`. Report whichever exists, and say so.
        stamp = (
            record["header"]["Version"]
            or record["header"]["TimeUpdated"]
            or record["header"]["Last modified"]
            or "(no version or date in header)"
        )
        print(
            f"{name:22} {stamp:24}"
            f" network={record['rules']['network']:7} cosmetic={record['rules']['cosmetic']:7}"
            f" exception={record['rules']['exception']:6} sha256={record['sha256'][:12]}",
            file=sys.stderr,
        )
    json.dump(out, sys.stdout, indent=2)
    print(file=sys.stdout)
 
 
if __name__ == "__main__":
    main()

Real output, 2026-08-29 (this is the run every rule count on this page comes from):

easylist               202608291151             network=  54722 cosmetic=  24512 exception=   758 sha256=6c8ceac99fab
easyprivacy            202608291151             network=  55099 cosmetic=     33 exception=   836 sha256=b1812eb0ad01
easylist-cookie        2026-08-28 00:50 UTC     network=   1674 cosmetic=  23057 exception=   428 sha256=2c39a370892c
adguard-url-tracking   2.0.14.1                 network=   2520 cosmetic=      2 exception=    91 sha256=7578d8eb0e3e
peter-lowe             Sat, 29 Aug 2026 10:08:46 GMT network=   3528 cosmetic=      0 exception=     0 sha256=28ca97374e62
easylist-china         202608291151             network=  11377 cosmetic=   6935 exception=   986 sha256=e5be0ec4ef4b
easylist-germany       202608271302             network=   2149 cosmetic=   3650 exception=   164 sha256=1528a89f4222
liste-fr               202608291151             network=   9892 cosmetic=   3545 exception=   157 sha256=bacd552ed794

Run the crawl allowing everything, then classify. You can re-classify with a different list, or a different version of the same list, without re-crawling — which you cannot do if you blocked at request time. You also avoid changing the page you are measuring: a blocked resource changes what the page loads next, so a blocking crawl and an allowing crawl are not measuring the same web.

Engine maintenance status checked 2026-08-29 against the npm, PyPI and crates.io registries and the GitHub API. This is the section of the page that rots fastest.

“Install a blocker and see what it blocks” is now constrained by a documented rule budget rather than by engineering. Chrome's declarativeNetRequest limits, from the API reference read on 2026-08-29:⁸⁾

• GUARANTEED_MINIMUM_STATIC_RULES = 30,000 rules across the enabled static rulesets (MAX_NUMBER_OF_ENABLED_STATIC_RULESETS = 50);
• MAX_NUMBER_OF_REGEX_RULES = 1,000 regular-expression rules of each type, each under 2 KB once compiled. The documentation's own words: “the total number of regular expression rules of each type cannot exceed 1000”.

EasyList alone is 54,722 network rules and EasyPrivacy 55,099. Neither fits in the 30,000-rule static guarantee, let alone both, so an MV3 extension ships a subset chosen by its authors — which is what uBlock Origin Lite is, and why it is not feature-equivalent to uBlock Origin.⁹⁾

Firefox has its own caps and they are not Chrome's. MDN documents the same constant names but records the dynamic and session limits changing at Chrome 120 and Firefox 128 independently, so the values are per-browser and per-version.¹⁰⁾ If your measurement compares blockers across browsers, read the constants at runtime and report them — the rule budget is a confound, not a constant.

Lukić and Papadopoulos [11Lukić, Karlo; Papadopoulos, Lazaros (2026): "Privacy vs. Profit: The Impact of Google's Manifest Version 3 (MV3) Update on Ad Blocker Effectiveness", in: Proceedings on Privacy Enhancing Technologies. (Link)] measured whether this degrades blocking and found no significant reduction in ad blocking and a significant increase in anti-tracking between MV2 and MV3 builds of four popular blockers, though MV3 left cosmetic placeholders in 21% of cases where MV2 left none. The blocking survived; whether an MV3 extension is a sound measurement instrument is a different question and it is not settled. If your method depends on the extension seeing every request, post-process a full crawl with the Rust or Node engine instead, where no rule cap applies.

You will be asked this in review, so have the numbers. Two things are being measured here and they are not the same: false negatives (the list does not know about a tracker) and bypasses (the rule exists and matches, and the request happens anyway).

The list is an anglophone desktop-web instrument. Every step away from that costs recall, and the cost has been measured:

Nothing in this table is a criticism of the lists. They are maintained for browsing, by volunteers, on the web people browse. It is a statement about the instrument's sensitivity: if you point it anywhere other than the anglophone desktop web, report your recall or state that you did not measure it.

• Local frames [22Ukani, Alisha; Haddadi, Hamed; Snoeren, Alex C.; Snyder, Peter (2025): "Local Frames: Exploiting Inherited Origins to Bypass Content Blockers", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, pp. 1349-1363. (DOI)], CCS 2025: on the 12,234 of 21,965 crawled sites that use local frames (about:blank, srcdoc, blob), 73.7% of the URLs those frames requested should have been blocked by EasyList + EasyPrivacy + uBlock Origin lists and were not, because content blockers mishandle inherited origins. Nineteen distinct vulnerabilities across the blockers tested. If you post-process request logs with an engine you will count these as blocked; a live blocking crawl will not.
• CNAME cloaking [6Dimova, Yana; Acar, Gunes; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (2021): "The CNAME of the game: Large-scale analysis of DNS-based tracking evasion", Proceedings on Privacy Enhancing Technologies 2021:394–412. (DOI) (Link)]: a tracker reached through a first-party CNAME defeats hostname matching entirely. The AdGuard CNAME list exists for this and needs your crawl to have recorded DNS resolution.
• Deliberate non-blocking. NoT.js [5Amjad, Abdul Haddi; Munir, Shaoor; Shafiq, Zubair; Gulzar, Muhammad Ali (2024): "Blocking Tracking JavaScript at the Function Granularity", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] reported ten tracking scripts from a sample of fifty to the list authors, who confirmed via GitHub issues that these mixed scripts are knowingly not blocked, because blocking them breaks pages. “Not on the list” can mean “on the list's do-not-break register”.

AdFlush [14Lee, Kiho; Lim, Chaejin; Jin, Beomjin; Kim, Taeyoung; Kim, Hyoungshick (2024): "AdFlush: A Real-World Deployable Machine Learning Solution for Effective Advertisement and Web Tracker Prevention", in: Proceedings of the ACM Web Conference. (DOI)] and the filter lists it was compared against flagged almost exactly the same volume of traffic — 39.27% versus 39.92% of all requests — and the paper reads that as evidence AdFlush “can effectively serve as a substitute for filter lists”. The same paper reports 642 ads and trackers on 108 domains that the lists had missed. Both are true, and together they are the point: equal marginals are not equal sets. If you compare a classifier against a list, report the confusion matrix, not the two totals.

The practice is not confined to request classifiers. 88 papers in this corpus name a filter list as the groundTruthSource for a classification step, across twelve different kinds of object — requests, domains, cookies, scripts, IP addresses, website categories, privacy policies, consent notices, network traffic, even email messages. The list has become the field's general-purpose definition of “advertising or tracking”, far outside what it was written to describe.

The clearest recent examples, each verified against the paper's own text:

• CookieGraph [23Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)], CCS 2023 labels a cookie by the provenance of the script that set it: “if a script that sets a cookie is not marked by any of the filter lists, we label these cookies Non-ATS … if any one of the filter lists marks the cookie's setter as ATS, we label the cookie as Unknown”. It then adds Cookiepedia as a second, independent label source, and treats its self-declared purposes conservatively. That combination — filter-list provenance plus a CMP-maintained label database — is the current state of the art for cookie labelling, and it is a real improvement on scoring the list against itself.
• NoT.js [5Amjad, Abdul Haddi; Munir, Shaoor; Shafiq, Zubair; Gulzar, Muhammad Ali (2024): "Blocking Tracking JavaScript at the Function Granularity", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], CCS 2024 labels a JavaScript function by whether the network requests it participates in match EasyList/EasyPrivacy, calling the result “a conservative ground truth” in which mixed-behaviour functions (3.9% of it) are labelled non-tracking.
• SugarCoat [24Smith, Michael; Snyder, Peter; Livshits, Benjamin; Stefan, Deian (2021): "SugarCoat: Programmatically Generating Privacy-Preserving, Web-Compatible Resource Replacements for Content Blocking", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], CCS 2021 takes both the tracking labels and the breakage signal from list artefacts — rules and exception rules.
• Read Between the Lines [25Ghasemisharif, Mohammad; Polakis, Jason (2023): "Read Between the Lines: Detecting Tracking JavaScript with Bytecode Classification", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], CCS 2023 classifies tracking JavaScript from bytecode, with EasyList, EasyPrivacy and Fanboy's Enhanced Tracking as the labels.

The whole learned-classifier roster in this corpus whose stated ground truth is a filter list — eleven papers, and it reads as a who's-who of the reference baselines — is printed in full on the provenance page.

Nobody has escaped the list entirely, but four routes exist, in rising order of effort:

1. Hand-label a sample and report precision against the list. A few hundred requests is an afternoon. 34 of the 167 list-using classification papers (20.4%) did this, and 119 (71.3%) report no validation at all; it is the single cheapest improvement available and reviewers notice its absence.
2. Add an independent label source. Cookiepedia for cookies [23Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)], a CMP declaration, an entity map. Disagreements between two imperfect sources are informative in a way agreement with one is not.
3. Use a behavioural or differential detector as the reference, not as the thing being scored: invisible pixels [3Fouad, Imane; Bielova, Nataliia; Legout, Arnaud; Sarafijanovic-Djukic, Natasa (2020): "Missed by Filter Lists: Detecting Unknown Third-Party Trackers with Invisible Pixels", in: Proceedings on Privacy Enhancing Technologies, pp. 499-518. (DOI)], breakage-differential testing [15Shuang, He; Zhao, Lianying; Lie, David (2025): "Duumviri: Detecting Trackers and Mixed Trackers with a Breakage Detector", in: Proceedings of the Network and Distributed System Security Symposium. (Link)], dynamic taint tracking [1Calzavara, Stefano; Casarin, Samuele; Squarcina, Marco; Maffei, Matteo (2026): "From Syntactic Matching to Taint Tracking and Back: A Comparative Study of Web Tracking Detection Techniques", in: Proceedings on Privacy Enhancing Technologies. (Link)]. Each has been done roughly once.
4. Report the confusion matrix and inspect the disagreements by hand. Lee et al. [13Lee, Dongkeun; Joo, Minwoo; Lee, Wonjun (2023): "Net-track: Generic Web Tracking Detection Using Packet Metadata", in: Proceedings of the ACM Web Conference. (DOI)] did exactly this and found 34.5% of their apparent errors were the list's, not theirs. That is a result you get for free by not assuming.

Everything in this section comes from a structured extraction over 5,859 full-text papers from CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026, one record per paper with a verbatim evidence quote per claim. The 2025 and 2026 venue-years are provisional — CCS and IMC 2026 have not been held, and IEEE S&P and WWW 2026 are incompletely selected — so any per-year row reaching them is under-represented by construction. Methodology and limits are at the end of this section.

A paper is in the population if it used or produced something that folds to a filter-list family. Engines (adblockparser, adblock-rust), heuristics that are not lists (Privacy Badger) and off-topic blocklists (spam, malware, IP reputation, censorship, certificate revocation) are excluded by name and counted separately.

“Mentioned” is not “used”. The 18 excluded papers are 8.4% of what a raw name search would score as adoption, and the compared ones are the dangerous rows: a paper that beats EasyList did not adopt it.

Of the 198 papers that used or produced a filter list. A paper naming several is counted under each, so shares do not sum to 100%. Names are free text and were folded into families; spellings is how many distinct strings the corpus uses, and unfolded is what the single most common exact string alone would have found.

Folding is not cosmetic. Counting exact strings would find 92 EasyList papers instead of 112 (−17.9%), 26 Disconnect papers instead of 48 (−45.8%, because Disconnect appears as Disconnect list, Disconnect.me, Disconnect blacklist, Disconnect Entity List and twenty more), and 3 hosts-file papers instead of 27. Any adoption table built on exact strings is wrong by tens of percent.

Of the 167 papers with at least one list-backed classification step. This is the finding that motivated this page: the filter list is not a request classifier, it is the field's general-purpose “is this advertising or tracking” oracle, and it is applied to objects it was never written to describe.

Grouped by what that does to the instrument:

These are not a partition and the shares exceed 100%: 17 of the 167 papers apply a list at more than one granularity — typically requests and domains in the same study.

Nearly a third of the field throws away the list's granularity before using it. That is often deliberate and sometimes unavoidable — a DNS blocklist or a passive traffic capture gives you nothing finer than a hostname — but it changes what the label means, and it is rarely stated. The per-paper roster behind every non-request row is on the provenance page so you can check the claim.

Validation of the list-backed classification steps, over the 167 papers. Sentinels are printed as themselves and never counted as an answer:

The rows overlap — 11 papers carry both a sentinel and a real value, so the two sentinel rows must not be added. The paper-level figure is: 119 of 167 (71.3%) report nothing but sentinels, and 48 (28.7%) report at least one real validation.

The not-applicable row is mostly papers that applied a list as-is and reasonably consider the list itself the definition. That is exactly the assumption Calzavara et al. measured at 16%–19% false positives.

Read the 29.8% as an order of magnitude in both directions: the extraction fills the version field when the paper puts a version next to the name, so a paper that dates its lists in a crawl paragraph may not be credited — and several of the 53 give an extension version (Ghostery 5.4.1, Adblock Plus 3.7) rather than a list version, which does not identify the rules at all. The 2.2% is the figure that matters and it is not an artefact: a list Version: string is unmistakable, and only four papers have one.

Filter-list use peaked in 2018–2021 and has been flat since, at roughly 3–4% of these seven venues. Nothing in the corpus supports “the field has moved on from filter lists”: machine learning was added alongside, not instead. Among the population, papers carrying any LLM-based classification step appear only in 2024 (2), 2025 (4) and 2026 (1) — real, new, and far too thin to call current practice on the strength of the corpus's most provisional years.

• How they were produced. One structured record per paper extracted from full text, each tuple carrying a verbatim evidence quote and its section. Every number in this section comes from report_filter_lists.mjs; the list-name fold is req_fold.mjs, shared with Requests so the two pages cannot disagree about what “EasyList” means, and the granularity and regional folds are fl_fold.mjs. Every query, the scripts' unedited output, the full fold residue and the per-paper rosters are on the provenance page; corpus-level caveats are on corpus.
• The population is a judgement, not an enum. No field in the extraction means “used a filter list”. The membership rule is a regular expression plus a hand-written family table, and both are printed in full on the provenance page so you can disagree with them.
• A paper counts once, never once per tuple, and shares do not sum to 100% because the fields are multi-valued.
• Sentinels are counted as what they are. not-applicable and none-reported are never folded into a stated value; where they are the largest rows, that is the finding.
• Free-text names were folded, and the residue is printed rather than dropped: 34 distinct strings matched the candidate regex but no family, and almost all are generic off-topic phrases (12 IP reputation blacklists, combined public blacklists). Off-topic blocklist families were excluded by name and counted: malware/phishing 10 papers, spam 8, IP reputation 7, content-category 6, censorship 3, certificate revocation 2.
• Free-text fields are ~20% stable run-to-run. List names are given as folded families and rankings; the enum fields (classification.target, classification.validation) are considerably more stable and are given as percentages.
• Venue coverage. Seven venues only. EuroS&P, ACSAC, RAID, AsiaCCS, WPES, CHI and SOUPS are absent, and several works this page relies on were published outside them — Snyder et al. at SIGMETRICS in particular. Any count here is a lower bound.
• Overlap with Requests. That page computes a partly overlapping population (its “S1” signal) and reports 197 papers where this page reports 198, with per-list counts differing by one or two. The two scripts define membership slightly differently — this page counts a list named anywhere in tools[] or classification[], that page additionally intersects with its request-classification task fold. Neither is wrong; the difference is a live example of why a population definition belongs in the provenance, not in a sentence.

1. The list, its version and its commit. EasyList Version 202608291151, commit 3a4485aa — not “EasyList”. Archive the .txt with your artefact. 70% of papers give nothing; 98% give nothing that identifies the rules.
2. The engine and its version, separately from the list. adblock 0.13.3 and adblockparser 0.7 do not match the same rules, and the second silently ignores options it does not know.
3. Which rule kinds you evaluated. Network only, or cosmetic too? Did you evaluate exception rules? Nearly a third of EasyList is cosmetic and answers a different question.
4. The unit you applied it at, and if it is coarser than a request URL, say what that discards.
5. Your regional lists, or the explicit statement that you used the anglophone core and that non-English results are a lower bound.
6. Validation on your own sample. Hand-label a few hundred and report precision against the list. Four papers in five do not.
7. If a list supplied your labels: the label noise. “Filter lists” is an answer with a published error rate now [1Calzavara, Stefano; Casarin, Samuele; Squarcina, Marco; Maffei, Matteo (2026): "From Syntactic Matching to Taint Tracking and Back: A Comparative Study of Web Tracking Detection Techniques", in: Proceedings on Privacy Enhancing Technologies. (Link)] — quote it, and report the confusion matrix rather than two totals.
8. Whether you blocked at crawl time or post-processed, because a blocking crawl changes the page it measures.

• Classifying web requests — what to do with the labels: the request-unit ladder, the ML lineage (AdGraph, WebGraph, Khaleesi, AdFlush), link decoration and cookie-notice detection.
• Comparison of crawling libraries — which of them record the initiator chain, resource type and redirect chain a rule needs.
• Tracker Radar Collector — the crawler behind the Tracker Radar dataset, which is a list of a different kind.
• webXray and domain-to-company ownership — once a request is flagged, whose is it, and why the entity maps disagree.
• Analysing and classifying JavaScript — the script- and function-level end, where list labels are propagated through call stacks.
• Classifying cookies — where the “a cookie set by a blocked resource is an advertising cookie” method belongs.
• Granting consent to websites — the cookie-notice lists (EasyList Cookie List, autoconsent, Consent-O-Matic) in their own context.
• Website classification — DNS and category blocklists, and the measured reason not to use a categorisation service to find trackers.
• Provenance of this page's figures — every query, the raw script output, the folds and their residue, the external checks and what was rejected.

[1]

Calzavara, Stefano; Casarin, Samuele; Squarcina, Marco; Maffei, Matteo (2026): "From Syntactic Matching to Taint Tracking and Back: A Comparative Study of Web Tracking Detection Techniques", in: Proceedings on Privacy Enhancing Technologies. (Link)

[2]

Snyder, Peter; Vastel, Antoine; Livshits, Ben (2020): "Who Filters the Filters: Understanding the Growth, Usefulness and Efficiency of Crowdsourced Ad Blocking", Proc. ACM Meas. Anal. Comput. Syst. 4(2). (DOI) (Link)

[3]

Fouad, Imane; Bielova, Nataliia; Legout, Arnaud; Sarafijanovic-Djukic, Natasa (2020): "Missed by Filter Lists: Detecting Unknown Third-Party Trackers with Invisible Pixels", in: Proceedings on Privacy Enhancing Technologies, pp. 499-518. (DOI)

[4]

Böttger, Christian; Demir, Nurullah; Hörnemann, Jan; Acharya, Bhupendra; Pohlmann, Norbert; Holz, Thorsten; Grosse-Kampmann, Matteo; Urban, Tobias (2025): "Understanding Regional Filter Lists: Efficacy and Impact", in: Proceedings on Privacy Enhancing Technologies, pp. 309-325. (DOI)

[5]

Amjad, Abdul Haddi; Munir, Shaoor; Shafiq, Zubair; Gulzar, Muhammad Ali (2024): "Blocking Tracking JavaScript at the Function Granularity", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[6]

Dimova, Yana; Acar, Gunes; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (2021): "The CNAME of the game: Large-scale analysis of DNS-based tracking evasion", Proceedings on Privacy Enhancing Technologies 2021:394–412. (DOI) (Link)

[7]

Sjösten, Alexander; Snyder, Peter; Pastor, Antonio; Papadopoulos, Panagiotis; Livshits, Benjamin (2020): "Filter List Generation for Underserved Regions", in: Proceedings of the ACM Web Conference. (DOI)

[8]

Matte, Célestin; Bielova, Nataliia; Santos, Cristiana Teixeira (2020): "Do Cookie Banners Respect my Choice? Measuring Legal Compliance of Banners from IAB Europe's Transparency and Consent Framework", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[9]

Demir, Nurullah; Hörnemann, Jan; Große-Kampmann, Matteo; Urban, Tobias; Pohlmann, Norbert; Holz, Thorsten; Wressnegger, Christian (2023): "On the Similarity of Web Measurements Under Different Experimental Setups", in: Proceedings of the ACM Internet Measurement Conference, pp. 356-369. ACM DOI 10.1145/3618257.3624795 is listed by DBLP but was not registered with the DOI resolver as of 2026-08-12; the DOI above resolves to the authors' institutional record of the same paper (DOI)

[10]

Wang, Xinzhe; Zhuang, Zeyang; Meng, Wei; Cheng, James (2024): "Detecting and Understanding Self-Deleting JavaScript Code", in: Proceedings of the ACM Web Conference. (DOI)

[11]

Lukić, Karlo; Papadopoulos, Lazaros (2026): "Privacy vs. Profit: The Impact of Google's Manifest Version 3 (MV3) Update on Ad Blocker Effectiveness", in: Proceedings on Privacy Enhancing Technologies. (Link)

[12]

Chen, Quan; Snyder, Peter; Livshits, Ben; Kapravelos, Alexandros (2021): "Detecting Filter List Evasion with Event-Loop-Turn Granularity JavaScript Signatures", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[13]

Lee, Dongkeun; Joo, Minwoo; Lee, Wonjun (2023): "Net-track: Generic Web Tracking Detection Using Packet Metadata", in: Proceedings of the ACM Web Conference. (DOI)

[14]

Lee, Kiho; Lim, Chaejin; Jin, Beomjin; Kim, Taeyoung; Kim, Hyoungshick (2024): "AdFlush: A Real-World Deployable Machine Learning Solution for Effective Advertisement and Web Tracker Prevention", in: Proceedings of the ACM Web Conference. (DOI)

[15]

Shuang, He; Zhao, Lianying; Lie, David (2025): "Duumviri: Detecting Trackers and Mixed Trackers with a Breakage Detector", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[16]

Shuba, Anastasia; Markopoulou, Athina; Shafiq, Zubair (2018): "NoMoAds: Effective and Efficient Cross-App Mobile Ad-Blocking", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[17]

Shuba, Anastasia; Markopoulou, Athina (2020): "NoMoATS: Towards Automatic Detection of Mobile Tracking", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[18]

Varmarken, Janus; Le, Hieu; Shuba, Anastasia; Markopoulou, Athina; Shafiq, Zubair (2020): "The TV is Smart and Full of Trackers: Measuring Smart TV Advertising and Tracking", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[19]

Ferreira Torres, Christof; Willi, Fiona; Shinde, Shweta (2023): "Is Your Wallet Snitching On You? An Analysis on the Privacy Implications of Web3", in: 32nd USENIX Security Symposium (USENIX Security 23). (Link)

[20]

Rüth, Jan; Zimmermann, Torsten; Wolsing, Konrad; Hohlfeld, Oliver (2018): "Digging into Browser-based Crypto Mining", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[21]

Subramani, Karthika; Yuan, Xingzi; Setayeshfar, Omid; Vadrevu, Phani; Lee, Kyu Hyung; Perdisci, Roberto (2020): "When Push Comes to Ads: Measuring the Rise of (Malicious) Push Advertising", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[22]

Ukani, Alisha; Haddadi, Hamed; Snoeren, Alex C.; Snyder, Peter (2025): "Local Frames: Exploiting Inherited Origins to Bypass Content Blockers", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, pp. 1349-1363. (DOI)

[23]

Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[24]

Smith, Michael; Snyder, Peter; Livshits, Benjamin; Stefan, Deian (2021): "SugarCoat: Programmatically Generating Privacy-Preserving, Web-Compatible Resource Replacements for Content Blocking", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[25]

Ghasemisharif, Mohammad; Polakis, Jason (2023): "Read Between the Lines: Detecting Tracking JavaScript with Bytecode Classification", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)