A crawl is stateless when the browser starts each visit from an empty profile, and stateful when it carries the profile — cookies, localStorage, IndexedDB, the HTTP cache — from one visit to the next. That single switch decides what your crawl is able to observe at all: a crawl that starts every visit from an empty profile and visits each target once cannot see retargeting, cookie respawning, or the effect of a consent choice on the next site, because none of those exist without accumulated state. It sees cookie syncing — a fresh profile is in fact an unusually attractive target for it, see below — but only first contact, never the sync graph a real user has accumulated. It also decides how fast you can go, whether your results depend on the order you visited the list in, and how far your numbers can be pushed towards a claim about real users.

This page is about that design choice. For how one particular tool implements it, see Stateful and stateless in OpenWPM; for the tools themselves, Crawler; for where to crawl from, Crawling location; for what to do on the page once you are there, Interaction and Consent.

Before anything else: “stateful” and “stateless” mean two unrelated things in this field, and a keyword search will mix them.

• Crawl statefulness — this page. A property of your measurement: does the browser profile survive between page visits.
• Tracking statefulness — a property of the phenomenon: cookies and other client-side storage (“stateful tracking”) versus fingerprinting (“stateless tracking”). Jueckstock et al.'s “Measuring the Privacy vs. Compatibility Trade-off in Preventing Third-Party Stateful Tracking” [1Jueckstock, Jordan; Snyder, Peter; Sarker, Shaown; Kapravelos, Alexandros; Livshits, Benjamin (2022): "Measuring the Privacy vs. Compatibility Trade-off in Preventing Third-Party Stateful Tracking", in: Proceedings of the ACM Web Conference. (DOI)] is entirely about the second sense. So is the abstract of Englehardt and Narayanan's 1-million-site census [2Englehardt, Steven; Narayanan, Arvind (2016): "Online Tracking: A 1-million-site Measurement and Analysis", in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1388–1401. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] — in the same paper that runs both crawl modes. Cookies and Fingerprinting are the pages for the second sense.

This is not a pedantic distinction. It is a live source of error: one 2025 paper in our corpus is labelled by the extraction as running both crawl modes on the strength of the sentence “Stateful tracking stores explicit identifiers in the browser”, while its methods section says “Browser state was purged after every crawl … a fresh Chrome profile for each site”. Read the sentence, not the word.

The literature's vocabulary is binary; its designs are not. Three distinct configurations appear in the corpus, and the extraction's three-valued enum (stateful / stateless / both) has no slot for the third.

The seeded-stateless design is the one most often mistaken for stateful. Urban et al. state its logic exactly [3Urban, Tobias; Degeling, Martin; Holz, Thorsten; Pohlmann, Norbert (2020): "Beyond the Front Page:Measuring Third Party Dynamics in the Field", in: Proceedings of The Web Conference 2020, pp. 1275–1286. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)]:

This profile is loaded before each website visit but is not altered. Hence, each website visit uses the same profile and the order of visited websites does not impact the results.

Agarwal et al. combine the two in sequence: personas are trained statefully by browsing stereotypical sites, and then “A HPW crawl with a loaded persona is stateless, i.e., each HPW website visit is independent” [4Agarwal, Pushkal; Joglekar, Sagar; Papadopoulos, Panagiotis; Sastry, Nishanth; Kourtellis, Nicolas (2020): "Stop tracking me Bro! Differential Tracking of User Demographics on Hyper-Partisan Websites", in: Proceedings of the ACM Web Conference. (DOI)]. Englehardt and Narayanan's census does the same thing for scale rather than for personas — build one seed profile serially over the top 10,000 sites, then clone it into parallel browsers [2Englehardt, Steven; Narayanan, Arvind (2016): "Online Tracking: A 1-million-site Measurement and Analysis", in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1388–1401. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)].

You also have to say what the unit of the reset is, and papers almost never do:

• per page visit (strictest stateless);
• per site, keeping state across that site's subpages — which is what a subpage crawl usually means in practice;
• per browser instance, so a crawl with N parallel browsers has N independent cookie jars over an arbitrary partition of your site list, not one user;
• per crawl, never.

“We cleared the browser state between visits” is the most common phrasing in the corpus and the least checkable. State lives in more places than the cookie jar, and the API you reach for clears a different subset than you think. The table below is measured, not recalled: an instrumented local origin sets a server cookie, a JavaScript cookie, a localStorage marker and an immutable-cached subresource, and the crawler visits it twice with a different reset in between. A ✓ means the state survived and visit 2 saw it.

Playwright 1.62.1, Chromium 151.0.7922.34, Linux. Reproduce with the script below.

Read off the three rows in bold. Clearing cookies clears cookies. It does not clear localStorage, and it does not clear the HTTP cache — in the clearCookies() rows the cached subresource was never re-requested from the origin, so a request-counting measurement silently loses it on every visit after the first. Playwright's own documentation is accurate and easy to misread: clearCookies “Removes cookies from context”,¹⁾ and storageState returns “current cookies, local storage snapshot, IndexedDB snapshot and virtual WebAuthn credentials” — note what is missing from that list, and note that the storageState row above is the only one where cookies came back while the cache did not.

The cache matters because it is a tracking channel in its own right, not just a performance detail. Solomos et al. showed that Chrome's favicon cache is a separate store that browser “clear browsing data” controls do not touch and that persists into incognito [5Solomos, Konstantinos; Kristoff, John; Kanich, Chris; Polakis, Jason (2021): "Tales of Favicons and Caches: Persistent Tracking in Modern Browsers", in: Proceedings of the Network and Distributed System Security Symposium. (Link)]; ETag- and cache-based identifiers have the same property. A crawl whose “stateless” guarantee is clearCookies() is stateful in exactly the channels that were designed to survive a cookie clear. Acar et al. put the general version of this more starkly [6Acar, Gunes; Eubank, Christian; Englehardt, Steven; Juarez, Marc; Narayanan, Arvind; Díaz, Claudia (2014): "The Web Never Forgets: Persistent Tracking Mechanisms in the Wild", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]:

once some tracking has happened, it is hard to start from a truly clean profile

The complete list of things you should be able to say you reset, or say you did not: cookies (including partitioned ones), localStorage and sessionStorage, IndexedDB, Cache Storage and service workers, the HTTP disk cache, the favicon cache, HSTS and TLS session state, DNS cache, permission grants, and the extension state of anything you installed.

Zeber et al. compared an OpenWPM crawl against telemetry from over 50,000 opt-in Firefox users over the same period [8Zeber, David; Bird, Sarah; Oliveira, Camila; Rudametkin, Walter; Segall, Ilana; Wolls´en, Fredrik; Lopatka, Martin (2020): "The Representativeness of Automated Web Crawls as a Surrogate for Human Browsing", in: Proceedings of The Web Conference 2020, pp. 167–178. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)]. The gap is large and consistently in one direction:

crawler site visits issued requests to a median of 11.6 third-party domains, whereas for visits by humans, the median was 4.5 third parties

Two cautions. First, this is crawler versus human, not stateful versus stateless: automation, vantage point, interaction and statefulness all differ at once, so it is not a clean experiment on this axis. The existing note on this page previously read the paper's Figure 6 as “stateless crawls result in more third-party requests than a stateful crawl”; that is not what the figure compares. Second, the authors' own explanation is nevertheless a statefulness mechanism:

cookie syncing is not necessary for users who have already had their cookies synced, whereas a stateless crawler browser instance with a fresh profile would be a clear target for cookie syncing

And the direction is not universal. Fingerprinting prevalence agreed between crawl and users to within 1 percentage point in the same study — so “crawls over-count tracking” is a claim about third parties and trackers, not about every privacy metric.

The 2026 restatement of the same problem is much sharper, and it is about interaction as well as state. Song et al. trained nine website-fingerprinting models on traffic from scripted browser automation and tested them on traffic from 30 real users across 20 sites: every model scored under 10% accuracy. Training on LLM-agent-generated, persona-driven browsing instead put accuracy “into the 80% range” [22Song, Chuxu; Mekala, Dheekshith Dev Manohar; Wang, Hao; Martin, Richard (2026): "Redefining Website Fingerprinting Attacks with Multi-Agent LLMs", in: Proceedings on Privacy Enhancing Technologies, pp. 688-702. (DOI)]. If your measurement is downstream of a model trained on crawler traffic, scripted-crawl realism is not a limitations-section caveat; it is the dominant error term.

Englehardt and Narayanan are blunt about it [2Englehardt, Steven; Narayanan, Arvind (2016): "Online Tracking: A 1-million-site Measurement and Analysis", in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1388–1401. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)]:

Making stateful measurements is fundamentally at odds with parallelism.

Their own numbers, on one 2016 EC2 c4.2xlarge:

• 10 stateful browser instances in parallel, against 20 stateless ones — “stateful parallel measurements are memory-limited while stateless parallel measurements are typically CPU-limited”;
• the census itself ran 1,000,000 sites stateless but only 100,000 stateful.

The workaround is the seed profile: visit the top 10,000 sites serially, save the profile, clone it into N parallel browsers. It works well —

We find that a seed profile which has visited the top 10,000 sites will have communicated with 76% of all third-party domains present on more than 5 of the top 100,000 sites.

— but it has an artefact you must report, in the authors' own words: “third parties which don't appear in the top sites if the seed profile will have different cookies set in each of the parallel instances”, so a sync partner sees several IDs for one notional user and your sync counts inflate. Acar et al. made the same trade in 2014 and said so [6Acar, Gunes; Eubank, Christian; Englehardt, Steven; Juarez, Marc; Narayanan, Arvind; Díaz, Claudia (2014): "The Web Never Forgets: Persistent Tracking Mechanisms in the Wild", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]: “except for the sequential crawl (Crawl1), we ran multiple browsers in parallel to extend the reach of the study at the cost of not keeping a profile state (cookies, localStorage) between visits”.

A stateful crawl of a ranked list confounds rank with visit order: by the time you reach rank 10,000 the profile has seen 9,999 sites, so “tracking at low ranks” and “tracking after a lot of browsing” are the same variable. Zeber et al. name the mechanism [8Zeber, David; Bird, Sarah; Oliveira, Camila; Rudametkin, Walter; Segall, Ilana; Wolls´en, Fredrik; Lopatka, Martin (2020): "The Representativeness of Automated Web Crawls as a Surrogate for Human Browsing", in: Proceedings of The Web Conference 2020, pp. 167–178. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] — “the results of the crawl may then depend on the accumulated state, e.g., the order of pages visisted” — and Demir et al. make it a reporting requirement [23Demir, Nurullah; Große-Kampmann, Matteo; Urban, Tobias; Wressnegger, Christian; Holz, Thorsten; Pohlmann, Norbert (2022): "Reproducibility and Replicability of Web Measurement Studies", in: Proceedings of the ACM Web Conference. (DOI)]:

In stateful experiments, the order of visited pages potentially impacts the results, and it accounts for HTTP session-specific phenomena, such as opt-in to cookie tracking. Stateless crawls, in turn, allow to study session-independent attributes.

Three mitigations are in use, in ascending order of cost:

1. Go seeded-stateless and say so, as Urban et al. do, which removes the dependence by construction [3Urban, Tobias; Degeling, Martin; Holz, Thorsten; Pohlmann, Norbert (2020): "Beyond the Front Page:Measuring Third Party Dynamics in the Field", in: Proceedings of The Web Conference 2020, pp. 1275–1286. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)].
2. Randomise the visit order and publish the seed, so the confound becomes noise rather than a gradient. Rasaii et al. run their stateful campaign in a randomised order, again in the reverse of that order, and again in a recombined order, precisely so the order effect can be measured rather than assumed away [14Rasaii, 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)].
3. Repeat the whole crawl with an independently drawn order and report the between-run variation. Nobody in our corpus does this at scale; see Open Questions.

These are the results that a stateless crawl could not have produced. Each is quoted with the paper's own denominator.

• Consent given on one site follows you to the next. Rasaii et al. accepted banners across the first half of Tranco's top 20,000 and then measured the second half with that profile loaded — the denominator for the headline figure is the second-half domains where a banner was successfully rejected, not all 20,000. “Our findings reveal that around 50% of websites send at least one intractable cookie” — a tracking cookie transmitted before any consent on the site sending it. Sites with a CMP banner sent 6.91× more of them than sites with a native banner; enabling Global Privacy Control cut them by about 30%, with a further 32% on later visits after rejecting; and about 25% stop being sent only after the page is reloaded [14Rasaii, 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)]. Partitioning does not yet blunt this: “only 1.3% of all unique tracking cookies are partitioned, with more than half accompanied by nonpartitioned cookies from the same tracker domain”.
• Respawning plus syncing survives a state clear. The 2014 mechanism is historical — Flash reached end of life in December 2020 — but the finding is the reason a state clear cannot be assumed to work, and the technique moved to fingerprint-keyed respawning rather than disappearing ([9Fouad, Imane; Santos, Cristiana; Legout, Arnaud; Bielova, Nataliia (2022): "My Cookie is a phoenix: Detection, measurement, and lawfulness of cookie respawning with browser fingerprinting", in: PETS 2022-22nd Privacy Enhancing Technologies Symposium. (DOI) (Link)] in 2022, server-side in [24Fouad, Imane; Santos, Cristiana; Laperdrix, Pierre (2024): "The Devil is in the Details: Detection, Measurement and Lawfulness of Server-Side Tracking on the Web", Proceedings on Privacy Enhancing Technologies 2024(4):450-465. (DOI)] in 2024). Acar et al. found “33 different Flash cookies from 30 different domains respawned a total of 355 cookies on 107 first party domains”, and concluded that through one ad exchange present on ~11% of first parties, “This scenario enables at least 11% of a user's history to be tracked over time” [6Acar, Gunes; Eubank, Christian; Englehardt, Steven; Juarez, Marc; Narayanan, Arvind; Díaz, Claudia (2014): "The Web Never Forgets: Persistent Tracking Mechanisms in the Wild", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)].
• A trained profile is treated differently. Agarwal et al.: “having an established persona from a particular demographic … results in up to 15% more cookies stored than for a baseline with no set persona” [4Agarwal, Pushkal; Joglekar, Sagar; Papadopoulos, Panagiotis; Sastry, Nishanth; Kourtellis, Nicolas (2020): "Stop tracking me Bro! Differential Tracking of User Demographics on Hyper-Partisan Websites", in: Proceedings of the ACM Web Conference. (DOI)].
• State accumulates within a site, not only across sites. Urban et al., under a seeded-stateless design with state kept across a site's own subpages: “subsites set considerably more (36 %) cookies than the respective landing pages. On average, 55 cookies were set when loading a landing page while 78 were set when a subsite was accessed” [3Urban, Tobias; Degeling, Martin; Holz, Thorsten; Pohlmann, Norbert (2020): "Beyond the Front Page:Measuring Third Party Dynamics in the Field", in: Proceedings of The Web Conference 2020, pp. 1275–1286. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)]. See Interaction.

And one that cuts the other way: cookie respawning with browser fingerprinting was measured on 30,000 Alexa sites with a stateless harness, by comparing paired visits rather than by accumulating a profile — “1, 150 (3.83%) of the Alexa top 30, 000 websites use cookie respawning with browser fingerprinting” [9Fouad, Imane; Santos, Cristiana; Legout, Arnaud; Bielova, Nataliia (2022): "My Cookie is a phoenix: Detection, measurement, and lawfulness of cookie respawning with browser fingerprinting", in: PETS 2022-22nd Privacy Enhancing Technologies Symposium. (DOI) (Link)]. Note the qualifier: that figure counts respawning combined with fingerprinting, not respawning in general. A stateful phenomenon does not always require a stateful crawl; sometimes it requires two controlled visits. The same is true of cookie syncing at first contact. What accumulation buys is the aged identity, not the mechanism.

This is the part of the topic where the literature is out of date and a page written from the corpus alone would mislead. Everything in this section was checked against primary sources on 2026-08-19.

• Firefox partitions third-party cookies by default. Total Cookie Protection has been on by default since June 2022, “confining cookies to the site where they were created”.⁴⁾
• Chrome partitions third-party storage for every user. “The feature has been enabled for all users on Chrome 115 and later.”⁵⁾ Cookies are the exception, not the rule, here.
• Third-party cookies were not deprecated. 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”, and in October 2025 confirmed CHIPS and FedCM continue while other Privacy Sandbox APIs are phased out.⁶⁾ A 2023-vintage paper that frames its design around imminent third-party cookie removal is describing a future that did not arrive. Chrome's Incognito mode does block third-party cookies by default, which is a separate trap: “we ran in incognito for a clean profile” silently also changes the blocking policy.
• Your crawler probably turns the partitioning off. Playwright launches Chromium with –disable-features=…,ThirdPartyStoragePartitioning,…; Puppeteer does not. Measured here:

Playwright's own source names the reason, and it is directly about state-carrying: the flag is disabled so that storageState keeps working. Issue 32230 — “Local storage items set via browser.newContext() missing for an iframe in Chromium” — was fixed by turning partitioning off, and a 2025 request to turn it back on was declined with:

our current capabilities of saving/restoring the storage are not exactly compatible with partitioning … Without CDP support, it does not seem practical to replicate all the intricate details of storage partitioning outside of the browser, so disabling the feature is the only way to make things work for now

⁸⁾

So the consequence is that two crawlers driving the same engine version accumulate different third-party state, on the one axis this page is about, and the divergence exists because one of them has a profile-serialisation API that cannot express partitioned storage. Neither documents this where you would look.

And it is a moving target. In the same thread, the person who filed the request notes that “when the ThirdPartyStoragePartitioning flag is removed, bug #32230 will start reoccurring” — that is, Playwright's opt-out is expected to stop being available, and as late as January 2026 the maintainers were still asking the reporter for a design that would keep storageState working without the flag. Whenever that lands, a Playwright crawl starts accumulating partitioned storage with no change to your code, at whatever version boundary it happens on. Pin and report the Playwright version alongside the statefulness claim.

• OpenWPM also opts out, by default. BrowserParams.tp_cookies defaults to “always”, which sets network.cookie.cookieBehavior = 0 — all third-party cookies allowed, unpartitioned. Firefox tracking protection cannot be switched on at all: the code raises RuntimeError(“Firefox Tracking Protection is not currently supported”).⁹⁾

So the plain fact is that a stateful research crawl in 2026 accumulates an unpartitioned cross-site profile. That resembles a default Chrome user's cookie jar — but not that user's storage, which Chrome has partitioned since 115 — and it does not resemble a default Firefox or Safari user in either respect. And it happens whichever engine you drive, because the research tooling disables the partitioning. Whether that is the right choice depends on your question; it is never the right thing to leave unsaid. Measured, on the default Playwright Chromium context:

Engine                  third party got its cookie back on the SECOND, different site
----------------------  ----------------------------------------------------------
Chromium 151.0.7922.34  YES — sent "tp=third-party-id"

We could not run the same probe on Playwright's Firefox in this container — headless dies with RenderCompositorSWGL failed mapping default framebuffer and headed needs a dbus the image lacks — so the Firefox row is absent rather than guessed, and the Firefox claim above rests on Mozilla's documentation.

In Playwright and Puppeteer you get this by accident, which is both convenient and a reporting hazard: a fresh browser.newContext() or a fresh launch() has an empty profile, so the default is stateless and a paper that says nothing has still made a choice. Be explicit about the unit — a new context per site is cheap and isolates cache and storage as well as cookies (the browser.newContext() row above), whereas clearCookies() does not.

• Playwright: chromium.launchPersistentContext(userDataDir) and reuse userDataDir. Everything persists, including the cache. To carry a profile deliberately and legibly instead, use storageState() — it serialises cookies, localStorage and IndexedDB to JSON you can commit as an artefact, which makes the seed reproducible in a way a binary profile directory is not. It does not carry the HTTP cache.
• Puppeteer: puppeteer.launch({ userDataDir }) and reuse the directory — the same mechanism as Playwright's persistent context, and worth knowing because Puppeteer is the more used of the two in this corpus (76 crawling papers against Playwright's 34). Puppeteer has no storageState equivalent, so a legible seed means either shipping the profile directory or writing your own cookie/storage dump.
• OpenWPM: stateful is the default, and stateless is per-command-sequence: CommandSequence(url, reset=True), documented as “True if browser should clear state and restart after sequence”.¹⁰⁾ There is no global switch, which is why papers describe this in prose and reviewers cannot check it. Watch num_browsers: with N browsers your “stateful crawl” is N cookie jars. Details on Stateful and stateless in OpenWPM.
• Seeding: build the seed in a separate, documented run; store it (storageState JSON, or OpenWPM's seed_tar); record when it was built and what it visited. A seed profile ages — 2016's top 10,000 sites are not 2026's, and a seed built before a crawl that ran for three weeks is not the same instrument at the end as at the start.

This is the complete script behind the reset table — all nine reset strategies, so every row is reproducible. Save the two files side by side as server.mjs and probe.mjs; the second imports the first. It needs nothing but Playwright and a free port.

server.mjs

// Minimal instrumented origin for the state-channel probe. Counts every
// request it receives, per path, and reports what the client sent back.
import http from 'node:http';
 
export function startServer(port = 8123) {
  const log = [];
  const server = http.createServer((req, res) => {
    log.push({ path: req.url, cookie: req.headers.cookie ?? null, ims: req.headers['if-none-match'] ?? null });
    if (req.url === '/') {
      res.writeHead(200, {
        'content-type': 'text/html; charset=utf-8',
        'set-cookie': 'srv=server-set; Path=/; Max-Age=86400',
        'cache-control': 'no-store',
      });
      res.end(`<!doctype html><title>probe</title>
<script src="/cached.js"></script>
<script>
  document.cookie = 'js=js-set; path=/; max-age=86400';
  // Stamp a marker ONCE. A later visit that still sees the FIRST visit's marker
  // proves localStorage survived; one that writes its own proves it did not.
  window.__lsBefore = localStorage.getItem('ls');
  if (!window.__lsBefore) localStorage.setItem('ls', 'visit-' + Date.now());
</script>
<img src="/cached.png">`);
      return;
    }
    if (req.url === '/cached.js') {
      // Aggressively cacheable: a second visit should not hit the network.
      res.writeHead(200, { 'content-type': 'application/javascript', 'cache-control': 'public, max-age=31536000, immutable' });
      res.end('window.__cached = true;');
      return;
    }
    if (req.url === '/cached.png') {
      res.writeHead(200, { 'content-type': 'image/png', 'cache-control': 'public, max-age=31536000, immutable' });
      res.end(Buffer.from('89504e470d0a1a0a0000000d49484452000000010000000108060000001f15c4890000000a49444154789c6300010000050001', 'hex'));
      return;
    }
    res.writeHead(404, { 'cache-control': 'no-store' });
    res.end('nope');
  });
  return new Promise((resolve) => server.listen(port, '127.0.0.1', () => resolve({ server, log })));
}

probe.mjs

// What each "reset" actually resets. Drives Playwright's own Chromium against a
// local instrumented origin and reports, for each reset strategy, whether the
// second visit still carried a cookie, still had localStorage, and still served
// the cacheable subresource from cache instead of the network.
//
//   npm i playwright && npx playwright install chromium
//   node scripts/state_probe/probe.mjs
//
// Read as: a ✓ under "cookie", "localStorage" or "cache hit" means state
// SURVIVED the reset. A stateless crawl needs all three to be ✗.
import fs from 'node:fs';
import os from 'node:os';
import path from 'node:path';
import { chromium } from 'playwright';
import { startServer } from './server.mjs';
 
const PORT = 8123;
const TARGET = `http://127.0.0.1:${PORT}/`;
const { server, log } = await startServer(PORT);
 
const tmp = () => fs.mkdtempSync(path.join(os.tmpdir(), 'pw-profile-'));
 
// Visit the page and report what the origin saw and what the page found.
async function visit(page) {
  const before = log.length;
  await page.goto(TARGET, { waitUntil: 'load' });
  await page.waitForTimeout(400);
  const hits = log.slice(before);
  return {
    cookieSentOnDoc: hits.find((h) => h.path === '/')?.cookie ?? null,
    cachedJsFromNetwork: hits.some((h) => h.path === '/cached.js'),
    cachedPngFromNetwork: hits.some((h) => h.path === '/cached.png'),
    // __lsBefore is what the page found BEFORE writing its own marker, so it is
    // non-null only when localStorage genuinely survived into this visit.
    lsCarriedIn: await page.evaluate(() => window.__lsBefore ?? null),
    lsNow: await page.evaluate(() => localStorage.getItem('ls')),
    jarCookies: (await page.context().cookies()).map((c) => c.name).sort().join(','),
  };
}
 
const mark = (b) => (b ? '✓' : '✗');
const results = [];
const record = (strategy, second) =>
  results.push({
    strategy,
    cookie: mark(!!second.cookieSentOnDoc),
    localStorage: mark(second.lsCarriedIn !== null),
    cacheHit: mark(!second.cachedJsFromNetwork),
    detail:
      `visit 2 sent Cookie: ${second.cookieSentOnDoc ?? '(none)'}; ` +
      `localStorage carried in: ${second.lsCarriedIn ?? '(none)'}; ` +
      `/cached.js re-requested from origin: ${second.cachedJsFromNetwork ? 'yes' : 'no'}`,
  });
 
// 1. Same page object, second navigation.
{
  const b = await chromium.launch();
  const c = await b.newContext();
  const p = await c.newPage();
  await visit(p);
  record('nothing — second page.goto() in the same context', await visit(p));
  await b.close();
}
// 2. New page in the same context.
{
  const b = await chromium.launch();
  const c = await b.newContext();
  await visit(await c.newPage());
  record('context.newPage()', await visit(await c.newPage()));
  await b.close();
}
// 3. context.clearCookies() only.
{
  const b = await chromium.launch();
  const c = await b.newContext();
  const p = await c.newPage();
  await visit(p);
  await c.clearCookies();
  record('context.clearCookies()', await visit(p));
  await b.close();
}
// 4. clearCookies() + clearPermissions() (the usual "we cleared cookies" claim).
{
  const b = await chromium.launch();
  const c = await b.newContext();
  const p = await c.newPage();
  await visit(p);
  await c.clearCookies();
  await c.clearPermissions();
  record('clearCookies() + clearPermissions()', await visit(p));
  await b.close();
}
// 5. New browser CONTEXT in the same browser process.
{
  const b = await chromium.launch();
  const c1 = await b.newContext();
  await visit(await c1.newPage());
  const c2 = await b.newContext();
  record('browser.newContext() — new context, same browser process', await visit(await c2.newPage()));
  await b.close();
}
// 6. Fresh browser.launch() — Playwright's non-persistent default.
{
  const b1 = await chromium.launch();
  await visit(await (await b1.newContext()).newPage());
  await b1.close();
  const b2 = await chromium.launch();
  record('fresh chromium.launch() (Playwright default, no user-data-dir)', await visit(await (await b2.newContext()).newPage()));
  await b2.close();
}
// 7. launchPersistentContext, same user-data-dir, relaunched.
{
  const dir = tmp();
  const c1 = await chromium.launchPersistentContext(dir);
  await visit(await c1.newPage());
  await c1.close();
  const c2 = await chromium.launchPersistentContext(dir);
  record('launchPersistentContext() twice on the SAME user-data-dir', await visit(await c2.newPage()));
  await c2.close();
}
// 8. launchPersistentContext, same dir, clearCookies() in between.
{
  const dir = tmp();
  const c1 = await chromium.launchPersistentContext(dir);
  await visit(await c1.newPage());
  await c1.close();
  const c2 = await chromium.launchPersistentContext(dir);
  await c2.clearCookies();
  record('same user-data-dir + clearCookies() on relaunch', await visit(await c2.newPage()));
  await c2.close();
}
// 9. storageState round-trip: the documented way to carry a profile on purpose.
{
  const b = await chromium.launch();
  const c1 = await b.newContext();
  await visit(await c1.newPage());
  const state = await c1.storageState();
  await c1.close();
  const c2 = await b.newContext({ storageState: state });
  record('storageState() saved and reloaded into a new context', await visit(await c2.newPage()));
  await b.close();
  fs.writeFileSync(
    path.join(import.meta.dirname, 'storagestate-sample.json'),
    JSON.stringify(state, null, 1)
  );
}
 
const W = Math.max(...results.map((r) => r.strategy.length));
console.log(
  ['Reset between visit 1 and visit 2'.padEnd(W), 'cookie', 'localStorage', 'cache hit'].join('  ')
);
console.log([('-'.repeat(W)), '------', '------------', '---------'].join('  '));
for (const r of results)
  console.log([r.strategy.padEnd(W), r.cookie.padEnd(6), r.localStorage.padEnd(12), r.cacheHit].join('  '));
console.log('\n✓ = the state SURVIVED the reset and visit 2 saw it. A stateless crawl needs ✗ in all three columns.');
console.log('"cache hit" ✓ means the immutable subresource was NOT re-requested from the origin.\n');
for (const r of results) console.log(`  ${r.strategy}\n      ${r.detail}`);
{
  const pkg = JSON.parse(
    fs.readFileSync(new URL('./package.json', import.meta.resolve('playwright')), 'utf8')
  );
  const b = await chromium.launch();
  console.log(`\nplaywright ${pkg.version}; chromium ${b.version()}; ${process.platform}`);
  await b.close();
}
server.close();

All figures below are over the 1,120 papers in the corpus that ran an automated web crawl, out of 5,859 extracted papers from CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026. They are reporting rates: “does not state” means the paper did not say, not that the crawl had no state. The figures come from three scripts — report_stateful_stateless.mjs for the tables, statefulness_audit.mjs for the 29-paper adjudication, statefulness_probe.mjs for the text-corroboration counts — and the full query log, with each script's unedited output, is on stateful_stateless.

219 of 1,120 (19.6%) state it. Among those 219: stateless 51.6%, stateful 35.2%, both arms 13.2%. Against the other configuration fields the same papers could have reported:

An external cross-check disagrees, informatively — and it is a close comparison, because it covers the same seven venues. Demir et al. hand-coded 117 web-measurement papers from 2016–2021 against 18 reproducibility criteria; their criterion C11, “describe crawling strategy”, derived from exactly this design question, was omitted by 41%, partially met by 12% and fully satisfied by 44% [23Demir, Nurullah; Große-Kampmann, Matteo; Urban, Tobias; Wressnegger, Christian; Holz, Thorsten; Pohlmann, Norbert (2022): "Reproducibility and Replicability of Web Measurement Studies", in: Proceedings of the ACM Web Conference. (DOI)]. Partial plus satisfied is 56%, which is 2.9 times our 19.6%.¹¹⁾ Both can be right, and the reason is not venue coverage: their 117 papers are hand-picked as web measurements from those venues, while our 1,120 are every paper the extraction found to have run a crawl, including a long tail that crawls incidentally to something else. Their “crawling strategy” is also read more broadly than the stateful/stateless enum. Treat 19.6% as the rate across everything that crawls in these venues, and ~56% as the rate among papers whose main contribution is a web measurement.

This is the finding, and it is easiest to see against reporting norms that did move. Same buckets, same corpus:

Artifact release more than tripled and ethics-review reporting more than quadrupled. Statefulness has sat between 16% and 21% throughout, with no trend. It is also the flattest of the crawl-configuration fields, which is the sharper version of the claim because those fields compete for the same paragraph of the same methods section:

Denominators are the crawling papers in each bucket, from the table above (102 / 167 / 308 / 345 / 198). Naming the browser gained 18 points and headless mode gained 10 from a near-zero base; statefulness gained 2.5 and has the narrowest range of the six (5.3 pp). Interaction depth is the only field whose range is nearly as narrow (6.2 pp), and it got that way by declining from 78.4% to 72.2% rather than by standing still. It is not that the field decided the axis does not matter — Demir et al. made it a named criterion in 2022, and Zeber et al. and Jueckstock et al. had made it a measured concern in 2020 and 2021. It is that nothing turned the concern into a reporting norm: no venue asks for it on a checklist, and no widely used tool writes it into a config file that ends up in an artifact.

What did move is the answer among those who give one: the stateless share of stated values rose from 43.8% into the 50s (50.8%, 59.2%, 52.8% over the last three buckets). Read this as the field's default hardening rather than as a swing in practice — the whole cell is small (16 papers in the first bucket), and the modern tooling defaults to stateless.

PETS states it at 34.1% — about 60% more often than the next venue (IMC, 21.2%) and two and a half times as often as USENIX Security (13.6%) — and holds 9 of the 29 both-arms papers on just over half of USENIX's crawling volume. PETS is where this reporting norm is strongest.

OpenWPM papers state it at six times the rate of papers that do not name a framework, and twice the rate of Selenium papers. The mechanism is not virtue but interface: OpenWPM's CommandSequence has a reset argument and its documentation names the choice, so authors have a word for what they did. Selenium hands you a fresh session and no vocabulary. (OpenWPM reports 33 of 60 (55.0%) using a wider definition of “an OpenWPM paper” — any tools[] tuple whose name matches OpenWPM, regardless of the category the extractor filed it under, and without restricting to the crawling population. Applying that name match inside the crawling population gives 33 of 59 (55.9%). Both definitions are computed by this page's report script, so the two pages cannot drift.)

The consent row needs a caveat that consent supplies: the same 36 papers were hand-audited there and 7 (19.4%) turned out to be extraction false positives — they never touched a banner. The second row recomputes the rate on the 28 the audit fully supported (a 29th is supported but with an overstated enum value), and it barely moves, so the finding is robust to the error.

The good news first: where the design makes the axis unavoidable, reporting roughly triples. A login is state, and 39 of the 54 login crawls that say anything say stateful. The bad news is the repeat-visit row: 199 papers visit the same target two or more times and 114 of them (57.3%) never say whether state carried between the visits — which is the one thing that determines whether the repeat visit is a replication or a second step in a sequence. If you take one reporting rule from this page, take that one.

Folding the 219 stating papers by subject matter (keyword match over slug, detection.phenomenon and classification target) shows the two vocabularies of Two words, two literatures both present, and shows that “stateful” leans towards application-security scanning:

In the tracking literature stateless outnumbers stateful more than two to one; in the scanning literature it is the reverse, because there “state” means the application's own session and database, and coverage depends on reaching it. The 45-paper residue is largely papers that are not web crawls in either sense — an NTP-pool robustness study, a carrier-grade-NAT deployment study, a commercial-VPN ecosystem study, a 5G performance study, several underground-marketplace studies — and it is printed in full in the report output so it does not vanish quietly.

The 29 papers labelled both are the page's most load-bearing set: they are the studies that ran a stateful and a stateless arm and can therefore tell you what the choice costs. Because crawlConfig carries one evidence quote for the whole configuration object, the dataset's usual “spot-check the quote” discipline cannot validate this field at all — the quote behind a statefulness value is as likely to be evidence for the browser or the interaction depth. So all 29 were read in full against their own text.

So the corpus holds 16 genuine comparison studies out of 1,120 crawling papers (1.4%), not 29 (2.6%). Use the 16 as a reading list and not the 29. Here they are, with what the two arms actually were:

Ten more are labelled both but contrast something else — a login, a seeded profile, an extension, a consent step — and three have no statefulness contrast at all. Across all 219 stated values, a mechanical text probe finds a state-management sentence in the paper's own text for 178 (81.3%) and none for 41 (18.7%); the shared configuration quote itself contains a state term for only 72 (32.9%), which is the clearest possible demonstration that it is not evidence for this field. The 18.7% is an upper bound on false positives, not a measurement of them — hand-reading showed some are misses by the probe's regex rather than errors in the extraction. Full verdicts and reasoning: stateful_stateless.

• Population. crawled = a crawl-configuration record exists or studyTypes includes automated-web-crawl: 1,120 papers. 1,080 of them have a configuration record; the field can only be stated on those, so 19.6% (of 1,120) and 20.3% (of 1,080) are both correct and the page uses the first, because a paper with no configuration record has certainly not told you.
• Stability. crawlConfig.statefulness agreed on 98% of papers between two independent extraction runs over identical text, which is why exact percentages are published here rather than rankings. That figure was measured on the previous, 4,322-paper corpus and has not been re-measured on this one; treat it as the right order of magnitude.
• The evidence quote does not evidence this field. See The comparison studies, audited. This is the single biggest threat to every number above, and it is why the audit exists.
• Reporting, not practice. 75.4% “not stated” is a claim about papers, not about crawls.
• Seven venues. EuroS&P, ACSAC, RAID, AsiaCCS, CHI and SOUPS are absent, so this is a claim about CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P.
• Full query log, folding rules, residue, quote checks and reviewer findings: stateful_stateless. Corpus-level caveats: corpus.

Demir et al. set the bar [23Demir, Nurullah; Große-Kampmann, Matteo; Urban, Tobias; Wressnegger, Christian; Holz, Thorsten; Pohlmann, Norbert (2022): "Reproducibility and Replicability of Web Measurement Studies", in: Proceedings of the ACM Web Conference. (DOI)]:

authors need to document what part of a browser profile is maintained statefully, what part is reset, and when

Concretely, one short paragraph in your methodology, covering:

1. Stateful, stateless or seeded, in those words.
2. The unit of the reset — per page visit, per site, per browser instance, per crawl.
3. What exactly is reset, given that “we cleared cookies” leaves localStorage and the cache: name the storage kinds, or name the mechanism (a fresh user-data-dir, a new BrowserContext, CommandSequence(reset=True)).
4. The seed's provenance, if any: what built it, when, over which sites, and whether it is published as an artefact.
5. Number of parallel browsers, alongside the stateful claim, because N browsers is N users.
6. Visit order and whether it was randomised, with the seed, if the crawl was stateful.
7. The engine's partitioning posture: which browser and version, and whether third-party cookie or storage partitioning was on. In 2026 this is not a detail — see Since 2022 the engine decides, not you.

One sentence that does all of it: “OpenWPM 0.35.0 (its pinned unbranded Firefox build), stateful with num_browsers=1 and tp_cookies=“always” (third-party cookies allowed, unpartitioned), visit order randomised with seed 20260819, profile dumped after each 1,000 sites and published.”

1. Default to stateless unless your question needs accumulation. It parallelises, it is order-independent, and every visit is an independent observation, which is what the statistics on Hypothesis testing assume.
2. Say so anyway. Getting it by default is not the same as reporting it, and 75.4% of the crawling papers in this corpus did not.
3. If you need state, prefer seeded-stateless to a rolling profile. You keep a non-empty starting state and lose the order confound. Publish the seed.
4. If you need a rolling profile, run one browser or report how many you ran and how the site list was partitioned across them.
5. Never claim a reset you did not measure. Run the probe against your own harness once; it takes a minute and it is the cheapest methodological insurance on this page.
6. Do not compare your numbers to a paper on the other side of this axis without saying so. Third-party counts from a fresh-profile crawl and from an aged profile are different quantities.
7. State the engine's partitioning posture, and if you disable partitioning to get cross-site accumulation, say that you did and why.

1. [2Englehardt, Steven; Narayanan, Arvind (2016): "Online Tracking: A 1-million-site Measurement and Analysis", in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1388–1401. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] — the reference implementation of both modes. Read §3.3 for the cost of statefulness and §4 for the seed-profile design and its artefact. Everything later argues with this paper.
2. [8Zeber, David; Bird, Sarah; Oliveira, Camila; Rudametkin, Walter; Segall, Ilana; Wolls´en, Fredrik; Lopatka, Martin (2020): "The Representativeness of Automated Web Crawls as a Surrogate for Human Browsing", in: Proceedings of The Web Conference 2020, pp. 167–178. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] — how far a crawl is from a user. The numbers you will be asked about in review.
3. [23Demir, Nurullah; Große-Kampmann, Matteo; Urban, Tobias; Wressnegger, Christian; Holz, Thorsten; Pohlmann, Norbert (2022): "Reproducibility and Replicability of Web Measurement Studies", in: Proceedings of the ACM Web Conference. (DOI)] — what to write down. Criterion C11 and practice P9 are the reporting standard; the paper also measures how badly the field met it.
4. [14Rasaii, 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)] — the modern stateful design, done well. Split the list, accept on the first half, measure the second half, randomise the order. The clearest recent example of a result that a stateless crawl cannot produce.
5. [3Urban, Tobias; Degeling, Martin; Holz, Thorsten; Pohlmann, Norbert (2020): "Beyond the Front Page:Measuring Third Party Dynamics in the Field", in: Proceedings of The Web Conference 2020, pp. 1275–1286. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] — seeded stateless, and why. One sentence in §4.3.2 explains the whole third design position.
6. [6Acar, Gunes; Eubank, Christian; Englehardt, Steven; Juarez, Marc; Narayanan, Arvind; Díaz, Claudia (2014): "The Web Never Forgets: Persistent Tracking Mechanisms in the Wild", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] — why a clean profile is hard. Respawning and syncing across a deliberate state clear.
7. [4Agarwal, Pushkal; Joglekar, Sagar; Papadopoulos, Panagiotis; Sastry, Nishanth; Kourtellis, Nicolas (2020): "Stop tracking me Bro! Differential Tracking of User Demographics on Hyper-Partisan Websites", in: Proceedings of the ACM Web Conference. (DOI)] — train stateful, measure stateless. The hybrid pattern most personalisation work now uses.
8. [22Song, Chuxu; Mekala, Dheekshith Dev Manohar; Wang, Hao; Martin, Richard (2026): "Redefining Website Fingerprinting Attacks with Multi-Agent LLMs", in: Proceedings on Privacy Enhancing Technologies, pp. 688-702. (DOI)] — the 2026 version of the realism problem. Models trained on scripted-crawler traffic score under 10% on real users; LLM-agent personas close most of the gap.
9. [7Jueckstock, Jordan; Sarker, Shaown; Snyder, Peter; Beggs, Aidan; Papadopoulos, Panagiotis; Varvello, Matteo; Livshits, Benjamin; Kapravelos, Alexandros (2021): "Towards Realistic and Reproducible Web Crawl Measurements", in: Proceedings of the ACM Web Conference. (DOI)] — the neighbouring axis. Vantage point and browser configuration, with every crawl launched from “a clean user profile”. Often cited as varying statefulness; it does not. See Crawling location for that axis.

• Nobody has run the clean experiment. Demir et al. announce one and do not deliver it: §2.2 says “Since the effects of C5 and C11 are not yet adequately discussed by previous work, we analyze them in Section 4”, and §4 then runs “four exemplarily case studies focusing on C4, C5, C10, and C12” — repetition, crawler technology, interaction and geolocation. C11, the crawling strategy, is the one criterion they flagged and did not vary; their own runs are described in Appendix C as “stateless coordinated crawls” [23Demir, Nurullah; Große-Kampmann, Matteo; Urban, Tobias; Wressnegger, Christian; Holz, Thorsten; Pohlmann, Norbert (2022): "Reproducibility and Replicability of Web Measurement Studies", in: Proceedings of the ACM Web Conference. (DOI)]. Sixteen papers in this corpus run both arms, every one of them incidentally to another question. A same-sites, same-time, same-vantage crawl differing only in statefulness, reporting the effect on third-party counts, tracker counts and filter-list hit rates, would be a short and highly citable paper.
• How much does visit order actually change a stateful result? The confound is universally acknowledged and never quantified.
• Does the seed profile artefact bite? Englehardt and Narayanan predicted that cloning one seed into N browsers inflates cookie-sync counts. Nobody has measured the size of the inflation, and it is the design large stateful crawls have used since.
• What does statefulness mean under partitioning? If a stateful crawl's cross-site accumulation is the thing being measured, and every default browser now partitions storage while the research tooling either disables the partitioning (Playwright, OpenWPM — both verified above) or predates it entirely, then the stateful/stateless dichotomy needs a third dimension. No paper in the corpus addresses this, and the ground is still moving: Playwright's opt-out is expected to become unavailable when Chromium removes the flag, at which point every Playwright-based crawl changes behaviour without any change to the paper's own code.
• Does the per-browser cookie-jar partition change published results? Carried over from OpenWPM because it is the same question: no paper we found reports num_browsers alongside a stateful claim.

[1]

Jueckstock, Jordan; Snyder, Peter; Sarker, Shaown; Kapravelos, Alexandros; Livshits, Benjamin (2022): "Measuring the Privacy vs. Compatibility Trade-off in Preventing Third-Party Stateful Tracking", in: Proceedings of the ACM Web Conference. (DOI)

[2]

Englehardt, Steven; Narayanan, Arvind (2016): "Online Tracking: A 1-million-site Measurement and Analysis", in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 1388–1401. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[3]

Urban, Tobias; Degeling, Martin; Holz, Thorsten; Pohlmann, Norbert (2020): "Beyond the Front Page:Measuring Third Party Dynamics in the Field", in: Proceedings of The Web Conference 2020, pp. 1275–1286. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[4]

Agarwal, Pushkal; Joglekar, Sagar; Papadopoulos, Panagiotis; Sastry, Nishanth; Kourtellis, Nicolas (2020): "Stop tracking me Bro! Differential Tracking of User Demographics on Hyper-Partisan Websites", in: Proceedings of the ACM Web Conference. (DOI)

[5]

Solomos, Konstantinos; Kristoff, John; Kanich, Chris; Polakis, Jason (2021): "Tales of Favicons and Caches: Persistent Tracking in Modern Browsers", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[6]

Acar, Gunes; Eubank, Christian; Englehardt, Steven; Juarez, Marc; Narayanan, Arvind; Díaz, Claudia (2014): "The Web Never Forgets: Persistent Tracking Mechanisms in the Wild", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[7]

Jueckstock, Jordan; Sarker, Shaown; Snyder, Peter; Beggs, Aidan; Papadopoulos, Panagiotis; Varvello, Matteo; Livshits, Benjamin; Kapravelos, Alexandros (2021): "Towards Realistic and Reproducible Web Crawl Measurements", in: Proceedings of the ACM Web Conference. (DOI)

[8]

Zeber, David; Bird, Sarah; Oliveira, Camila; Rudametkin, Walter; Segall, Ilana; Wolls´en, Fredrik; Lopatka, Martin (2020): "The Representativeness of Automated Web Crawls as a Surrogate for Human Browsing", in: Proceedings of The Web Conference 2020, pp. 167–178. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[9]

Fouad, Imane; Santos, Cristiana; Legout, Arnaud; Bielova, Nataliia (2022): "My Cookie is a phoenix: Detection, measurement, and lawfulness of cookie respawning with browser fingerprinting", in: PETS 2022-22nd Privacy Enhancing Technologies Symposium. (DOI) (Link)

[10]

Bashir, Muhammad Ahmad; Arshad, Sajjad; Robertson, William; Wilson, Christo (2016): "Tracing information flows between ad exchanges using retargeted ads", in: 25th USENIX Security Symposium (USENIX Security 16), pp. 481-496. (Link)

[11]

Liu, Zengrui; Iqbal, Umar; Saxena, Nitesh (2024): "Opted Out, Yet Tracked: Are Regulations Enough to Protect Your Privacy?", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[12]

Meng, Wei; Xing, Xinyu; Sheth, Anmol; Weinsberg, Udi; Lee, Wenke (2014): "Your Online Interests: Pwned! A Pollution Attack Against Targeted Advertising", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[13]

Robertson, Ronald E.; Lazer, David; Wilson, Christo (2018): "Auditing the Personalization and Composition of Politically-Related Search Engine Results Pages", in: Proceedings of the ACM Web Conference. (DOI)

[14]

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)

[15]

Kancherla, Gayatri Priyadarsini; Bielova, Nataliia; Santos, Cristiana; Bichhawat, Abhishek (2025): "Johnny Can't Revoke Consent Either: Measuring Compliance of Consent Revocation on the Web", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[16]

Kaizer, Andrew J.; Gupta, Minaxi (2016): "Characterizing Website Behaviors Across Logged-in and Not-logged-in Users", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[17]

Rautenstrauch, Jannis; Mitkov, Metodi; Helbrecht, Thomas; Hetterich, Lorenz; Stock, Ben (2024): "To Auth or Not To Auth? A Comparative Analysis of the Pre- and Post-Login Security Landscape", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[18]

Rautenstrauch, Jannis; Pellegrino, Giancarlo; Stock, Ben (2023): "The Leaky Web: Automated Discovery of Cross-Site Information Leaks in Browsers and the Web", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[19]

Chen, Quan; Ilia, Panagiotis; Polychronakis, Michalis; Kapravelos, Alexandros (2021): "Cookie Swap Party: Abusing First-Party Cookies for Web Tracking", in: Proceedings of the ACM Web Conference. (DOI)

[20]

Mirheidari, Seyed Ali; Golinelli, Matteo; Onarlioglu, Kaan; Kirda, Engin; Crispo, Bruno (2022): "Web Cache Deception Escalates!", in: Proceedings of the USENIX Security Symposium. (Link)

[21]

Matthews, Zachary; Vlajic, Natalija (2018): "Can Browser Add-Ons Protect Your Children from Online Tracking?", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[22]

Song, Chuxu; Mekala, Dheekshith Dev Manohar; Wang, Hao; Martin, Richard (2026): "Redefining Website Fingerprinting Attacks with Multi-Agent LLMs", in: Proceedings on Privacy Enhancing Technologies, pp. 688-702. (DOI)

[23]

Demir, Nurullah; Große-Kampmann, Matteo; Urban, Tobias; Wressnegger, Christian; Holz, Thorsten; Pohlmann, Norbert (2022): "Reproducibility and Replicability of Web Measurement Studies", in: Proceedings of the ACM Web Conference. (DOI)

[24]

Fouad, Imane; Santos, Cristiana; Laperdrix, Pierre (2024): "The Devil is in the Details: Detection, Measurement and Lawfulness of Server-Side Tracking on the Web", Proceedings on Privacy Enhancing Technologies 2024(4):450-465. (DOI)

[25]

Pan, Xiang; Cao, Yinzhi; Chen, Yan (2015): "I Do Not Know What You Visited Last Summer: Protecting Users from Third-party Web Tracking with TrackingFree Browser", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[26]

Englehardt, Steven; Han, Jeffrey; Narayanan, Arvind (2018): "I never signed up for this! Privacy implications of email tracking", Proceedings on Privacy Enhancing Technologies 2018(1):109-126. (DOI)

[27]

Mehrnezhad, Maryam; Coopamootoo, Kovila; Toreini, Ehsan (2022): "How Can and Would People Protect From Online Tracking?", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[28]

Ablove, Anna; Chandrashekaran, Shreyas; Qiang, Xiao; Ensafi, Roya (2026): "Characterizing the Implementation of Censorship Policies in Chinese LLM Services", in: Proceedings of the Network and Distributed System Security Symposium. (Link)