A common task in web privacy measurements is to determine which web requests correspond to the benign loading of required web resources and which are used to track users. There are two main methods for such classification: matching requests against crowd-sourced lists (typically used in ad-blocking or tracking protection extensions) or using machine learning (ML) to classify the requests based on their context and request URL.

This page is dedicated to the classification of web requests and partially DOM elements on the loaded page. For classification of other resources, such as cookies, JavaScript code, or fingerprinting, navigate to the specific pages. What you drive the browser with is a separate decision, and it constrains this one: a classifier that needs the initiator chain or the script call stack needs a crawler that records them.

• SoK: Advances and Open Problems in Web Tracking [2Vekaria, Yash; Beugin, Yohan; Munir, Shaoor; Acar, Gunes; Bielova, Nataliia; Englehardt, Steven; Iqbal, Umar; Kapravelos, Alexandros; Laperdrix, Pierre; Nikiforakis, Nick; Polakis, Jason; Roesner, Franziska; Shafiq, Zubair; Zimmeck, Sebastian (2025): "SoK: Advances and Open Problems in Web Tracking". arXiv preprint arXiv:2506.14057. (Link)] — a systematisation by fourteen of the field's authors, and the fastest orientation to where request classification sits in the wider tracking literature. Its §V-C1 gives the same three-limitation account of filter lists this page gives (small maintainer community, accumulated dead rules, static so evadable) and then names the ML lineage: AutoFR, AdGraph, WebGraph, WTAGraph, and PageGraph as the shipped implementation. It is still a preprint: only v1 exists (16 June 2025), and the version exhibited as a poster at IEEE S&P 2026 labels itself “Preprint”.¹⁾ Check for a venue version before you cite it as published.
• SoK: After Decades of Web Tracker Detection, What's Next? [3Rieder, Wolf; Raschke, Philip; Cory, Thomas; Sechting, Christian René; Kumar, Aditya; Küpper, Axel (2026): "SoK: After Decades of Web Tracker Detection, What's Next?", in: Proceedings of the IEEE Symposium on Security and Privacy. (Link)], IEEE S&P 2026 — a meta-study specifically of tracker detectors, which is the classifier lineage this page is about.
• Then read in this order, because each one answers the previous one's complaint: filter lists as measured dead weight [4Snyder, 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)] → what they miss [5Fouad, 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 graph lineage [6Iqbal, Umar; Snyder, Peter; Zhu, Shitong; Livshits, Benjamin; Qian, Zhiyun; Shafiq, Zubair (2020): "AdGraph: A Graph-Based Approach to Ad and Tracker Blocking", in: 2020 IEEE Symposium on Security and Privacy (SP), pp. 763-776. (DOI)], [7Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2022): "WebGraph: Capturing Advertising and Tracking Information Flows for Robust Blocking", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2875-2892. USENIX Association, Boston, MA. (Link)] → mixed resources [8Amjad, Abdul Haddi; Saleem, Danial; Gulzar, Muhammad Ali; Shafiq, Zubair; Zaffar, Fareed (2021): "TrackerSift: untangling mixed tracking and functional web resources", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] → the deployable classifier [9Lee, 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)] → labels that at least come with a breakage check [10Shuang, 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)] → how wrong the list was all along [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)].

“Which requests are tracking” hides a choice of unit, and the units are not interchangeable. Papers that appear to disagree about tracking prevalence are often measuring different rows of this table.

Mixed resources are the normal case, not the tail. TrackerSift [8Amjad, Abdul Haddi; Saleem, Danial; Gulzar, Muhammad Ali; Shafiq, Zubair; Zaffar, Fareed (2021): "TrackerSift: untangling mixed tracking and functional web resources", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] measured how far up the granularity ladder you have to go before a resource is purely one or the other: more than 17% of domains, 48% of hostnames, 6% of scripts and 9% of methods in their crawls combine tracking and functional behaviour. Blocking at the hostname level therefore breaks things, and 9 of their 10 manually inspected sites showed major or minor breakage when mixed scripts were blocked. Whatever unit you pick, say what you did with the mixed cases; “we blocked the domain” is a decision with a measurable cost.

• Matching on the third-party hostname alone. CNAME cloaking [11Dimova, 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)], first-party subdomains and CDN hosting all defeat it, and Lin et al. [25Lin, Su-Chin; Chou, Kai-Hsiang; Chen, Yen; Hsiao, Hsu-Chun; Cassel, Darion; Bauer, Lujo; Jia, Limin (2022): "Investigating Advertisers' Domain-changing Behaviors and Their Impacts on Ad-blocker Filter Lists", in: Proceedings of the ACM Web Conference. (DOI)] quantified the churn: among 252,601 domains seen while crawling 50,000 sites they found 1,748 replica ad domains, of which 35.9% worked by changing subdomains and 17.4% by moving to first-party subdomains. The 1,096 that lists did eventually block survived a mean 410.5 days (median 195.5) before a rule appeared.
• URL and page-content features in a learned classifier. WebGraph [7Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2022): "WebGraph: Capturing Advertising and Tracking Information Flows for Robust Blocking", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2875-2892. USENIX Association, Boston, MA. (Link)] showed the point directly: a URL-mutating adversary succeeded against AdGraph 96.62% of the time once first-party collusion was allowed, and against WebGraph's content-free features only 8.34%.
• Perceptual ad blocking as a robust method. Tramèr et al. [26Tramèr, Florian; Dupré, Pascal; Rusak, Gili; Pellegrino, Giancarlo; Boneh, Dan (2019): "AdVersarial: Perceptual Ad Blocking meets Adversarial Machine Learning", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] broke every perceptual ad blocker they examined; it is worth reading as the reason nobody builds on it.
• Treating a filter-list hit as the definition of tracking. See the box at the top.

LLM classification of web requests is, as of 2026-08-12, essentially absent from the peer-reviewed literature. One paper in these seven venues, TGNN [24Xiong, Shenping; Wang, Xutong; Jin, Ze; Liu, Xinyu; Wang, Haoqiang; Chen, Zhen; Tan, Ru; Liu, Qixu (2026): "TGNN: Enhancing Pixel Tracking Detection via LLM-driven Annotation and GAT-powered Structural Representation", in: Proceedings of the ACM Web Conference. (DOI)] (TheWebConf 2026), carries an llm method on a web-request classification tuple, and it uses the model to annotate training data rather than to classify at inference. A targeted search outside the corpus — arXiv, EuroS&P, ACSAC, RAID, AsiaCCS and WPES, 2025–2026 — found no peer-reviewed paper that prompts or fine-tunes a language model to decide whether an HTTP request is tracking. Industry is ahead of the literature here and says so: AdGuard demonstrated a prototype at the Ad-Filtering Dev Summit in October 2025 that asks a model per resource instead of consulting a list, and reported latency and cost as the blockers.³⁾ If you are planning an LLM-based request classifier you are not late — but you have no baseline to cite, so budget for building one, and for the reviewer question about cost, reproducibility and prompt drift that this page cannot answer for you.

And one 2026 paper is missing from the tables below by construction. AdVersa [27Lim, Chaejin; Lee, Kiho; Jin, Beomjin; Baek, Heewon; Kim, Hyoungshick (2026): "AdVersa: Adversarially-Robust and Practical Ad and Tracker Blocking in the Wild", in: Proceedings of the ACM Web Conference, pp. 3519-3530. (DOI)] (TheWebConf 2026) reports F1 98.23%, generalisation to unseen domains at 91.47% F1, and robustness where prior systems were evaded 57–92% of the time. TheWebConf 2026 is one of the incompletely-selected venue-years, so it is absent from every corpus figure on this page even though it is squarely in scope. Its own abstract frames it as embedding-based rather than LLM-based; treat it as the likeliest successor to the AdGraph/WebGraph line and not as the missing LLM baseline. Its figures here are the paper's own, taken from its abstract and Crossref record; nobody on this page has read it critically.

The main principle of block lists is their crowd-sourced nature. For instance, the EasyList repository has 324 contributors, roughly 287,000 commits and 8,901 closed issues as of 2026-08-12.⁴⁾ This has several implications:

• Widespread advertisers and trackers have well-defined and up-to-date rules, while the long tail of tracking companies might not be covered well.
• Adding rules is much more common than deleting them. Snyder et al. [4Snyder, 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)] applied EasyList to a sample of 10,000 websites and found that 90.16% of its resource-blocking rules provide no benefit to users in common browsing scenarios; they measured EasyList growing from a few hundred rules to over 60,000 across its first nine years. Böttger et al. [28Bö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)] reproduced the shape of that result on regional lists five years later: across their crawl profiles 93.3% of distinct rules identified no tracking request at all — only 8,163 of 122,548 (6.6%) ever matched one.⁵⁾
• There is a cat-and-mouse game between list maintainers and the advertising industry. Some rules (e.g., YouTube's war on ad blocking) are short-lived, making it necessary to use up-to-date lists.

Rules can prevent actions from happening (useful for protecting user privacy), either by blocking entire domains or specific requests based on their paths. Alternatively, rules can be applied after loading a resource (described by a CSS selector) to prevent its rendering, which is more useful for blocking advertisements or annoying elements.

The split matters for your measurement, and it is bigger than people expect. Measured on the live lists on 2026-08-12: EasyList is 52,557 network rules and 24,422 cosmetic rules, so nearly a third of it cannot answer “would this request have been blocked”. EasyPrivacy is 54,850 network rules and 34 cosmetic ones — effectively all network. EasyList Cookie List inverts this completely at 1,668 network and 22,979 cosmetic rules, because hiding a banner is a rendering problem. If your pipeline reports “rules matched”, say which kind.

Status column checked 2026-08-12 against the primary source in each row. Filter lists die quietly, and a dead list in a 2026 crawl is a silent measurement error.

You will be asked this in review, so have the numbers.

The reverse direction has a number too, and it is a lesson in how to read one. AdFlush [9Lee, 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 also reports 642 ads and trackers on 108 domains that the lists had missed, which it reported upstream. Both are true, and they are the point: equal marginals are not the same as equal sets. If you compare a classifier against a list, report the confusion matrix, not the two totals.

Block lists use regular expressions with custom syntax to decide which resources to block. The advantage of applying them in post-processing is that you can run a crawl allowing all resources and classify afterwards — and re-classify with a different list later, which you cannot do if you blocked at crawl time.

Maintenance status checked 2026-08-12; this is the section of the page that rots fastest.

Cosmetic filters are a different matter: do not try to evaluate them with your automation library's CSS selector engine. Modern cosmetic filters are a superset of CSS — procedural filters such as `:has-text()`, and HTML filtering (##^) — that a find_element call cannot express, and finding an element is not the same as hiding it. If you need cosmetic filtering, use the cosmetic API of the Ghostery or Brave engine to resolve the selectors for a hostname first, then query with those.

If your measurement design is “install a blocker extension and see what it blocks”, this is now a hard constraint rather than an engineering detail. Chrome's declarativeNetRequest limits, from the API documentation on 2026-08-12:⁹⁾

Two of them bite, and both are documented constants you can read at runtime rather than hard-code:

• GUARANTEED_MINIMUM_STATIC_RULES = 30,000 static rules across at most 50 enabled rulesets;
• MAX_NUMBER_OF_REGEX_RULES = 1,000 regular-expression rules of each type, each under 2 KB compiled.

(The dynamic and session limits — 5,000 unsafe dynamic, 30,000 safe dynamic since Chrome 121, 5,000 session — are in the same reference and matter less for a blocker shipping a list.)

Compare those against the lists: EasyList alone carries 52,557 network rules and EasyPrivacy 54,850 (measured 2026-08-12). Neither fits in the 30,000-rule static guarantee, let alone both, and the 1,000-rule regex cap bites well before that. An MV3 extension therefore ships a subset of the list, 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. Firefox implements declarativeNetRequest too and exposes the same constants — GUARANTEED_MINIMUM_STATIC_RULES, MAX_NUMBER_OF_ENABLED_STATIC_RULESETS, MAX_NUMBER_OF_REGEX_RULES — but MDN records the dynamic and session limits changing at Chrome 120 and Firefox 128 independently, so the numbers are version-specific per browser rather than shared.¹¹⁾ 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 [31Lukić, 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 actually 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 — MV3 blocked about 1.8 more trackers per site — but they did find MV3 leaving 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, prefer post-processing a full crawl with the Rust or Node engine above, where no rule cap applies.

Run this at the start of a crawl and archive the JSON with your data. It reads the metadata the lists publish about themselves, counts rules by kind, and hashes the bytes.

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 202608121614, commit cff91d2b, 52,556 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. Add your regional list here.
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",
}
 
# 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-12:

easylist               202608121621             network=  52557 cosmetic=  24422 exception=   758 sha256=652ca564670f
easyprivacy            202608121630             network=  54850 cosmetic=     34 exception=   836 sha256=809f80964d06
easylist-cookie        2026-08-11 23:25 UTC     network=   1668 cosmetic=  22979 exception=   427 sha256=4de43038a16a
adguard-url-tracking   2.0.13.86                network=   2492 cosmetic=      2 exception=    91 sha256=c468efefcdfe
peter-lowe             Wed, 12 Aug 2026 15:15:56 GMT network=   3525 cosmetic=      0 exception=     0 sha256=25093c8b037f

Filter lists ship to users; learned classifiers, with one partial exception, do not. Three reasons, and all three matter for how you read the results below:

• A model that decides at runtime is a fingerprinting surface. Privacy Badger's “local learning” was removed for exactly this reason.¹²⁾
• Evasion is not hypothetical. Tramèr et al. [26Tramèr, Florian; Dupré, Pascal; Rusak, Gili; Pellegrino, Giancarlo; Boneh, Dan (2019): "AdVersarial: Perceptual Ad Blocking meets Adversarial Machine Learning", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] broke perceptual ad blocking outright, and AdGraph, WebGraph, Khaleesi and WTAGRAPH all report their own evasion rates — one of them, AdGraph, at 96.62%.
• Breaking a site in a way nobody can reproduce is worse than missing a tracker, and a model gives you no rule to point at when a user complains.

None of that stops you using a learned classifier as a measurement instrument, which is what this section is for. But read the three subsections below as the field's historical baselines, not as recommendations: the systems this page calls current are in What Came After, and Why It Matters.

AdGraph: A Graph-Based Approach to Ad and Tracker Blocking [6Iqbal, Umar; Snyder, Peter; Zhu, Shitong; Livshits, Benjamin; Qian, Zhiyun; Shafiq, Zubair (2020): "AdGraph: A Graph-Based Approach to Ad and Tracker Blocking", in: 2020 IEEE Symposium on Security and Privacy (SP), pp. 763-776. (DOI)] uses ML classification based on EasyList lists. It constructs a graph structure of web elements, network requests, and JavaScript execution for feature extraction. Example features include graph size, node degree, request length, domain party, and the presence of advertising keywords in requests. A random forest model achieves 95.33% accuracy, 89.1% precision and 86.6% recall against labels derived from eight crowdsourced filter lists, as shown below. Its breakage was on par with the lists themselves: no breakage on 85.0% of sites against the lists' 88.6%, major breakage on 5.9% against 6.4%.

Repository with instrumented crawler. Its production successor is Brave's PageGraph, which is the practical way to get this representation today.

WebGraph: Capturing Advertising and Tracking Information Flows for Robust Blocking [7Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2022): "WebGraph: Capturing Advertising and Tracking Information Flows for Robust Blocking", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2875-2892. USENIX Association, Boston, MA. (Link)] is a follow-up to AdGraph. It improves feature processing to address adversarial ML methods, removes dependency on modifiable content features, and enhances overall performance: 94.32 ± 0.27% accuracy with content features removed, and the robustness result that justifies the design — a URL-mutating adversary with first-party collusion succeeded 96.62 ± 0.37% of the time against AdGraph and 8.34 ± 0.66% against WebGraph.

Repository with trained model and pipeline

Khaleesi: Breaker of Advertising and Tracking Request Chains [13Iqbal, Umar; Wolfe, Charlie; Nguyen, Charles; Englehardt, Steven; Shafiq, Zubair (2022): "Khaleesi: Breaker of Advertising and Tracking Request Chains", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2911-2928. USENIX Association, Boston, MA. (Link)] also extends AdGraph, but changes the unit: it classifies request chains, which accounted for about one third of all requests in its crawls, reaching 94.07% accuracy on a later dataset than it was trained on. Here is a repository with trained model and pipeline.

Additionally, it offers a Firefox extension that blocks advertising chains. While not directly suitable for crawls (the current implementation blocks requests), you can disable the functionality by removing the return { cancel: true } at background.js lines 51–54 (checked 2026-08-12: line 52 is the log, 53 is the cancel) and collect logs to classify ads instead.

As third-party cookies disappear, identifiers move into the URL. Link decoration is the practice of appending information to a link — ?fbclid=…, ?gclid=…, ?utm_source=… — so that the destination site, or a script on it, can recover an identifier without any cross-site storage. Classifying decorations is a different problem from classifying requests: the request may be entirely legitimate and only one query parameter privacy-relevant, so blocking is the wrong response and sanitising is the right one.

PURL (Privacy-preserving URL) [22Munir, Shaoor; Lee, Patrick; Iqbal, Umar; Shafiq, Zubair; Siby, Sandra (2024): "PURL: Safe and Effective Sanitization of Link Decoration", in: 33rd USENIX Security Symposium (USENIX Security 24), pp. 4103-4120. USENIX Association, Philadelphia, PA. (Link)], USENIX Security 2024, is the reference work.

• Method. It builds a page-execution graph that also has decoration nodes, so a decoration can be linked to the storage value it came from and the script that put it there. Encoded values are matched by monitoring Base64, MD5, SHA-1 and SHA-256 encodings of storage values, which is how a hashed cookie in a URL is caught. A random forest is then trained on labels combining filter lists, Cookiepedia and manually curated tracking-parameter lists.
• Prevalence. 73.02% of tested sites use link decoration for tracking, with an average of 10.75 tracking decorations per site. Those are the numbers to cite for “how common is this”.
• Performance and cost. 98.74% accuracy, 98.62% precision, 98.87% recall. Sanitising rather than blocking keeps breakage low: minor breakage on 5 of 100 sites and major breakage on 1 (a CSS load failure).
• The result that connects this page to fingerprinting. Fingerprinting scripts initiated requests carrying 1,800 unique decorations, of which 200 were labelled as advertising or tracking — decoration is one of the ways a fingerprint leaves the page.
• The experiment worth copying. They ran crawls with and without entering deterministic identifiers (email addresses, names) and found 538 decorations present only in the identifier crawls, 62 of them tracking. That differential design isolates identifier exfiltration from ordinary parameters far better than any static list, and it is cheap.

The lists, if you do not want to train a classifier. Parameter-stripping rules are maintained by browser vendors rather than by the filter-list community, and they are not equally accessible. Checked 2026-08-12:

Nobody has published a coverage-and-accuracy comparison of these parameter lists against each other, in the way Vallina et al. did for website categorisation services. PURL's own labels came from a union of them plus manual curation, which means the union has never been independently audited. This is a well-scoped, publishable measurement.

Finding the notice and labelling its buttons is a classification problem on DOM elements, and it is on this page because the methods are the same ones — a CSS-selector list, then a heuristic, then a small language model. What the notice means legally, and what to do about consent, is on Granting Consent to Websites; the crawler-side mechanics of clicking are on Interaction.

The pipeline everyone converges on has three stages, and each has a measured cost.

1. Find the notice. Start with the EasyList Cookie List CSS selectors (1,668 network and 22,979 cosmetic rules on 2026-08-12) and add DOM/text heuristics: high z-index, position: fixed, a privacy-related keyword pool, a container that overlaps the viewport bottom or centre.
2. Label the interactive elements. Accept / reject / close / save / settings / other. Button text is short, multilingual and adversarially designed, which is why this is the stage that moved from keyword lists to learned models.
3. Decide what to click, and verify it happened. A click that silently fails is worse than no click, because the crawl continues and reports pre-consent behaviour as post-consent. The consent-interaction crawlers the field shares for this — BannerClick, Priv-Accept and the autoconsent integration built into Tracker Radar Collector — are compared on the crawler page.

Outside these seven venues, the WPES workshop at CCS is where a good deal of this work lands: Intumwayase et al. [40Intumwayase, Jean Luc; Fouad, Imane; Laperdrix, Pierre; Rouvoy, Romain (2025): "Exploring the Enforcement of Cookie Notices across Continents: An Empirical Study", in: Proceedings of the 24th Workshop on Privacy in the Electronic Society. (DOI)] (WPES 2025) is a cross-continental study of cookie-notice enforcement and is not in any corpus figure on this page.

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 limitations are at the end of this section.

There is no single field called “request classification”, and if you search for one you will find half of it. The population for this section is built from two independent signals:

Only 42% of the population fires both signals. That is the practical finding: the filter list has become a general-purpose third-party labelling instrument, reached for by papers on consent, passkeys, WebViews and satellite connectivity that would never describe themselves as tracker-detection work — while a large minority of request classification is done with bespoke heuristics that name no public list at all.

The second signal needs narrowing, and the narrowing is itself informative. The raw enum value classification.target == “web-request” fires on 258 papers, and 94 of them are not about advertising or tracking at all — infrastructure and CDN measurement, web-application security, spam and social-network abuse, bot detection, censorship, browser-extension security. The same over-catching happens on the list side: the regular expression that finds “a blocklist” also finds 35 papers using spam, malware, IP-reputation, content-category, censorship or certificate-revocation blocklists, which belong on Website classification and IP classification. Every exclusion is named, counted and itemised on the provenance page rather than dropped.

PETS is more than six times more likely than NDSS to publish this work (12.7% of its papers against 1.9%), and PETS plus IMC together carry 43% of it on 20% of the corpus. Read that as venue scope, not as receptiveness: PETS is a privacy-only venue, so of course this work is a larger share of it, and nothing here says anything about acceptance odds. As a reading-list ranking, though, it is the one to follow.

The peak is 2018–2021 — GDPR, the AdGraph lineage and the cookie-notice literature all landing at once — and the field has settled since at roughly 4% of these venues.

Of the 197 papers that used or produced an advertising-or-tracking filter list. A paper naming several lists is counted under each, so the shares do not sum to 100%. Names were folded into families, because they are free text: the Spellings folded column is how many distinct strings the corpus uses for each.

Folding is not cosmetic here. Counting exact strings undercounts EasyList by 18.2% (90 papers against 110), EasyPrivacy by 19.7%, Ghostery/WhoTracks.me by 11.8% — and Disconnect by 45.8% (26 against 48), because it appears as Disconnect list, Disconnect.me, Disconnect blacklist, Disconnect Entity List, Disconnect Tracker Protection lists and twenty-two other spellings. Any table of list adoption built on exact strings is wrong by tens of percent.

Separately, the engines: tracker-radar-collector 10 papers (which is a crawler, not a list — a distinction the raw names do not make), adblockparser 9, adblock-rust 7, uBlock Origin Core 2, abp-blocklist-parser 1, the Adblock Plus Android library 1.

By value, and a paper can appear in more than one row: 196 used, 13 named only in an “other tools mentioned” field, 11 compared against as a baseline, 2 mentioned, 2 produced. The compared rows are the dangerous ones — a paper that beats EasyList is not a paper that adopted it.

Of the 172 population papers carrying at least one web-request classification tuple they used or produced. classification.method agrees run-to-run on 58% of papers, so read this as a ranking, not as precise shares.

Machine learning never displaced the filter list; it peaked at 11.3% of papers. The visible drop in blocklist in the provisional last bucket sits on 32 papers and two incomplete venue-years, so do not read a trend into it. The one thing the last row does establish is that LLM classification of requests has exactly one instance in these venues, in 2026.

Of the 14 population papers with a learned web-request classification tuple (supervised-ml, unsupervised-ml or llm):

The eight are NoMoAds, AdGraph, Khaleesi, WebGraph, WTAGRAPH, AdFlush, Beyond the Request and Duumviri — that is, every system this page recommends as a baseline, without exception. Duumviri is the closest thing to a break in the pattern and it is not one: it takes its tracking-detector labels from EasyList and EasyPrivacy like the rest (12,936 tracker and 14,785 non-tracker cases from the Alexa top 5K), and what is independent is its features and its separately-trained breakage detector, whose positive samples are reconstructed from exception rules and user reports rather than from tracking labels. Nobody in this corpus has trained a request classifier without a filter list somewhere in the loop.

Validation, over the same 172 papers as above:

One paper in three reports no validation of its request classification at all. The not-applicable row is mostly papers that applied a list as-is and reasonably consider the list itself the definition — 45 of those 58 papers carry that not-applicable verdict on a blocklist tuple — which is exactly the assumption Calzavara et al. [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)] measured at 16%–19% false positives. Manual validation of a sample is an afternoon's work and it is the single cheapest thing you can add.

Of the 177 papers naming a filter list as a tool they used or produced, 52 (29.4%) attach any version or date to it. Read that as an order of magnitude in both directions: the extraction fills the version field only 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 52 give an extension version (Ghostery 5.4.1, Adblock Plus 2.6.7) rather than a list version, which does not identify the rules. Precise datings do exist and are the model to copy: EasyList and EasyPrivacy, downloaded January 29, 2019; EasyList (EL), March 13, 2020; whotracks.me, 2019-09-25.

Given that EasyList publishes both a Version: and the exact Commit: in its own header, and that it changed twice within thirteen minutes on the day this page was written, a 70% silence rate is the largest single reproducibility gap on this page.

201 of the 254 ran an automated web crawl; 197 have a recorded crawl configuration. Of those, 52.3% state a consent action, 46.2% state whether the crawl was stateful, 23.4% state headless or headful, and 95.4% state an interaction depth. Consent action matters more here than on most pages: a crawl that accepted everything and a crawl that never touched the banner are measuring different webs, and nearly half the papers do not say which they did. See the crawler page for the corpus-wide comparison.

• How they were produced. One structured record per paper was extracted from full text, each tuple carrying a verbatim evidence quote and its section. The script that produces every number in this section, with its denominators, is report_requests.mjs; the folding rules are in req_fold.mjs; verify_requests_figures.mjs re-checks every per-paper figure on this page against the paper's own text. Every query, the scripts' unedited output and the full residue are on the provenance page for this one; corpus-level caveats are on corpus.
• The population is a judgement, not an enum. No field in the extraction means “classifies requests as tracking”. S1 and S2 above are proxies, both are folded free text or a hand-written task rule, and both are stated 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-stated, none-reported and not-applicable are never folded into a stated value; where they are the largest row, that is the finding.
• Free-text names were folded before counting. The residue is printed rather than dropped: 34 distinct strings across 35 tuples matched no list family, and almost all are generic off-topic phrases (12 IP reputation blacklists, combined public blacklists, eCrimeX blacklist). The full list is on the provenance page.
• Every per-paper figure on this page was checked against the paper's own full text, not against the extraction's summary of it: of 143 literal figures, 141 were found verbatim in paper.cols.txt and 2 as a listed spelling variant (Matte et al. write 1 426 and 22 949 with a thin space). That pass caught a real error: the extraction's summary of Rasaii et al. [33Rasaii, Ali; Gosain, Devashish; Gasser, Oliver (2023): "Thou Shalt Not Reject: Analyzing Accept-Or-Pay Cookie Banners on the Web", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] gives a denominator of “45,222 websites”, and that number is nowhere in the paper, which says “we crawled 45k websites and found cookiewalls on 280 of them”. The page says ~45k. Snyder et al. is a SIGMETRICS paper outside these seven venues, so its 90.16% was verified against the paper directly rather than through the corpus.
• 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 the seven — Snyder et al. at SIGMETRICS, Intumwayase et al. at WPES, and the Vekaria et al. SoK on arXiv. Any count here is a lower bound on a system's standing.
• Stability. classification.method agrees with an independent extraction run on 58% of papers and free-text names on about 20% of exact strings; enum fields such as classification.validation are considerably more stable. That is why methods are given as rankings and validation as percentages.

1. The list, its version and its commit. EasyList Version 202608121614, commit cff91d2b — not “EasyList”. Archive the .txt with your artefact. 70% of papers do not do this.
2. The engine and its version, separately from the list. adblock 0.13.2 and adblockparser 0.7 do not match the same rules, and the second one silently ignores options it does not know.
3. Which rule kinds you evaluated. Network only, or cosmetic too? Nearly a third of EasyList is cosmetic and answers a different question.
4. The unit, and how you decided “party”. Domain, eTLD+1, URL, chain or parameter — and whether party is by public suffix list (name which one) or by entity map (name which one). The two give different third-party rates for the same crawl.
5. What you did with mixed resources, given that 48% of hostnames are mixed [8Amjad, Abdul Haddi; Saleem, Danial; Gulzar, Muhammad Ali; Shafiq, Zubair; Zaffar, Fareed (2021): "TrackerSift: untangling mixed tracking and functional web resources", in: Proceedings of the ACM Internet Measurement Conference. (DOI)].
6. Validation on your own sample. Hand-label a few hundred requests and report precision against the list. One paper in three reports nothing here.
7. If you trained a classifier: what supplied the labels, and what you think the label noise is. “Filter lists” is an answer with a known 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.
8. Your consent action and statefulness, because tracking requests are conditional on both.
9. If you used a banner-clicking tool: its success rate on your sample, not its authors' [37Demir, Nurullah; Urban, Tobias; Pohlmann, Norbert; Wressnegger, Christian (2024): "A Large-Scale Study of Cookie Banner Interaction Tools and their Impact on Users' Privacy", in: Proceedings on Privacy Enhancing Technologies, pp. 5-20. (DOI)].

* No independent audit of the tracking-parameter lists exists (see Link Decoration and Tracking Parameters). PURL's ground truth is their union. * Nobody has repeated the filter-list-versus-behaviour comparison on a modern crawl at scale. Calzavara et al. [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)] did it for one taint-tracking browser on 7,614 sites; Fouad et al. [5Fouad, 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)] did it behaviourally in 2020. The 16%–19% false-positive figure is currently a single data point that a lot of this page leans on. * The Brave transfer failure in Beyond the Request [23Rieder, Wolf; Raschke, Philip; Cory, Thomas (2025): "Beyond the Request: Harnessing HTTP Response Headers for Cross-Browser Web Tracker Detection in an Imbalanced Setting", in: Proceedings on Privacy Enhancing Technologies, pp. 100-117. (DOI)] is unexplained. Whether it is Brave's own blocking changing the observable distribution, or something about its request handling, is a small and answerable question. * Python has no maintained filter-list engine. Someone should either revive python-adblock against adblock 0.13.x or state loudly that Python pipelines must shell out. * Nothing in this corpus escapes the filter list. All 8 learned request classifiers train on filter-list labels, Duumviri included. The two directions that come closest — Duumviri's differential features and breakage detector [10Shuang, 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)], and taint tracking as an independent detector [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)] — have each been done once. A request classifier whose labels come from something other than a list is an open problem, and it is the one this page would most like solved. * What Manifest V3 did to extension-based measurement. Lukić and Papadopoulos [31Lukić, 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)] found no significant loss of blocking effectiveness under declarativeNetRequest, but the 30,000-rule static cap is well under EasyList's 52,557 network rules and nobody has published which rules the shipped MV3 blockers drop, or what that omits from a measurement. * Venue coverage is itself an open problem for this topic. AdVersa [27Lim, Chaejin; Lee, Kiho; Jin, Beomjin; Baek, Heewon; Kim, Hyoungshick (2026): "AdVersa: Adversarially-Robust and Practical Ad and Tracker Blocking in the Wild", in: Proceedings of the ACM Web Conference, pp. 3519-3530. (DOI)] at TheWebConf 2026 and Intumwayase et al. [40Intumwayase, Jean Luc; Fouad, Imane; Laperdrix, Pierre; Rouvoy, Romain (2025): "Exploring the Enforcement of Cookie Notices across Continents: An Empirical Study", in: Proceedings of the 24th Workshop on Privacy in the Electronic Society. (DOI)] at WPES 2025 are both squarely in scope and both invisible to the figures above. A reading list built only from the seven venues in this corpus will be incomplete for exactly the most recent work.

• Comparison of crawling libraries — what records the initiator chain, the call stack and the response headers these methods need.
• Tracker Radar Collector — the lowest-effort crawler for this task, and where the Tracker Radar data comes from.
• Brave PageGraph — AdGraph's production successor, and the practical way to get a page-execution graph.
• Analysing and classifying JavaScript — the script-level and function-level end of the granularity ladder.
• Cookies and Fingerprinting — the other two things a “tracking” label is often about.
• Granting consent to websites — what the cookie notice means, once you have found it.
• Website classification — and the measured reason not to use a categorisation service to find trackers.
• Stateful vs stateless crawling and Interaction.
• Provenance of this page's figures.

[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]

Vekaria, Yash; Beugin, Yohan; Munir, Shaoor; Acar, Gunes; Bielova, Nataliia; Englehardt, Steven; Iqbal, Umar; Kapravelos, Alexandros; Laperdrix, Pierre; Nikiforakis, Nick; Polakis, Jason; Roesner, Franziska; Shafiq, Zubair; Zimmeck, Sebastian (2025): "SoK: Advances and Open Problems in Web Tracking". arXiv preprint arXiv:2506.14057. (Link)

[3]

Rieder, Wolf; Raschke, Philip; Cory, Thomas; Sechting, Christian René; Kumar, Aditya; Küpper, Axel (2026): "SoK: After Decades of Web Tracker Detection, What's Next?", in: Proceedings of the IEEE Symposium on Security and Privacy. (Link)

[4]

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)

[5]

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)

[6]

Iqbal, Umar; Snyder, Peter; Zhu, Shitong; Livshits, Benjamin; Qian, Zhiyun; Shafiq, Zubair (2020): "AdGraph: A Graph-Based Approach to Ad and Tracker Blocking", in: 2020 IEEE Symposium on Security and Privacy (SP), pp. 763-776. (DOI)

[7]

Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2022): "WebGraph: Capturing Advertising and Tracking Information Flows for Robust Blocking", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2875-2892. USENIX Association, Boston, MA. (Link)

[8]

Amjad, Abdul Haddi; Saleem, Danial; Gulzar, Muhammad Ali; Shafiq, Zubair; Zaffar, Fareed (2021): "TrackerSift: untangling mixed tracking and functional web resources", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[9]

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)

[10]

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)

[11]

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)

[12]

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)

[13]

Iqbal, Umar; Wolfe, Charlie; Nguyen, Charles; Englehardt, Steven; Shafiq, Zubair (2022): "Khaleesi: Breaker of Advertising and Tracking Request Chains", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2911-2928. USENIX Association, Boston, MA. (Link)

[14]

Ikram, Muhammad; Asghar, Hassan Jameel; Kaafar, Mohamed Ali; Mahanti, Anirban; Krishnamurthy, Balachander (2017): "Towards Seamless Tracking-Free Web: Improved Detection of Trackers via One-class Learning", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[15]

Iqbal, Umar; Shafiq, Zubair; Qian, Zhiyun (2017): "The ad wars: retrospective measurement and analysis of anti-adblock filter lists", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[16]

Mughees, Muhammad Haris; Qian, Zhiyun; Shafiq, Zubair (2017): "Detecting Anti Ad-blockers in the Wild", in: Proceedings on Privacy Enhancing Technologies, pp. 130-146. (DOI)

[17]

Le, Hieu; Markopoulou, Athina; Shafiq, Zubair (2021): "CV-Inspector: Towards Automating Detection of Adblock Circumvention", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[18]

Yang, Zhiju; Pei, Weiping; Chen, Monchu; Yue, Chuan (2022): "WTAGRAPH: Web Tracking and Advertising Detection using Graph Neural Networks", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[19]

Le, Hieu; Elmalaki, Salma; Markopoulou, Athina; Shafiq, Zubair (2023): "AutoFR: Automated Filter Rule Generation for Adblocking", in: Proceedings of the USENIX Security Symposium. (Link)

[20]

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)

[21]

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)

[22]

Munir, Shaoor; Lee, Patrick; Iqbal, Umar; Shafiq, Zubair; Siby, Sandra (2024): "PURL: Safe and Effective Sanitization of Link Decoration", in: 33rd USENIX Security Symposium (USENIX Security 24), pp. 4103-4120. USENIX Association, Philadelphia, PA. (Link)

[23]

Rieder, Wolf; Raschke, Philip; Cory, Thomas (2025): "Beyond the Request: Harnessing HTTP Response Headers for Cross-Browser Web Tracker Detection in an Imbalanced Setting", in: Proceedings on Privacy Enhancing Technologies, pp. 100-117. (DOI)

[24]

Xiong, Shenping; Wang, Xutong; Jin, Ze; Liu, Xinyu; Wang, Haoqiang; Chen, Zhen; Tan, Ru; Liu, Qixu (2026): "TGNN: Enhancing Pixel Tracking Detection via LLM-driven Annotation and GAT-powered Structural Representation", in: Proceedings of the ACM Web Conference. (DOI)

[25]

Lin, Su-Chin; Chou, Kai-Hsiang; Chen, Yen; Hsiao, Hsu-Chun; Cassel, Darion; Bauer, Lujo; Jia, Limin (2022): "Investigating Advertisers' Domain-changing Behaviors and Their Impacts on Ad-blocker Filter Lists", in: Proceedings of the ACM Web Conference. (DOI)

[26]

Tramèr, Florian; Dupré, Pascal; Rusak, Gili; Pellegrino, Giancarlo; Boneh, Dan (2019): "AdVersarial: Perceptual Ad Blocking meets Adversarial Machine Learning", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[27]

Lim, Chaejin; Lee, Kiho; Jin, Beomjin; Baek, Heewon; Kim, Hyoungshick (2026): "AdVersa: Adversarially-Robust and Practical Ad and Tracker Blocking in the Wild", in: Proceedings of the ACM Web Conference, pp. 3519-3530. (DOI)

[28]

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)

[29]

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)

[30]

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

[31]

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)

[32]

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)

[33]

Rasaii, Ali; Gosain, Devashish; Gasser, Oliver (2023): "Thou Shalt Not Reject: Analyzing Accept-Or-Pay Cookie Banners on the Web", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[34]

Khandelwal, Rishabh; Nayak, Asmit; Harkous, Hamza; Fawaz, Kassem (2023): "Automated Cookie Notice Analysis and Enforcement", in: 32nd USENIX Security Symposium (USENIX Security 23), pp. 1109-1126. USENIX Association, Anaheim, CA. (Link)

[35]

Ogut, Aysun; Turanlioglu, Berke; Metiner, Doruk Can; Levi, Albert; Yilmaz, Cemal; Cetin, Orcun; Uluagac, Selcuk (2024): "Dissecting Privacy Perspectives of Websites Around the World: "Aceptar Todo, Alle Akzeptieren, Accept All..."", in: Proceedings of the USENIX Security Symposium. (Link)

[36]

Bouhoula, Ahmed; Kubicek, Karel; Zac, Amit; Cotrini, Carlos; Basin, David (2024): "Automated Large-Scale Analysis of Cookie Notice Compliance", in: 33rd USENIX Security Symposium (USENIX Security 24), pp. 1723-1739. USENIX Association, Philadelphia, PA. (Link)

[37]

Demir, Nurullah; Urban, Tobias; Pohlmann, Norbert; Wressnegger, Christian (2024): "A Large-Scale Study of Cookie Banner Interaction Tools and their Impact on Users' Privacy", in: Proceedings on Privacy Enhancing Technologies, pp. 5-20. (DOI)

[38]

Tang, Brian; Bui, Duc; Shin, Kang G. (2025): "Navigating Cookie Consent Violations Across the Globe", in: Proceedings of the USENIX Security Symposium. (Link)

[39]

Rasaii, Ali; Dao, Ha; Feldmann, Anja; Javid, Mohammadmahdi; Gasser, Oliver; Gosain, Devashish (2025): "Intractable Cookie Crumbs: Unveiling the Nexus of Stateful Banner Interaction and Tracking Cookies", in: Proceedings on Privacy Enhancing Technologies, pp. 429-445. (DOI)

[40]

Intumwayase, Jean Luc; Fouad, Imane; Laperdrix, Pierre; Rouvoy, Romain (2025): "Exploring the Enforcement of Cookie Notices across Continents: An Empirical Study", in: Proceedings of the 24th Workshop on Privacy in the Electronic Society. (DOI)