Differences

This shows you the differences between two versions of the page.

--- privacy:cookies [2025/01/30 14:37] – [Cookiedatabase] karelkubicek
+++ privacy:cookies [2026/09/11 02:30] (current) – Point at the new statistics:annotation page from the validation section and Related Pages. Authored by Claude karel.kubicek.claude
@@ Line 1: / Line 1: @@
 ====== Classifying Cookies ======
-Browser cookies are still the most commonly used method for tracking the session state of websites and the identity of visitors. According to prior studies, between 80% in 2012 {[roesner2012_detecting]} and 90% in 2019 {[solomos2019_clash,sanchezrola2019can]} of websites use cookies for user tracking, often without users' knowledge. While other stateless tracking technologies, such as [[Privacy:Fingerprinting]] or [[Privacy:Requests#classification_of_link_decorators|Link decorators]], exist, cookies remain the primary choice, with stateless methods typically used in combination with cookies. This trend persists despite the discontinuation of third-party cookies.
+Browser cookies are still the most commonly used method for tracking the session state of websites and the identity of visitors. Sánchez-Rola et al. {[sanchezrola2019can]} found cookies capable of identifying a user on **more than 90%** of the websites they visited, often without those users' knowledge.((The widely repeated trend line "80% in 2012 {[roesner2012_detecting]} rising to 90% in 2019 {[solomos2019_clash]}" — which this page carried until 2026-09-10 and which comes from the introduction of {[bollinger2022automating]} — could not be confirmed against either primary source: the Roesner NSDI 2012 paper contains no percentage between 70% and 99% anywhere in its text, and the Solomos et al. paper reports on the tracker–publisher graph rather than a share of websites. Checked 2026-09-10. Do not cite the pair without re-reading both.)) While other stateless tracking technologies, such as [[Privacy:Fingerprinting]] or [[Privacy:Requests#Link Decoration and Tracking Parameters|Link decorators]], exist, cookies remain the primary choice, with stateless methods typically used in combination with cookies. This trend persists, and third-party cookies were in the end **not** discontinued: on 22 April 2025 Google announced it would "maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies".((Anthony Chavez, [[https://privacysandbox.google.com/blog/privacy-sandbox-next-steps|"Next steps for Privacy Sandbox and tracking protections in Chrome"]], 22 April 2025. The older ''privacysandbox.com/news/…'' URL now redirects here; the quoted text is unchanged. Checked 2026-09-10.)) They remain allowed by default in Chrome, blocked in its Incognito mode, and partitioned per top-level site by default in Firefox and Safari — so what a measurement observes depends on which browser it drove and in which mode; see [[Programming:Stateful stateless#Since 2022 the engine decides, not you]].
-Below, we discuss two main classification methods: using datasets of labeled cookies or machine learning (ML) to classify cookies based on their context and request URL. But first some preliminaries.
+This page is about deciding **what a cookie you have already recorded is for**. That is a labelling problem with a specific and unusual property: there is no ground truth. Nobody can read a cookie value and know that it carries an advertising identifier; every label on this page comes from someone's declaration, someone's list, or someone's model, and the interesting methodological questions are all about which of those you chose and how much of your data it could label at all.
+<WRAP important>
+**"Cookie classification" names at least four different decisions, and papers routinely conflate them.** Of the **53** papers in [[literature:corpus|our corpus]] that classify a cookie, **18 (34.0%)** decide a //purpose// category, **16 (30.2%)** decide whether the value is a per-user //identifier//, **11 (20.8%)** decide whether the cookie belongs to a //tracker// from the provenance of whatever set it, and **5 (9.4%)** decide a //security// role. Those are different tasks with different ground truth, different error modes and different error rates, and a related-work section that lists them together is comparing things that are not comparable. Pick yours before you pick a method: [[#Four Questions Called "Cookie Classification"]].
+</WRAP>
+===== What to Read First =====
+  * **Automating Cookie Consent and GDPR Violation Detection** {[bollinger2022automating]}, USENIX Security 2022 — the reference point for purpose classification. It builds the ground truth (2.2M cookies declared by website operators through their CMPs), trains a classifier on it, and measures Cookiepedia against the same labels. Read §4 for the evaluation and Table 3 for the number most papers forget to report: Cookiepedia's **cookie coverage of 79.2%**.
+  * **CookieGraph: Understanding and Detecting First-Party Tracking Cookies** {[shaoor2023cookiegraph]}, CCS 2023 — the graph-feature successor, and the paper that made first-party tracking cookies a measurable category. Its released artifact is also the easiest way to see how thin name-based labelling is in practice (see [[#Coverage is the number you have to report]]).
+  * **Semantics-Aware Cookie Purpose Compliance** {[chen2025_semantics]}, TheWebConf 2025 — the only peer-reviewed LLM cookie classifier in these seven venues. Read it for the design (segment the //value//, then interpret the segments) rather than for the F1.
+  * **Crumbling Cookie Categories** {[jiwani2024crumbling]}, PoPETs 2024 — the categories you are classifying into are not understood by the people they exist for. **7%** of participants correctly identified the standard definition of a "functional" cookie, and 24% that of a "performance" cookie.
+  * **Journey to the Center of the Cookie Ecosystem** {[sanchezrola2021_journey]}, IEEE S&P 2022 — the largest identifier-classification run in the corpus (137,997,677 cookies over 6.2M pages, 48% classed as identifiers) and the paper that moved the field from length-and-expiry thresholds to an entropy test.
+  * Then, for the mechanics your classifier sits on top of: [[Privacy:Browser storage]] for what your crawler actually captured, and [[Privacy:Cookie syncing]] for what happens to an identifier after you have found it.
+===== Scope: What This Page Covers and What It Does Not =====
+Cookies touch six pages on this wiki, and the boundaries are drawn by //what you are doing with the cookie//, not by the mechanism. This page is deliberately narrow.
+^ Question ^ Page ^
+| What is this cookie //for//? Which label source, which taxonomy, which classifier | **this page** |
+| Does this cookie's value travel to another party, and how do I detect that | [[Privacy:Cookie syncing]] |
+| What did my crawler actually capture, and which stores did it silently miss | [[Privacy:Browser storage]] |
+| Was the cookie set before, after or in spite of a consent decision | [[Privacy:Consent]] and [[Programming:Interaction]] |
+| Do third-party cookies still exist, and what replaced them | [[Privacy:Privacy sandbox]] and [[Privacy:Browser protection]] |
+| Does my crawl carry cookies from one site to the next | [[Programming:Stateful stateless]] |
+Two consequences worth stating, because both were live judgement calls when this page was rewritten. **Identifier detection is documented on [[Privacy:Cookie syncing#The Identifier Heuristic Is the Measurement]], not here** — it is the same heuristic whether you are looking for a sync or counting ID cookies, and duplicating the table would guarantee the two copies drift. This page says which of the 53 papers do it and how the family has moved; the heuristics themselves are one click away. And **the platform history — the third-party-cookie deprecation, its reversal, CHIPS, partitioning — lives on [[Privacy:Privacy sandbox]]**; this page carries only the one sentence above, because a measurement that classifies cookies has to know that the population of cookies is browser-conditional and does not need the roadmap.
 ===== First- and Third-Party Cookies =====
-First-party cookies are set by the domain the user is directly visiting, while all other cookies are from third parties. A common misconception is that first-party cookies are always benign and third-party cookies are always intrusive. However, first-party cookies can also track users or even be set by third parties using CNAME cloaking. First-party cookies are restricted to the website's context, while third-party cookies can track users across multiple websites.
+<WRAP important>A common misconception in research is that first-party cookies are always benign and third-party cookies are always intrusive!</WRAP>
-Munir et al. {[shaoor2023cookiegraph]} observed that 89.86% of the top-million websites use first-party tracking cookies. Of these, 96.61% are ghostwritten by third-party scripts embedded in the first-party context, and some are set by fingerprinting scripts.
+First-party cookies are set by the domain the user is directly visiting, while all other cookies are considered third-party cookies. Although third-party cookies are significantly more used for tracking than first-party cookies, it is wrong to claim that first-party cookies are always benign and third-party cookies are always intrusive. First-party cookies can also track users or even be set by third parties using [[https://arxiv.org/abs/2102.09301|CNAME cloaking]] and there are many third-party cookies serving necessary functionality such as SSO.
+The only difference is from the browser perspective. First-party cookies are accessible only from the first-party website's context, while third-party cookies are accessible across multiple websites that embed the same third party. But this implementation depends on the browser, with [[https://webkit.org/blog/8943/privacy-preserving-ad-click-attribution-for-the-web/|Safari]] and [[https://blog.mozilla.org/en/products/firefox/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/|Firefox]] setting the  storage for third parties for every website separately.
+Munir et al. {[shaoor2023cookiegraph]} observed that 89.86% of the top-million websites use first-party tracking cookies. Of these, 96.61% are ghostwritten by third-party scripts embedded in the first-party context, and some are set by fingerprinting scripts. Kancherla et al. {[kancherla2025_least]} measured the same relationship from the access side rather than the setting side and found that **89.84% of all cookie accesses** on the Tranco top 10,000 are performed by third-party JavaScript — a share, not a volume, and one that is nearly identical for ''localStorage'' (90.98%) and not far off for IndexedDB (72.49%).
+The practical consequence for a classifier is that the party of a cookie is a property of the //observation//, not of the cookie: the same name and value can be first-party on one site and third-party on another, and only **2 of the 53** cookie-classifying papers in the corpus state a rule for deciding it at all (one uses the Public Suffix List, one compares host domains). If your classifier takes the party as a feature — CookieBlock and CookieGraph both do — say which eTLD list you used and at which version.
+===== Four Questions Called "Cookie Classification" =====
+Before choosing a method, decide which of these you are answering. The paper-counts are over the **53** corpus papers that classify a cookie; a paper answering two questions is in two rows.
+^ Question ^ What the label means ^ Where the ground truth comes from ^ Papers ^ Share of 53 ^
+| **Purpose** | One of //necessary / functional / analytics / advertising// (or the CMP's own scheme) | Website operators' own declarations, or a curated database built from them | 18 | 34.0% |
+| **Identifier** | The value carries a per-user identifier | None. Every paper defines its own predicate over value, lifetime and cross-profile stability | 16 | 30.2% |
+| **Tracking** | The cookie belongs to a tracker, decided from the //provenance// of the script or domain that set it | A filter list or tracker database, inherited whole, including its blind spots | 11 | 20.8% |
+| **Security role** | Authentication or session cookie; correctness of ''HttpOnly'', ''Secure'', ''SameSite'' | Behavioural tests (does removing it log you out) or the attribute itself | 5 | 9.4% |
+| **Party** | First or third party, by eTLD+1 | The Public Suffix List or an entity list | 2 | 3.8% |
+| Something else | Syncing detectors, lifetime buckets, opt-out registries, personal-data detectors, per-paper violation definitions | — | 12 | 22.6% |
+The rows are not interchangeable and the errors do not compose. A purpose label is only as good as the operator declaration behind it, and operators are wrong: {[bollinger2022automating]} found that **36.4%** of the 29,398 websites it examined had at least one cookie with an incorrectly assigned purpose, and **85.8%** had at least one cookie with a missing declaration or missing purpose. A tracking label inherits every judgement in a filter list, including the ones the list makes for breakage reasons rather than privacy reasons — see [[Privacy:Requests#Ground truth, and the circularity]]. An identifier label is a predicate you wrote yourself, so it is exactly as defensible as the paragraph in which you describe it.
+<WRAP tip>
+If your paper's claim is legal — "this cookie was set without consent and it is an advertising cookie" — you need a **purpose** label, and no amount of identifier detection substitutes for one. If your claim is about tracking capability, you need an **identifier** label and a purpose label adds nothing. Papers that state a legal conclusion off a filter-list label are making the strongest claim on the weakest ground truth of the three.
+</WRAP>
 ===== Categories =====
@@ Line 24: / Line 75: @@
     * Advertising/tracking cookies:
       * Used to tailor advertisements to the viewer, help track the user and collect sensitive data of the user's browsing behavior, usually across multiple websites. Said data is then also often sold to third parties. We recommend rejecting these types of cookies to protect your privacy.
-  * [[https://web.archive.org/web/20210520213158/https://iabeurope.eu/iab-europe-transparency-consent-framework-policies/#A_Purposes|12 purposes by IAB]], commonly used in CMPs implementing the TCF.
+  * The [[https://iabeurope.eu/iab-europe-transparency-consent-framework-policies/|IAB Europe TCF purposes]], used by CMPs implementing the TCF. **The count has moved and older papers will say 12:** as of 2026-09-10 the live policy defines **11 purposes plus 3 special purposes** (plus 3 features and 2 special features). TCF v2.2 added Purpose 11 and Special Purpose 3 was added later; the [[https://web.archive.org/web/20210520213158/https://iabeurope.eu/iab-europe-transparency-consent-framework-policies/#A_Purposes|2021 snapshot]] a lot of the literature cites has 10 purposes and 2 special purposes. Cite the version, not the number. See [[Privacy:TCF consent strings]].
-===== Datasets and Classification Services =====
+The ICC scheme is the field's default and it is not stated as such. Of the **29** corpus papers that name any category scheme on a cookie tuple, **11 (37.9%)** use the ICC four — but only **8** name the ICC or the International Chamber of Commerce; the other three simply write the four categories out. Counted by exact string the largest group is two papers. The fold and every contributing string are on [[provenance:privacy:cookies]].
-Using datasets of cookies or online classification services has significant disadvantages: they cannot classify unseen data or assign one cookie multiple classes based on dynamic content. However, they offer advantages over ML methods, such as post-crawl classification of detected cookies.
+<WRAP alert>
+**The categories do not survive contact with a user.** Jiwani et al. {[jiwani2024crumbling]} tested comprehension of the standard category names and found that only **7%** of participants could correctly identify the definition of a "functional" cookie and **24%** that of a "performance" cookie. Four candidate replacements beat "functional" — "customization" 72%, "personalized experience" 67%, "preferences" 59% — and the paper recommends "extra functionality cookies" and "anonymous analytics cookies" (67%, against performance's 24%) instead. Schöni et al. {[schoeni2024_cookieblock]} found the same downstream: **18 of 40** participants needed a prompt to recover from breakage caused by a cookie misclassification. If your paper's conclusion depends on users acting on a category, that dependency is a finding in itself, not an assumption.
+</WRAP>
-We discuss issues with dynamic cookie names, publicly released datasets, and two main online classification services: Cookiepedia and Cookiedatabase.
+===== Which Methods Are Current =====
-==== Dynamic Cookie Names ====
+<WRAP important>
+A ranking of what the literature //did// is a fact about the literature, not advice about what to do now. Statuses below are as of **2026-09-10** and rest on two different kinds of evidence, kept separate: corpus counts over the 53 cookie-classifying papers in [[Literature:Corpus|the seven venues, 2010–2026]], and dated primary sources for anything about tooling or platforms. The 2025–2026 venue-years are **provisional** — CCS 2026 and IMC 2026 have not been held, and IEEE S&P and WWW 2026 are incompletely selected — so a "current" claim resting on them is resting on the thinnest years in the corpus. Read them as arguments. The full log is on [[provenance:privacy:cookies]].
+</WRAP>
+^ Family ^ What it does ^ Papers ^ First → most recent ^ 2010–15 ^ 2016–19 ^ 2020–22 ^ 2023–24 ^ 2025–26* ^ Status in 2026 ^
+| **Purpose database lookup** | Query Cookiepedia, Cookie-Script or cookiedatabase.org by cookie name (and sometimes domain) | 17 | 2016 → 2025 | 0 | 1 | 3 | 8 | 5 | **The default, and by a distance.** Cheap, post-hoc, needs no instrumentation. Its weakness is coverage, not accuracy — see below |
+| **Own hand-written rule** | A predicate the authors wrote for this paper and named nothing | 20 | 2011 → 2025 | 5 | 3 | 8 | 0 | 4 | **Still the single largest family, and that is the finding.** Almost none of these are reusable or reused |
+| **Identifier heuristic** | A predicate over the cookie //value//: length, lifetime, cross-profile stability, entropy | 15 | 2014 → 2026 | 2 | 2 | 7 | 1 | 3 | **Current, but the predicate changed.** Thresholds on length and expiry are superseded by an entropy test; see below and [[Privacy:Cookie syncing#What is genuinely superseded]] |
+| **Filter list / tracker database** | Label the cookie by the provenance of what set it: a cookie set by a domain on EasyPrivacy or ''justdomains'' is an advertising cookie | 8 | 2014 → 2025 | 1 | 1 | 2 | 1 | 3 | **Current and growing.** Three of the eight are 2025. Cheapest possible labelling; inherits the list's blind spots wholesale |
+| **A published cookie classifier, reused** | Run CookieBlock, CookieGraph or WebGraph off the shelf | 5 | 2023 → 2025 | 0 | 0 | 0 | 3 | 2 | **Current, and the newest family here.** It did not exist before 2023 because the classifiers did not |
+| **Own supervised model** | Train a model for this paper on your own labels | 3 | 2014 → 2023 | 1 | 0 | 1 | 1 | 0 | **Rare, and it has stopped — for non-LLM models.** The last one is {[shaoor2023cookiegraph]}; the only cookie classifier trained in these venues since is the fine-tuned LLM in the row below |
+| **Hand labelling** | Authors label a sample themselves | 2 | 2014 → 2025 | 1 | 0 | 0 | 0 | 1 | Used as ground truth for something else, never as the classifier |
+| **Large language model** | Prompt or fine-tune an LLM on the cookie name and value | 1 | 2025 → 2025 | 0 | 0 | 0 | 0 | 1 | **One paper. Not yet established practice for cookies** — see [[#Where LLM classification actually is]] |
+| Papers in the bucket (denominator) | | 53 | | 7 | 7 | 17 | 10 | 12 | |
+\\ * 2025–2026 is a provisional bucket; see the box above. The columns count **papers**, and a paper using two families is counted in both, so the columns do not sum to the denominator row.
+==== What is genuinely superseded ====
+Each of these rests on a named, dated source that supersedes the thing it retires, not on a corpus count.
+  * **A fixed length window, or a long expiry, as the identifier test.** These were the standard predicates from 2014 to about 2021 and they are weak now. The replacement is an **entropy or guessability** test on the value: ''zxcvbn'' guesses ≥ 10^9 is the criterion used by {[sanchezrola2019can]} and {[sanchezrola2021_journey]}, adopted by {[calzavara2026_syntactic]}, and used by {[tang2025_navigating]} in 2025 to find tracking UIDs. Note how thin the corpus evidence for the //name// is, and that this is a case where the mechanism has spread further than the library: exactly **2** of the 5,869 readable papers mention ''zxcvbn'' within 150 characters of the word "cookie", while **35** mention entropy in the same window. The full argument, with the ten-heuristic comparison table, is on [[Privacy:Cookie syncing#The Identifier Heuristic Is the Measurement]] — do not write a new one without reading it.
+  * **Installing the CookieBlock extension into a Chrome crawler.** This was the recipe on this page until September 2026 and it no longer works. CookieBlock is a Manifest V2 extension((''manifest.json'' in [[https://github.com/dibollinger/CookieBlock|dibollinger/CookieBlock]] declares ''%%"manifest_version": 2%%''. Read 2026-09-10.)) and Chrome disabled Manifest V2 everywhere with Chrome 138 on 24 July 2025, removing support entirely in Chrome 139.((Chrome for Developers, [[https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline|"Manifest V2 support timeline"]]: "Jul 24th 2025: Manifest V2 is disabled everywhere. With Chrome 138 all users on all channels of Chrome have now Manifest V2 extensions disabled. Users can no longer turn them back on." Fetched 2026-09-10.)) The Chrome Web Store listing now returns "This item is not available".((Verified 2026-09-10 three ways: the store page at ''chromewebstore.google.com/detail/cookieblock/fbhiolckidkciamgcobkokpelckgnnol'' renders "This item is not available"; the CRX endpoint returns HTTP 204 with a zero-byte body where a live extension returns 200 with a package, and an invented extension id returns 404 with ''status="error-unknownApplication"''; the update check returns ''status="noupdate"''.)) Use the Firefox add-on or the offline classifier instead — see [[#CookieBlock]].
+  * **Treating "the cookie has a purpose label" and "the cookie was in the database" as the same event.** Every purpose-database paper before about 2022 reports a category distribution without reporting how many cookies got no category at all. That is not a rounding error: see the next section.
+  * **"Third-party cookies are about to disappear, so cookie classification is about to stop mattering."** They are not, and it does not. The framing that holds is "Chrome keeps them, Safari and Firefox do not", which makes every prevalence figure on this page **browser-conditional**. The detail is on [[Privacy:Privacy sandbox]].
+==== Coverage is the number you have to report ====
+The single most under-reported quantity in cookie purpose classification is **what fraction of your cookies got a label at all**. A database lookup that answers for 40% of your cookies and a classifier that answers for 100% of them are not comparable no matter what their accuracies are, and the category distribution you publish is a distribution over the part that answered.
+Four independent measurements, four different populations, all of them published:
+^ Source ^ Population ^ Cookies that got a category ^
+| {[bollinger2022automating]}, Table 3 | 277k cookies from 29,398 CMP-using websites | Cookiepedia **79.2%**; their own XGBoost model 100% |
+| {[demir2024_bannertools]} | Cookies from a cookie-banner-tool crawl | Cookiepedia classified **57%** of all cookies and **38%** of distinct cookies |
+| {[lin2024_browsing]}, Table 1 | 18,074 cookies across 255 websites with cookie notices | Cookie-Script left **14,619 unclassified — 80.9%**((Computed from the paper's Table 1 by this page, not stated as a percentage by the paper: 940 strictly necessary + 905 performance + 103 functionality + 1,507 tracking + 14,619 unclassified = 18,074. Table 1's second column is a **mean per site**, not a share — an earlier version of this page read the 28.50 in the unclassified row as a percentage, which is wrong and contradicts the paper's own caption.)) — "the vast majority of cookies are unclassified" |
+| The Cookiepedia name table released with {[shaoor2023cookiegraph]} | 45,785 distinct cookie names looked up | **39.3%** returned one of Cookiepedia's four categories; 35.1% returned an error and 25.6% returned "Unknown" |
+| Cookiepedia's own front page | Its whole 42,020,489-cookie database | **32% Unknown**, alongside 1% strictly necessary, 5% performance, 3% functionality, 58% targeting(([[https://cookiepedia.co.uk/|cookiepedia.co.uk]] front page, "Website Benchmarks from Cookiepedia". Vendor self-report, read 2026-09-10.)) |
+The last row is a vendor figure and the fourth is reproducible in one command:
+<code bash>
+curl -sL 'https://raw.githubusercontent.com/cookiegraph/CookieGraph/main/Feature%20Extraction%20and%20Classifier/code/labelling_scripts/cookies_categories_updated.csv' \
+  | python3 -c "import csv,sys,collections; r=csv.reader(sys.stdin); next(r); c=collections.Counter(x[2] for x in r); n=sum(c.values()); [print(f'{v:8d} {100*v/n:5.1f}%  {k}') for k,v in c.most_common()]"
+</code>
+The script that produces this table with its denominators is [[provenance:privacy:cookies#cookiepedia coverage|''cookiepedia_coverage.py'']].
+<WRAP alert>
+The spread between 79.2% and 39.3% is not a contradiction — it is the whole point. {[bollinger2022automating]} looked cookies up on sites that run a CMP, which are the sites whose cookies Cookiepedia is built from; the CookieGraph table looked up names from a general Tranco crawl. **Coverage is a property of your population, not of the database**, so you cannot inherit someone else's coverage figure and you have to measure your own.
+</WRAP>
+===== Label Sources: Datasets and Classification Services =====
+Using datasets of cookies or online classification services has significant disadvantages: they cannot classify unseen data or assign one cookie multiple classes based on dynamic content. However, they offer advantages over ML methods, such as post-crawl classification of detected cookies — which is why they are the largest family in the table above.
+<WRAP info>
 Some websites deviate from the typical key-value (cookie name and cookie value) scheme by storing data directly in the cookie name. There are several cases, explained by following examples:
   * ''_gat_UA-<ID>'' and ''_ga_<ID>'' (Google Analytics cookies), where the ID is unique to the Google Analytics configuration but not dynamic per user.
-  * ''AMCV_<ID>@<host>'' (Adobe Experience Cloud Identity Service cookie), where the ID is unique per user. Such cookie names cannot be found in databases due to their dynamic nature.
+  * ''AMCV_<ID>@<host>'' (Adobe Experience Cloud Identity Service cookie), where the ID is unique per user. Such cookie names cannot be found in databases due to their dynamic nature, except for cases when the database stores patterns.
+A name-keyed database therefore has a structural blind spot, and it is not randomly distributed: it falls on exactly the analytics and advertising vendors whose cookies you most want to label. If your lookup is exact-match on the name, say so, and report how many of your unmatched names have this shape.
+</WRAP>
 ==== OneTrust and CookieBot Dataset ====
@@ Line 49: / Line 160: @@
   * ''cat_id'': Numeric representation of ICC UK categories: 0 = Strictly-necessary, 1 = Functionality, 2 = Analytics, 3 = Advertising/tracking.
-Note that 80% of cookies are third-party cookies, the majority of these involve multiple entries for a given name and domain. However, these entries might assign contradicting labels, in fact, 7.2% of cookies have labels that do not match the majority label. You should therefore aggregate labels for given cookie and domain pair, and then pick the most popular category.
+Note that 80% of cookies are third-party cookies, the majority of these involve multiple entries for a given name and domain. However, these entries might assign contradicting labels, in fact, the paper puts a lower bound of 7.2% on the share of **third-party** cookie labels that are noise — labels that do not match the majority label for that cookie. You should therefore aggregate labels for given cookie and domain pair, and then pick the most popular category.
 There will be soon a new release based on December 2024 crawl, reach Karel Kubicek if you are reading this text and wanting the data.
-==== Open Cookie Database ====
+<WRAP tip>
+The same schema is the one you will meet again in the wild: the ''cookiepedia.csv'' shipped inside the [[https://github.com/cookiegraph/CookieGraph|CookieGraph]] artifact is 917,551 rows in exactly this ''consent_data'' layout, so despite the filename it holds **CMP-declared** labels, not Cookiepedia classifications. Its free-text ''cat_name'' column takes **1,158 distinct values**, including German-language category names — which is what "aggregate on ''cat_id'', not ''cat_name''" means in practice.
+</WRAP>
-[[https://github.com/jkwakman/Open-Cookie-Database|The Open Cookie Database]] is a crowdsourced effort to describe and categorize major cookies. As of January 2025, the published CSV file contains 2203 cookies classified into categories similar to the ICC UK guide:
+==== Cookiepedia ====
-  * Functional (also known as technical, essential or strictly necessary)
+[[https://cookiepedia.co.uk/|Cookiepedia]] is a commercial website by OneTrust, containing 42,020,489 cookies as of 2026-09-10. Categories align with ICC UK's four categories, Strictly Necessary, Functionality, Performance=Analytics, and Targeting/Advertising, read more about the [[https://cookiepedia.co.uk/classify-cookies|labeling process]]. OneTrust uses Cookiepedia to simplify cookie category assignments for their users (website operators), which however incentivizes labeling cookies as strictly necessary to avoid website breakage. This was observed by Bollinger and Kubicek et al. {[bollinger2022automating]} in Section 4.5.
-  * Personalization (also known as preferences)
-  * Analytics (also known as performance or statistics)
-  * Marketing (also known as tracking or social media)
-  * Security (custom category, used only by a few tens of cookies, which are mostly strictly necessary according to ICC UK's guide)
-==== Cookiepedia ====
+It is the field's default label source: **17 of the 53** cookie-classifying papers in the corpus use a purpose database, and Cookiepedia is named in **14** of them, from 2016 {[cahn2016_cookies]} to 2025 {[tang2025_navigating]}.
-[[https://cookiepedia.co.uk/|Cookiepedia]] is a commercial website by OneTrust, containing about 42M cookies. Categories align with ICC UK's four categories, Strictly Necessary, Functionality, Performance=Analytics, and Targeting/Advertising, read more about the [[https://cookiepedia.co.uk/classify-cookies|labeling process]]. OneTrust uses Cookiepedia to simplify cookie category assignments for their users (website operators), which however incentivizes labeling cookies as strictly necessary to avoid website breakage. This was observed by Bollinger and Kubicek et al. {[bollinger2022automating]} in Section 4.5.
+To use Cookiepedia directly on the website, you can either select to search by website or cookie name. In the first case, Cookiepedia overviews of all the first- and third-party cookies, and in the latter, it shows the aggregated purpose across all websites with this cookie. This has limitations for first-party cookies, as different websites may use cookies with the same name for different purposes. For instance [[https://cookiepedia.co.uk/cookies/user_id|user_id cookies]] is classified as Strictly Necessary despite that many websites use it to track users.((That specific classification is as last observed by the page's authors and could **not** be re-verified on 2026-09-10: ''cookiepedia.co.uk/cookies/<name>'' sits behind a Cloudflare interstitial that returns 403 to ''curl'' and to a headless Chromium from a datacentre address alike, while the site root returns 200. Check it from a residential vantage before quoting it.))
-To you Cookiepedia directly on the website, you can either select to search by website or cookie name. In the first case, Cookiepedia overviews of all the first- and third-party cookies, and in the latter, it shows the aggregated purpose across all websites with this cookie. This has limitations for first-party cookies, as different websites may use cookies with the same name for different purposes. For instance [[https://cookiepedia.co.uk/cookies/user_id|user_id cookies]] is classified as Strictly Necessary despite that many websites use it to track users.
+You can [[https://github.com/dibollinger/CookieBlock-Consent-Crawler/blob/67434cce8cab56e7097568a4162d86ee0752295f/domain_sources/cookiepedia_domain_scraper.py|scrape Cookiepedia]] or download dataset of almost 1M cookies collected by {[shaoor2023cookiegraph]} as a [[https://github.com/cookiegraph/CookieGraph/blob/main/Feature%20Extraction%20and%20Classifier/code/labelling_scripts/cookiepedia.csv|CSV here]]. Note that the site rejects plain ''curl'' with HTTP 403; a scraper needs a real browser or a browser-like client.((Checked 2026-09-10: ''cookiepedia.co.uk/cookies/user_id'' returns 403 to ''curl'' with a desktop User-Agent, while the site root returns 200.))
-You can [[https://github.com/dibollinger/CookieBlock-Consent-Crawler/blob/67434cce8cab56e7097568a4162d86ee0752295f/domain_sources/cookiepedia_domain_scraper.py|scrape Cookiepedia]] or download dataset of almost 1M cookies collected by {[shaoor2023cookiegraph]} as a [[https://github.com/cookiegraph/CookieGraph/blob/main/Feature%20Extraction%20and%20Classifier/code/labelling_scripts/cookiepedia.csv|CSV here]].
+**Accuracy, on the one dataset where anyone measured it.** {[bollinger2022automating]} evaluated Cookiepedia against 277k operator-declared labels and reports macro-recall (balanced accuracy) of **84.7%**, against **84.4%** for its own XGBoost model — the basis for the "competitive with human expertise" claim below. Precision is very uneven across classes: 94.5% for necessary, 84.2% for analytics, **38.1% for functional**. Nobody has re-measured Cookiepedia since.((The paper's §4.1 prose states **83.4%** for the same quantity while its Table 3 and §4.5 summary state **84.7%**. Its abstract quotes neither — it gives 84.4%, which is CookieBlock's own balanced accuracy, a different quantity. This page quotes the table. Flagged here rather than silently picking one.))
-==== Cookiedatabase ====
+==== Cookie-Script ====
-[[https://cookiedatabase.org/#about|Cookiedatabase]] is an open alternative to Cookiepedia with 15.5k cookies operated by Complianz.io CMP. They use the following categories:
+[[https://cookie-script.com/|Cookie-Script]] is a commercial CMP whose cookie scanner exposes a name-keyed category database using the same four ICC UK categories plus an "unclassified" bucket. It is the second-most-used purpose database in the corpus — **3** papers, all 2024–2025 {[lin2024_browsing,chen2025_semantics]} — and it is not mentioned anywhere on this page before 2026, which is a good illustration of how quietly a label source becomes standard.
+Its unclassified rate is the reason to know about it: across 255 websites with cookie notices from the Tranco top 350, {[lin2024_browsing]} categorised 18,074 cookies with Cookie-Script and **14,619 of them (80.9%) came back unclassified**. The paper's own Table 1 caption puts it plainly: "the vast majority of cookies are unclassified".
+==== Cookiedatabase.org ====
+[[https://cookiedatabase.org/#about|Cookiedatabase.org]] is an open alternative to Cookiepedia, started in 2019, operated by the Complianz CMP and funded by Complianz and the SIDN Fund. Contributions come from the websites using Complianz for consent management. They use the following categories:
   - Statistics-Anonymous
@@ Line 81: / Line 196: @@
   - Preferences Cookies (in some jurisdictions known as functionality)
-==== Cookiesearch ====
+The site no longer publishes a cookie count; its public WordPress API exposes **501** service "Data Passports" as of 2026-09-10, which is a count of //services//, not cookies.((''cookiedatabase.org/wp-json/wp/v2/service?per_page=1'' returns ''x-wp-total: 501''. There is no public endpoint for the cookie records. Checked 2026-09-10.)) Earlier versions of this page carried a figure of 15.5k cookies; it can no longer be verified from the site and has been removed rather than refreshed. Two corpus papers use it {[bouhoula2024_automated]}.
+==== Open Cookie Database ====
+[[https://github.com/jkwakman/Open-Cookie-Database|The Open Cookie Database]] is a crowdsourced effort to describe and categorize major cookies. As of 2026-09-10 the published CSV contains **2,266 cookies** and the repository is actively maintained (last commit 2026-08-21).((''raw.githubusercontent.com/jkwakman/Open-Cookie-Database/master/open-cookie-database.csv'', 2,267 lines including the header; repository ''pushed_at'' 2026-08-21T07:57:05Z via the GitHub API. Read 2026-09-10.)) Categories are similar to the ICC UK guide:
+  * Functional (also known as technical, essential or strictly necessary)
+  * Personalization (also known as preferences)
+  * Analytics (also known as performance or statistics)
+  * Marketing (also known as tracking or social media)
+  * Security (custom category, used only by a few tens of cookies, which are mostly strictly necessary according to ICC UK's guide)
+Its CSV also carries a ''Wildcard match'' column, which is the only one of these sources that addresses the dynamic-name problem described above.
+<WRAP alert>
+**No paper in the corpus uses it.** A full-text sweep of all 5,869 readable papers finds **zero** mentions of "Open Cookie Database" in any spelling. At 2,266 entries it is three to four orders of magnitude smaller than Cookiepedia, so for a general web crawl its coverage will be very low — but it is the only one of these sources whose contents, licence and history you can actually inspect, which makes it the right choice for a reproducibility-sensitive study on a small population. If you use it, report coverage explicitly; you will be the first.
+</WRAP>
+==== cookiesearch.org ====
+[[https://cookiesearch.org/|CookieSearch]] is an open cookie database run by the CookieYes CMP, self-describing as "100,000+ cookies", searchable by cookie name, ID, description, regex and script name. Its category scheme is six-valued — Necessary, Analytics, Advertisement, Functional, Performance, Others — so it does **not** map cleanly onto the ICC four: it splits analytics from performance, which the ICC scheme merges. Like the Open Cookie Database, it has **zero** mentions in the corpus. Treat the "100,000+" as a vendor self-report; there is no bulk export and no published methodology.((Read 2026-09-10 at ''cookiesearch.org''. The page footer reads "© 2026 CookieYes".))
-https://cookiesearch.org/ (no experience)
 ===== Machine-Learning Classification =====
-Using machine learning to classify cookies, rather than relying on static datasets, addresses the limitation of classifying unseen data. Research indicates that ML methods may even outperform human classification. However, practical deployment of ML-based approaches faces challenges similar to those in ML-based advertising blocking: they are prone to adversarial attacks, may disrupt website functionality, and can potentially be used for fingerprinting. These limitations however does not hinder application of ML-based detection in research.
+Using machine learning to classify cookies, rather than relying on static datasets, addresses the coverage limitation: a model that reads the cookie itself answers for 100% of your cookies, where a name lookup answers for 39–79% of them. Research indicates that ML methods may even outperform human classification. However, practical deployment of ML-based approaches faces challenges similar to those in ML-based advertising blocking: they are prone to adversarial attacks, may disrupt website functionality, and can potentially be used for fingerprinting. These limitations however does not hinder application of ML-based detection in research.
-==== CookieBlock Model ====
+The corpus record is thinner than the literature's self-image. **5 of 53** papers reuse a published cookie classifier and **3** trained their own. The most recent conventionally-trained cookie classifier in these venues is {[shaoor2023cookiegraph]} (2023); the only one since is {[chen2025_semantics]}'s fine-tuned GPT-3.5.
+==== CookieBlock ====
 In **Automating Cookie Consent and GDPR Violation Detection** {[bollinger2022automating]}, researchers developed an ML model to classify cookies according to the four ICC UK purposes. They scraped data from 30k websites using CMPs like OneTrust and CookieBot, collecting over 2 million cookies labeled by website operators.
@@ Line 94: / Line 230: @@
 The researchers extracted statistically rich, domain-specific features from the collected cookies. These features are derived from multiple attributes, including the cookie name, domain, value, expiry, and flags such as “HttpOnly.” For example, the entropy of a cookie's value is a key feature for identifying unique identifiers used for tracking, while the presence of a language locale often signifies cookies necessary for language settings.
-The authors trained an XGBoost model, achieving an 87.2% accuracy (84.4% balanced accuracy). This performance is competitive with the Cookiepedia dataset when considering website operators' labels as the ground truth. The confusion matrices below provide a detailed comparison.
+The authors trained an XGBoost model, achieving an 87.2% accuracy (84.4% balanced accuracy). This performance is competitive with the Cookiepedia dataset when considering website operators' labels as the ground truth, and it answers for **100% of cookies against Cookiepedia's 79.2%** on the same data. The confusion matrices below provide a detailed comparison.
 <WRAP center box>
@@ Line 101: / Line 237: @@
 </WRAP>
-Since the CookieBlock model requires instrumentation of cookie events, such as cookie updates, it must be applied during the crawling process. You can use OpenWPM's cookie instrumentation or install the CookieBlock browser extension to classify cookies. Follow these steps to set up CookieBlock in your crawler:
+<WRAP alert>
+**The Chrome route described below is dead. Do not follow it in a new crawler.** CookieBlock is a Manifest V2 extension, Chrome disabled Manifest V2 everywhere with Chrome 138 on 24 July 2025 and removed it in Chrome 139, and the Chrome Web Store listing now returns "This item is not available" (sources in [[#What is genuinely superseded]]). Three routes still work, in the order you should try them:
+  - **Classify offline, after the crawl.** This is the right default now: it decouples labelling from crawling, works with any crawler, and is versionable. See [[#The offline route]].
+  - **Drive Firefox instead of Chrome.** The [[https://addons.mozilla.org/en-US/firefox/addon/cookieblock/|Firefox add-on]] is still published (v1.1.0, last updated 2022-08-04, 1,980 daily users as of 2026-09-10) and Firefox continues to distribute Manifest V2 extensions. The [[https://microsoftedge.microsoft.com/addons/detail/cookieblock/mnfolmjlccppcgdeinhidialajfiopcc|Edge listing]] is also still live at v1.1.0, but Edge is Chromium and inherits Chromium's Manifest V2 removal, so treat it as unverified.((Verified 2026-09-10 via the AMO API (''addons.mozilla.org/api/v5/addons/addon/cookieblock/'': status ''public'', version 1.1.0, ''last_updated'' 2022-08-04, 1,980 average daily users) and the Edge add-ons product-details API (version 1.1.0, ''lastUpdateDate'' 2022-08-04). Mozilla's own migration guide continues to document distributing both Manifest V2 and V3 extensions.))
+  - **Load it unpacked into an older Chromium build.** Possible, and a reproducibility problem you now have to document: you are reporting results from a browser nobody ships.
+</WRAP>
+=== The offline route ===
+The classifier is released separately from the extension, as [[https://github.com/dibollinger/CookieBlock-Consent-Classifier|CookieBlock-Consent-Classifier]]. It takes a JSON file of cookies and produces features plus a prediction, so you can run it over cookies collected by //any// crawler — OpenWPM's ''javascript_cookies'' table, a Playwright ''storageState()'', a CDP ''Network.getAllCookies'' dump. The input format is one object per cookie:
+<code javascript>
+{
+  "cookie_id": {
+    "name": "<name>",
+    "domain": "<domain>",
+    "path": "/path",
+    "first_party_domain": "http://first-party-domain",
+    "label": 0,
+    "cmp_origin": 0,
+    "variable_data": [
+      {
+        "value": "<cookie content>",
+        "expiry": "<expiration in seconds>",
+        "session": "<true/false>",
+        "http_only": true,
+        "host_only": true,
+        "secure": true,
+        "same_site": "<no restriction/lax/strict>"
+      }
+    ]
+  }
+}
+</code>
+Two things the repository says that are easy to miss and change your results. Its README states that the Python feature extractor "differs from the Javascript version" and that "its outputs should not be used with the CookieBlock extension directly" — so an offline label and an extension label are not guaranteed to agree, and if your paper compares the two you have to say which you ran. And ''variable_data'' is a **list**: the model expects the sequence of values a cookie took across updates, not a single snapshot. A crawler that records the cookie jar once at the end of the visit throws away the feature the model most relies on. That is the reason for the instrumentation step below.
+=== Capturing the update history ===
+Whichever route you take, the model needs cookie //updates//, not a final jar. Use OpenWPM's cookie instrumentation (see [[Programming:Crawler:OpenWPM]]), a CDP ''Network.responseReceivedExtraInfo'' listener, or the extension's own history database. The extension recipe, kept here because it is still what the Firefox route needs:
-  - Install the CookieBlock extension in the same browser used by your crawler ([[https://chrome.google.com/webstore/detail/cookieblock/fbhiolckidkciamgcobkokpelckgnnol|Chrome]], [[https://addons.mozilla.org/en-US/firefox/addon/cookieblock/|Firefox]], or other browsers listed on the [[https://karelkubicek.github.io/post/cookieblock|CookieBlock page]]).
+  - Install the CookieBlock extension in the same browser used by your crawler (see the links in the box above, and the [[https://karelkubicek.github.io/post/cookieblock|CookieBlock page]]).
   - During installation, ensure all cookie categories and "Keep Track of Cookie History" are enabled. To be safe, open the cookie popup and click "Pause Cookie Removal."
   - Identify the extension ID by navigating to CookieBlock's settings and checking the URL: ''%%chrome-extension://<ID>/options/cookieblock_options.html%%''.
@@ Line 109: / Line 285: @@
   - After the crawl, collect all data from CookieBlock's database.
-The following Python code illustrates these steps for a Selenium-operated Chrome browser. Note that while this step is manual, it is necessary to perform it only once.
+The following Python code illustrates these steps for a Selenium-operated Chrome browser. Note that while this step is manual, it is necessary to perform it only once. **It is retained as a record of the method and as a template for the Firefox equivalent; as written it targets Chrome and will not work in Chrome 139 or later.**
 <file python create_profile.py>
@@ Line 125: / Line 301: @@
 Edit your crawler to load the profile before starting the crawl and to extract the cookie category data afterward:
-<file python create_profile.py>
+<file python crawl.py>
 import json
 from selenium import webdriver
@@ Line 223: / Line 399: @@
 ==== CookieGraph Model ====
-**CookieGraph: Understanding and Detecting First-Party Tracking Cookies** {[shaoor2023cookiegraph]} extends CookieBlock to resist adversarial modifications by avoiding easily mutable features (e.g., name) and leveraging network graph features to capture cookie usage patterns. This approach requires even further instrumentation, available only in their custom crawler.
+**CookieGraph: Understanding and Detecting First-Party Tracking Cookies** {[shaoor2023cookiegraph]} extends CookieBlock to resist adversarial modifications by avoiding easily mutable features (e.g., name) and leveraging network graph features to capture cookie usage patterns. This approach requires even further instrumentation, available only in their custom crawler. It reports 90.18% accuracy, 90.07% precision and 92.09% recall.
-Find the CookieGraph artifact at https://github.com/cookiegraph/CookieGraph/.
+Note that it answers a **different question**: CookieGraph's label is ATS versus non-ATS (advertising-and-tracking service or not), a binary tracking judgement, where CookieBlock's is a four-way purpose. Its ground truth is a combination of EasyList, EasyPrivacy, Cookiepedia and label propagation, so it inherits the filter lists' definition of a tracker — a legal claim built on it inherits that too.
+Find the CookieGraph artifact at https://github.com/cookiegraph/CookieGraph/. One caveat if you reuse the labelling code: the file ''cookie_categories_updated.csv'' in ''labelling_scripts/'' is not a CSV at all but a saved ''wget'' log; the real table is the similarly named ''cookies_categories_updated.csv''.((Both files read 2026-09-10 from the repository's ''main'' branch. ''cookie_categories_updated.csv'' is 3,260 bytes beginning ''%%--2023-03-02 20:52:33-- https://raw.githubusercontent.com/...%%''; ''cookies_categories_updated.csv'' is 1,656,432 bytes with header ''%%,cookie_key,category%%''.))
+==== Where LLM classification actually is ====
+Exactly **one** paper in these seven venues classifies cookies with a large language model: **Semantics-Aware Cookie Purpose Compliance** {[chen2025_semantics]}, TheWebConf 2025. That is **1 of the 53** papers that classify a cookie, or 1.9%.
+Its design is the transferable part. Rather than treating the cookie value as an opaque blob with an entropy, it **segments the value into primitive units** and fine-tunes GPT-3.5-turbo to interpret each segment's semantics, then maps the interpretation onto four GDPR-framed purposes (necessary, preference, statistics, marketing). Ground truth is 2,300 cookies from Alexa top-3k sites labelled by three independent authors, with Fleiss' kappa 0.978. It reports an F1 of 0.95 against Cookiepedia, Cookie-Script and CookieBlock on that set, "surpassing the CMPs and CookieBlock by around 10% and 18%". Applied to the Alexa top 1k it finds **25.4%** of websites provide no cookie declaration and **44.1%** show a potential purpose violation.
+<WRAP important>
+**Do not write that LLM classification is now routine for cookies.** It is one paper, in the corpus's thinnest and most provisional years, and it is a fine-tuned model rather than a prompt. The contrast with adjacent tasks is the useful number, because the same corpus that says 1.9% for cookies says LLMs have arrived elsewhere:
+^ Classification target ^ Papers that used or produced a classifier at it ^ …using an LLM ^ Share ^
+| privacy-policy | 102 | 12 | 11.8% |
+| dark-pattern | 13 | 1 | 7.7% |
+| user-generated-text | 419 | 30 | 7.2% |
+| consent-notice | 39 | 2 | 5.1% |
+| **cookie** | **53** | **1** | **1.9%** |
+| website-category | 424 | 5 | 1.2% |
+| ip-address | 295 | 1 | 0.3% |
+Corpus-wide, 177 papers use ''classification.method == "llm"'' at all, and the year curve is steep — 2 in 2023, 27 in 2024, 77 in 2025, 71 in the partial 2026. Cookies are not on that curve yet. The per-target table is generated once by [[provenance:privacy:cookies|the same script]] that backs [[Design:Website classification#which_task_though]], so the two pages cannot drift.
+</WRAP>
+Why cookies lag is a reasonable thing to speculate about in a related-work section and this page will not pretend to know. Two candidate explanations that a reviewer will accept: a cookie name-and-value pair is a very short, low-context input compared to a privacy policy, and the task already has a cheap, accepted baseline in a database lookup, so the marginal value of an LLM is lower than for tasks with no baseline at all.
 ==== Authentication Cookies ====
-**A Supervised Learning Approach to Protect Client Authentication on the Web** {[calzavara2015supervised]} investigates classifying cookies used for authentication. However, the code and model have not been published.
+**A Supervised Learning Approach to Protect Client Authentication on the Web** {[calzavara2015supervised]} investigates classifying cookies used for authentication. However, the code and model have not been published. This is the smallest of the four questions in the corpus — **5 of 53** papers — and unlike the others it has a behavioural ground truth available: remove the cookie, resubmit the request, see whether the session survives. {[calzavara2014_cookiejar]} builds a 327-cookie gold set exactly this way.
+===== Use in Publications =====
+Everything in this section is a count over [[Literature:Corpus|the corpus]]: **5,859 papers** from CCS, IMC, NDSS, PoPETs, USENIX Security, TheWebConf and IEEE S&P, 2010–2026. EuroS&P, ACSAC, RAID, AsiaCCS, CHI and SOUPS are not in it, so every figure below is a claim about those seven venues and nothing else. The report script and its unedited output are on [[provenance:privacy:cookies]].
+==== How the population was built ====
+A paper is in the population if it has at least one ''classification'' tuple whose ''target'' is ''cookie''. That is an enum field, not free text, so the set is stable between extraction runs — which is why it was preferred to a keyword sweep.
+^ Population ^ Papers ^ Share ^
+| The corpus | 5,859 | 100% |
+| …that classified or labelled anything | 4,439 | 75.8% of 5,859 |
+| …that ran an automated web crawl | 1,120 | 19.1% of 5,859 |
+| **…that classify a cookie** | **53** | **1.2% of the 4,439** |
+| …that measure anything about cookies (the above, plus a cookie detection tuple) | 117 | 2.0% of 5,859 |
+| of the 53, ran a crawl | 49 | 92.5% of 53 |
+**53 is the denominator for everything in this section**, not 5,859 and not 1,120. Three papers whose detection tuple names a "cookie" that is not an HTTP cookie — a DNS cookie, a TCP SYN cookie, a Bloom cookie — are excluded by name rather than by regex, so the exclusion can be argued with individually.
+==== It is a PoPETs literature ====
+^ Venue ^ Cookie-classifying papers ^ Papers in venue ^ Share of venue ^
+| PoPETs | 17 | 510 | 3.3% |
+| TheWebConf | 13 | 843 | 1.5% |
+| CCS | 8 | 990 | 0.8% |
+| IMC | 5 | 638 | 0.8% |
+| USENIX Security | 5 | 1,410 | 0.4% |
+| NDSS | 3 | 701 | 0.4% |
+| IEEE S&P | 2 | 767 | 0.3% |
+A third of the field is at one venue, and PoPETs' rate is more than ten times IEEE S&P's — though IEEE S&P contributes 2 papers, so read the ratio as indicative rather than as a measurement. If you are doing a literature review on cookie classification and you search the "big four" security conferences, you will miss most of it. The absence of SOUPS and CHI from this corpus compounds the same problem in the other direction: the usable-privacy half of this literature — {[jiwani2024crumbling]}, {[schoeni2024_cookieblock]} — reaches these figures only because it happened to appear at PoPETs.
+==== By year ====
+^ Year ^ Cookie-classifying papers ^ Papers classifying anything ^ Share ^
+| 2014 | 3 | 126 | 2.4% |
+| 2015 | 3 | 140 | 2.1% |
+| 2016 | 3 | 144 | 2.1% |
+| 2017 | 1 | 185 | 0.5% |
+| 2018 | 1 | 192 | 0.5% |
+| 2019 | 2 | 293 | 0.7% |
+| 2020 | 6 | 315 | 1.9% |
+| 2021 | 4 | 296 | 1.4% |
+| 2022 | 7 | 412 | 1.7% |
+| 2023 | 2 | 503 | 0.4% |
+| 2024 | 8 | 529 | 1.5% |
+| 2025* | 11 | 607 | 1.8% |
+| 2026* | 1 | 333 | 0.3% |
+\\ * Provisional venue-years: CCS 2026 and IMC 2026 have not been held, and IEEE S&P and WWW 2026 are incompletely selected, so 2026 is a floor and should not be read as a decline. 2010–2013 contributed one paper in total (CCS 2011) and are omitted. The share column is against papers that classified //anything// that year, which is the fairer denominator: it controls for the corpus roughly quintupling over the window.
+The topic is not growing as a share of classification work. It sits between 0.4% and 2.4% for the whole window with no trend, and the 2025 peak of 11 papers is 1.8% — the same share as 2020.
+==== Which label source, and how it moved ====
+The full table with statuses is in [[#Which Methods Are Current]]. The two movements worth stating plainly:
+  * **Purpose databases went from nothing to the default.** Zero papers 2010–2015, one 2016–2019, three 2020–2022, then **8 of the 10** papers in 2023–2024 and 5 of the 12 in 2025–2026. Nothing about cookies changed; Cookiepedia became easy to query and CookieGraph published a dump of it.
+  * **Hand-written one-off rules are still the largest family** at 20 of 53 papers, and they are almost entirely unreusable — 61 distinct ''resourceName'' strings across 79 tuples, of which 27 begin with the word "custom" and 34 contain it.
+==== Where the field goes quiet ====
+^ ^ Cookie papers ^ of 53 ^ All papers that classified anything ^ of 4,439 ^
+| Names a ground-truth source | 30 | 56.6% | 3,234 | 72.9% |
+| Reports any validation at all | 17 | 32.1% | 3,111 | 70.1% |
+Cookie-classification papers document their ground truth and their validation **worse** than the corpus average for classification work, by 16 and 38 percentage points. On a task whose defining difficulty is that there is no ground truth, that is the most uncomfortable pair of numbers on this page.
+^ ''classification.validation'' ^ Papers ^ Share of 53 ^
+| ''none-reported'' | 27 | 50.9% |
+| ''not-applicable'' | 16 | 30.2% |
+| ''manual-validation'' | 13 | 24.5% |
+| ''comparison-to-other-method'' | 4 | 7.5% |
+| ''cross-validation'' | 3 | 5.7% |
+| ''held-out-test-set'' | 3 | 5.7% |
+''none-reported'' and ''not-applicable'' are sentinels and are never counted as answers; the rows overlap because a paper with several cookie tuples can appear in several. Manual validation of a sample is the field's realistic minimum and only a quarter of the papers do it.
+The corpus-wide comparison, the four validation kinds and what each is worth on a task like this one are on [[Statistics:Annotation]]; 32.1% is the lowest rate of any target on this wiki that has a page.
+==== These papers do crawl better than the field ====
+Of the 53, 49 have a crawl configuration recorded. Against the 1,080 crawling papers corpus-wide:
+^ Configuration stated ^ Cookie papers (of 49) ^ All crawling papers (of 1,080) ^
+| Consent action | 65.3% | 32.3% |
+| Statefulness | 73.5% | 20.3% |
+| Interaction depth | 95.9% | 77.9% |
+| Browser | 81.6% | 49.0% |
+| Headless or not | 20.4% | 13.0% |
+| Authentication | 85.7% | 72.1% |
+Cookie papers are twice as likely as the field to state a consent action (65.3% against 32.3%) and three and a half times as likely to state statefulness (73.5% against 20.3%) — the two settings that most change a cookie count. That is a real result and it is also the floor, not the ceiling: **20.4%** state whether the browser was headless, and headlessness changes what a site serves.
+^ ''crawlConfig.consentAction'' ^ Papers ^ Share of 49 ^
+| ''no-interaction'' | 22 | 44.9% |
+| ''not-stated'' (sentinel) | 17 | 34.7% |
+| ''accept-and-reject'' | 7 | 14.3% |
+| ''reject-all'' | 2 | 4.1% |
+| ''accept-all'' | 1 | 2.0% |
+<WRAP alert>
+Read that table with two caveats. First, ''no-interaction'' is a real enum value but it is also the value an extractor reaches for when a paper is simply silent about banners; audited across the whole corpus it was unsupported by the paper in a large minority of cases, so treat 44.9% as an upper bound on "deliberately did not interact". Second, and regardless: **only 7 of 49 state that they crawled under both acceptance and rejection**, and 3 more state a single interaction (2 reject-all, 1 accept-all). A purpose distribution measured before any interaction is a distribution over the cookies a site sets to visitors who never answered, which is not the population most legal claims are about.
+</WRAP>
+==== What the papers found ====
+Each figure carries its own denominator and they are not comparable to each other. Every one below was checked against the paper's own text; the quote-check pass is in the report output.
+^ Finding ^ Population ^ Paper ^
+| 89.86% of websites have first-party tracking cookies | Top-million websites, in a deployment separate from the paper's own 20K stratified crawl | {[shaoor2023cookiegraph]} |
+| 96.61% of those are ghostwritten by third-party scripts | The first-party tracking cookies above | {[shaoor2023cookiegraph]} |
+| 89.84% of all cookie accesses are by third-party JavaScript | Tranco top 10,000, modified Firefox | {[kancherla2025_least]} |
+| 48% (66.7M) of cookies are identifiers | 137,997,677 cookies observed over 6.2M pages crawled from a 1M-domain seed | {[sanchezrola2021_journey]} |
+| 85.8% of websites have at least one cookie with a missing declaration or purpose | 29,398 CMP-using websites | {[bollinger2022automating]} |
+| 36.4% have at least one incorrectly assigned cookie purpose | Same 29,398 | {[bollinger2022automating]} |
+| 30.9% contain at least one purpose assignment that contradicts the majority label for that cookie | Same 29,398 | {[bollinger2022automating]} |
+| 26.1% use advertising/analytics cookies without declaring those purposes in the notice's initial text | 48,843 websites with cookie notices | {[bouhoula2024_automated]} |
+| 25.4% of websites provide no cookie declaration at all | Alexa top 1k | {[chen2025_semantics]} |
+| 44.1% show a potential cookie-purpose violation | Alexa top 1k | {[chen2025_semantics]} |
+| ~75% of observed cookies likely involve personal information | The paper's own global crawl | {[tang2025_navigating]} |
+| 3.13% of websites present a contradictory ("wrong category") cookie banner | Same | {[tang2025_navigating]} |
+| 39% (100 of 255) of websites keep using tracking cookies after the user opts out | 255 websites with cookie notices | {[lin2024_browsing]} |
+| 1.3% (40 of 3,177) of tracking cookies are partitioned | The paper's tracking-cookie set | {[rasaii2025_crumbs]} |
+| Only 7% of participants correctly identify the standard "functional" cookie definition, and 24% the "performance" one | Survey participants | {[jiwani2024crumbling]} |
+The last row is the one to keep in mind while reading the rest. Every percentage above is a percentage of a category system that the people it exists for cannot use.
+==== Methodology and limitations of these figures ====
+**The full query log, the report script, its unedited output, the folds with their residues, the quote checks and the external-source verification are on [[provenance:privacy:cookies]].** Corpus-wide caveats — how the corpus was built, which venue-years are provisional, how stable each extracted field is — are on [[Literature:Corpus]].
+Specific to this page:
+  * **The population is an extraction artefact, and it is a floor.** A paper enters the 53 because the extraction model assigned ''target: cookie'' to one of its classification tuples. A paper that classifies cookies as an incidental step of a study about something else may have had that step filed under ''other'', and would be missing. The wider "measures something about cookies" set is 117 papers, and the gap between 53 and 117 is mostly papers that count or track cookies without labelling them — but not entirely.
+  * **The four-question split is one person's reading, applied per ''resourceName'' string.** Every one of the 61 distinct strings is mapped by hand in the report script and every mapping is printed with the paper it came from, so a disagreement can be located and argued. The script throws rather than silently dropping a tuple whose string is not in the map, so a corpus refresh cannot quietly shrink a family. A zero residue here means the map is complete, not that every judgement in it is right.
+  * **Free-text fields are folded, and the fold is a judgement.** ''resourceName'' and ''taxonomy'' agree run-to-run on roughly 20% of exact strings, so nothing here is counted by exact string. The taxonomy fold leaves a residue of 7 tuples, printed in full on the provenance page.
+  * **The measured-results table mixes populations on purpose and cannot be aggregated.** Nothing in it can be averaged, ordered or plotted against anything else in it.
+  * **Two figures in it have denominators that the extraction got wrong or left ambiguous**, and were corrected by reading the paper: the 89.86% is over the top million from a separate deployment, not over the paper's own 20K stratified sample, and {[sanchezrola2021_journey]}'s 48% is over cookies, not websites.
+  * **''crawlConfig'' is a single object with one shared evidence quote**, so the crawl-configuration table cannot be quote-checked field by field. See the caveat box beside it.
+  * **The stability figures quoted for the extraction were measured on a previous, smaller corpus** and have not been re-measured against the current 5,859-paper run. Treat them as the right order of magnitude.
+===== What to Report =====
+If a reviewer is to accept a cookie classification result, the paper has to answer all of these. Most published papers answer fewer than half.
+  - **Which of the four questions you are answering** — purpose, identifier, tracking, or security role. Say it in one sentence, in the methodology, before the method.
+  - **The label source, named and versioned.** "Cookiepedia" is not a version; the database changes under you and nobody publishes a changelog. Record the date you queried it and, if you can, keep the raw responses.
+  - **Coverage.** How many of your cookies got a label, as a fraction of how many you tried to label. This is the number the field omits most often and it bounds every percentage you go on to report.
+  - **What you did with the unlabelled remainder.** Dropped, counted as "unknown", or assigned a default — these give three different answers and the third is almost always wrong.
+  - **The taxonomy, by name and origin.** "The four standard categories" is not a citation; the ICC UK guide is from 2012 and is a PDF you should link.
+  - **How you decided first versus third party**, with the eTLD list and its version.
+  - **Your consent state, and preferably more than one.** A purpose distribution before interaction and after rejection are different measurements of different populations.
+  - **Whether you captured cookie //updates// or a final jar.** Models that use value entropy or value churn need the sequence.
+  - **Your validation.** A hand-labelled sample with an agreement statistic is the realistic minimum. Only a quarter of published cookie-classification papers do this — being in that quarter is cheap and visible.
+  - **Which browser, in which mode, with which tracking protections.** A cookie population is browser-conditional; see [[Privacy:Browser protection]].
+  - **That your figure is a lower bound**, if it is. Name-keyed lookup misses dynamic names; filter-list provenance misses whatever the list misses; identifier heuristics miss encrypted and server-side identifiers.
+===== Open Questions =====
+<WRAP todo>
+  * **Nobody has re-measured Cookiepedia's accuracy since 2022.** {[bollinger2022automating]} is the only evaluation, on one dataset, against operator declarations that are themselves 36.4% wrong somewhere. Fourteen corpus papers use Cookiepedia as ground truth on the strength of it.
+  * **The two classifiers everyone reuses are ageing and nobody has tested them for decay.** CookieBlock's model dates from 2022 and CookieGraph's from 2023; both were trained on crawls from 2021–2022, before partitioning became a default in two engines. Apart from {[chen2025_semantics]}'s fine-tuned LLM, no cookie classifier has been trained in these venues since.
+  * **The four label sources have never been compared head-to-head on one crawl.** Cookiepedia, Cookie-Script, cookiedatabase.org and the Open Cookie Database disagree in taxonomy and in coverage, and {[chen2025_semantics]} compares two of them on 2,300 cookies. A four-way comparison on one population, reporting coverage and agreement rather than accuracy, is a short paper that everything on this page would cite.
+  * **LLM cookie classification is one paper.** {[chen2025_semantics]} fine-tunes GPT-3.5-turbo on value segments; nobody has tried a current model, a zero-shot prompt, or the obvious ablation of whether the LLM beats a name lookup on the cookies the name lookup //cannot// answer for — which is the only comparison that matters given the coverage figures above.
+  * **There is no time series.** Every figure in [[#What the papers found]] comes from a different population, crawler and year. Nothing in this corpus can say whether the share of advertising cookies grew or shrank over the window.
+  * **Partitioned cookies are measured once.** {[rasaii2025_crumbs]} reports 1.3% of tracking cookies partitioned. No classifier in the corpus treats the partition key as a feature or as part of the cookie's identity, and under partitioning the "same" cookie on two top-level sites is two cookies.
+  * **The categories themselves are the open problem.** {[jiwani2024crumbling]} shows the ICC names do not communicate and proposes replacements; no measurement paper has adopted them, so the field keeps classifying into a taxonomy it has evidence against.
+</WRAP>
+===== Related Pages =====
+  * [[Privacy:Cookie syncing|Measuring Cookie and ID Syncing]] — what happens to a cookie value after you have decided it is an identifier, and the identifier heuristics themselves.
+  * [[Privacy:Browser storage|Browser Storage Beyond Cookies]] — the five other places a site can leave an identifier, and what your crawler silently missed.
+  * [[Privacy:Consent|Granting Consent to Websites]] and [[Programming:Interaction|Interaction]] — the consent state that changes every figure here.
+  * [[Privacy:Privacy sandbox|Measuring the Privacy Sandbox]] — the third-party-cookie deprecation, its reversal, and partitioning.
+  * [[Privacy:Browser protection|Measuring with Browser Tracking Protections On]] — why a cookie population is browser-conditional.
+  * [[Privacy:Requests|Classifying Web Requests]] — filter lists, and the circularity you inherit with them.
+  * [[Privacy:TCF consent strings|TCF consent strings]] — the 12 IAB purposes, and reading what the site actually stored.
+  * [[Programming:Stateful stateless|Stateful and stateless crawling]] — whether your crawl carries cookies from one site to the next.
+  * [[Programming:Crawler:OpenWPM|OpenWPM]] — the cookie instrumentation the offline route expects.
+  * [[Design:Website classification|Classifying Websites]] — the per-target LLM adoption table this page's LLM section shares.
+  * [[Statistics:Annotation|Annotation and Validation]] — how to validate a label set whatever it labels, and why cookie classification is the worst-validated target here.
 ====== References ======
@@ Line 248: / Line 632: @@
 /* This enables discussion under this article. */
 ~~DISCUSSION~~