Every crawl runs in some tracking-protection state. Most crawls never say which one, and a good number are not in the state their authors think.

This page is about the browser's own anti-tracking machinery — Firefox's Enhanced Tracking Protection and Total Cookie Protection, Safari's Intelligent Tracking Prevention, Brave's Shields, Microsoft Edge's Tracking Prevention, and the protections built into Tor Browser, DuckDuckGo and Firefox Focus — used as an experimental treatment: you crawl the same population twice, once with the protection on and once with it off, and the difference is your result. It is also about the same machinery as a confounder, because it is on by default in every mainstream browser except Chrome, and your automation library has an opinion about it that it did not tell you.

Three neighbours own the parts this page does not. Filter lists is the list as an instrument — EasyList, EasyPrivacy, Disconnect, and why “blocked implies tracker” is circular; the protections here mostly consume those lists. Requests and Fingerprinting assume the default browser and describe what you classify once you have the requests. And a page on the privacy of browser extensions is a different topic again: what an extension leaks about you, not what it blocks.

• 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)], TheWebConf 2022 — the design to copy. Four third-party storage policies, two instances of each, eight crawls in parallel over the same URL list. Read §3.1 before you write a single line of harness code.
• OmniCrawl [2Cassel, Darion; Lin, Su-Chin; Buraggina, Alessio; Wang, William; Zhang, Andrew; Bauer, Lujo; Hsiao, Hsu-Chun; Jia, Limin; Libert, Timothy (2022): "OmniCrawl: Comprehensive Measurement of Web Tracking With Real Desktop and Mobile Browsers", in: Proceedings on Privacy Enhancing Technologies. (DOI)], PoPETs 2022 — the largest arm set in this corpus: 42 browser instances in parallel across four desktops and eighteen Android phones, in two locations. Read it for what it costs to do this properly, and for its finding that how you drive the browser is itself a treatment.
• Who Left Open the Cookie Jar? [3Franken, Gertjan; Van Goethem, Tom; Joosen, Wouter (2018): "Who Left Open the Cookie Jar? A Comprehensive Evaluation of Third-Party Cookie Policies", in: Proceedings of the USENIX Security Symposium. (Link)], USENIX Security 2018 — seven browsers and forty-six extensions against a generated test-case suite. The template for “does this protection do what it says”, as opposed to “what does the web look like under it”.
• Bridges to Self [4Vlummens, Tim; Girish, Aniketh; Weerasekara, Nipuna; Zuiderveen Borgesius, Frederik; Acar, Gunes; Vallina-Rodriguez, Narseo (2026): "Bridges to Self: Silent Web-to-App Tracking on Mobile via Localhost", in: Proceedings of the USENIX Security Symposium. (Link)], USENIX Security 2026 — the most recent per-protection test in the corpus, and the one that shows why the level matters: ETP blocked the Meta Pixel in Strict and not in Standard.
• Navigating Murky Waters [5Ali, Mir Masood; Chitale, Binoy; Ghasemisharif, Mohammad; Kanich, Chris; Nikiforakis, Nick; Polakis, Jason (2023): "Navigating Murky Waters: Automated Browser Feature Testing for Uncovering Tracking Vectors", in: Proceedings of the Network and Distributed System Security Symposium. (Link)], NDSS 2023 — 126 versions of seven browsers over two years. Read it before you assume a protection is a fixed thing you can name once.
• Then the vendor documentation, because no paper is current. Every table below was checked against it on 2026-09-01.

A protection is a moving target with a name that outlives its behaviour. “Safari blocks third-party cookies” is true in 2026 and was false in 2018 under the same product name. If your measurement spans a shipping date, the browser is a variable.

Edge's Balanced level depends on your profile's history, not only on the setting. Edge relaxes tracking prevention for organisations with which the profile has “an ongoing relationship (currently defined by a site engagement score of 4.1 or greater)”, and the mitigation “is currently only applied in Balanced mode”. A crawler profile is fresh on every site, so it has a site-engagement score of zero everywhere and gets the strictest version of Balanced that any user ever gets. That is not the population's Balanced. Edge also maintains a CompatExceptions list of sites exempted from enforcement, shipped on disk with the browser.

Under Edge, more protection can look like less blocking. Microsoft's own documentation says it outright: “Strict mode blocks more resource loads than Balanced. The blocking of more resource loads may result in Strict mode appearing to block less tracking requests than Balanced since the trackers making the requests are never loaded.” If your metric is number of tracking requests blocked, it is not monotone in protection strength. Count requests observed, against a permissive baseline, instead.

Firefox's “off” for bounce tracking is a dry run, not off. In the Firefox build examined here, the category rule that turns Bounce Tracking Protection off sets privacy.bounceTrackingProtection.mode to MODE_ENABLED_DRY_RUN, with the source comment “We currently consider MODE_ENABLED_DRY_RUN the 'off' state.” The classifier still runs and still records; only the purge is suppressed. If you are measuring bounce tracking, that is the difference between a control and a quiet treatment.

On the Chromium side, bounce tracking has first-class CDP instrumentation that no paper in the corpus names (a full-text sweep for either command string returns zero): Storage.runBounceTrackingMitigations and Storage.getRelatedWebsiteSets are both present in Chromium 151.0.7922.34 and at devtools-protocol tip-of-tree, unlike the Privacy Sandbox commands next to them, which are being removed (Chrome DevTools Protocol: what it covers, and for how long). runBounceTrackingMitigations forces the purge instead of waiting for the heuristic to fire, which is what you want in an arm rather than in a user's browser.

This is the whole page in one experiment. Two local HTTPS origins, a third party in an iframe setting a cookie two ways, and seven runs of six distinct Chromium configurations that a reasonable person would expect to differ — the default configuration is run twice on purpose, which is what makes the one real difference readable.

bp_arms_probe.mjs

// Does the "protection on" arm of a paired crawl actually have the protection on?
//
// Stands up two local HTTPS origins (a first party and a third party), embeds the
// third party in an iframe, and has it try to set and read a cookie. Then runs the
// same page under several Chromium configurations and prints what each arm saw.
// The point is not the cookie: it is that an arm has to be VERIFIED, not assumed.
// The default arm is run twice, on purpose: two instances of the SAME condition are
// what tell you how much of an arm-to-arm difference is noise rather than treatment.
//
//   PLAYWRIGHT_BROWSERS_PATH=/workspace/.playwright node sandbox/bp_arms_probe.mjs
import https from 'node:https';
import { execSync } from 'node:child_process';
import fs from 'node:fs';
import os from 'node:os';
import path from 'node:path';
import { chromium } from 'playwright';
 
const dir = fs.mkdtempSync(path.join(os.tmpdir(), 'bparms-'));
execSync(
  `openssl req -x509 -newkey rsa:2048 -nodes -keyout ${dir}/k.pem -out ${dir}/c.pem ` +
  `-days 2 -subj "/CN=first.example" ` +
  `-addext "subjectAltName=DNS:first.example,DNS:third.example"`,
  { stdio: 'ignore' }
);
const tls = { key: fs.readFileSync(`${dir}/k.pem`), cert: fs.readFileSync(`${dir}/c.pem`) };
 
const FIRST_PORT = 8443, THIRD_PORT = 8444;
const firstPage = `<!doctype html><title>first party</title>
<iframe id="f" src="https://third.example:${THIRD_PORT}/frame"></iframe>`;
const thirdFrame = `<!doctype html><title>third party</title><script>
  document.cookie = 'tp=set-from-js; SameSite=None; Secure; path=/';
  const seen = document.cookie;
  fetch('/report?jar=' + encodeURIComponent(seen), {credentials:'include'});
  parent.postMessage({jsCookie: seen}, '*');
</script>`;
 
const reports = [];
const srvFirst = https.createServer(tls, (req, res) => {
  res.writeHead(200, { 'content-type': 'text/html' });
  res.end(firstPage);
}).listen(FIRST_PORT);
const srvThird = https.createServer(tls, (req, res) => {
  if (req.url.startsWith('/report')) {
    reports.push({ cookieHeader: req.headers.cookie ?? null, url: req.url });
    res.writeHead(204); res.end(); return;
  }
  res.writeHead(200, {
    'content-type': 'text/html',
    'set-cookie': 'tp_http=set-from-header; SameSite=None; Secure; Path=/',
  });
  res.end(thirdFrame);
}).listen(THIRD_PORT);
 
const ARMS = [
  { label: 'default (no extra flags), run 1',       args: [] },
  { label: 'default (no extra flags), run 2',       args: [] },
  { label: '--test-third-party-cookie-phaseout',    args: ['--test-third-party-cookie-phaseout'] },
  { label: '--block-third-party-cookies (no such switch)', args: ['--block-third-party-cookies'] },
  { label: '--incognito',                           args: ['--incognito'] },
  { label: 'CDP Network.setCookieControls(true)',    args: [], cdpControls: true },
  { label: 'CDP Storage.setThirdPartyCookieBlocking', args: [], cdpBlock: true },
];
 
const rows = [];
for (const arm of ARMS) {
  reports.length = 0;
  const browser = await chromium.launch({
    args: [
      '--ignore-certificate-errors',
      `--host-resolver-rules=MAP first.example 127.0.0.1, MAP third.example 127.0.0.1`,
      ...arm.args,
    ],
  });
  const ctx = await browser.newContext({ ignoreHTTPSErrors: true });
  const page = await ctx.newPage();
  let cdpErr = null;
  if (arm.cdpBlock || arm.cdpControls) {
    const cdp = await ctx.newCDPSession(page);
    const [cmd, params] = arm.cdpControls
      ? ['Network.setCookieControls', { enableThirdPartyCookieRestriction: true }]
      : ['Storage.setThirdPartyCookieBlocking', { enabled: true }];
    try { await cdp.send('Network.enable'); await cdp.send(cmd, params); }
    catch (e) { cdpErr = String(e.message).split('\n')[0]; }
  }
  let jsCookie = null;
  await page.exposeFunction('__report', (v) => { jsCookie = v; });
  await page.addInitScript(() => {
    addEventListener('message', (e) => { if (e.data && 'jsCookie' in e.data) window.__report(e.data.jsCookie); });
  });
  await page.goto(`https://first.example:${FIRST_PORT}/`, { waitUntil: 'networkidle' }).catch(() => {});
  await page.waitForTimeout(700);
  const jar = await ctx.cookies();
  rows.push({
    arm: arm.label,
    cdpErr,
    thirdPartyCookiesInJar: jar.filter((c) => c.domain.includes('third')).map((c) => c.name),
    jsSetCookieVisibleInFrame: jsCookie,
    cookieHeaderOnSubsequentRequest: reports.map((r) => r.cookieHeader),
  });
  await browser.close();
}
srvFirst.close(); srvThird.close();
 
const v = execSync(`${chromium.executablePath()} --version`).toString().trim();
console.log(`browser: ${v}`);
console.log(`playwright: ${JSON.parse(fs.readFileSync('node_modules/playwright/package.json','utf8')).version}\n`);
for (const r of rows) {
  console.log(`ARM ${r.arm}`);
  if (r.cdpErr) console.log(`  CDP error:                        ${r.cdpErr}`);
  console.log(`  third-party cookies in the jar:   ${JSON.stringify(r.thirdPartyCookiesInJar)}`);
  console.log(`  document.cookie inside the frame: ${JSON.stringify(r.jsSetCookieVisibleInFrame)}`);
  console.log(`  Cookie header the 3p then saw:    ${JSON.stringify(r.cookieHeaderOnSubsequentRequest)}`);
  console.log();
}

Its output, unedited, 2026-09-01:

browser: Chromium 151.0.7922.34
playwright: 1.62.1

ARM default (no extra flags), run 1
  third-party cookies in the jar:   ["tp_http","tp"]
  document.cookie inside the frame: "tp_http=set-from-header; tp=set-from-js"
  Cookie header the 3p then saw:    ["tp_http=set-from-header; tp=set-from-js"]

ARM default (no extra flags), run 2
  third-party cookies in the jar:   ["tp_http","tp"]
  document.cookie inside the frame: "tp_http=set-from-header; tp=set-from-js"
  Cookie header the 3p then saw:    ["tp_http=set-from-header; tp=set-from-js"]

ARM --test-third-party-cookie-phaseout
  third-party cookies in the jar:   ["tp_http","tp"]
  document.cookie inside the frame: "tp_http=set-from-header; tp=set-from-js"
  Cookie header the 3p then saw:    ["tp_http=set-from-header; tp=set-from-js"]

ARM --block-third-party-cookies (no such switch)
  third-party cookies in the jar:   ["tp_http","tp"]
  document.cookie inside the frame: "tp_http=set-from-header; tp=set-from-js"
  Cookie header the 3p then saw:    ["tp_http=set-from-header; tp=set-from-js"]

ARM --incognito
  third-party cookies in the jar:   ["tp_http","tp"]
  document.cookie inside the frame: "tp_http=set-from-header; tp=set-from-js"
  Cookie header the 3p then saw:    ["tp_http=set-from-header; tp=set-from-js"]

ARM CDP Network.setCookieControls(true)
  third-party cookies in the jar:   []
  document.cookie inside the frame: ""
  Cookie header the 3p then saw:    [null]

ARM CDP Storage.setThirdPartyCookieBlocking
  CDP error:                        cdpSession.send: Protocol error (Storage.setThirdPartyCookieBlocking): 'Storage.setThirdPartyCookieBlocking' wasn't found
  third-party cookies in the jar:   ["tp_http","tp"]
  document.cookie inside the frame: "tp_http=set-from-header; tp=set-from-js"
  Cookie header the 3p then saw:    ["tp_http=set-from-header; tp=set-from-js"]

Three notes on reading this. --test-third-party-cookie-phaseout is a real Chromium switch: the string appears twice in the binary. It nonetheless changed nothing on this path, and this run did not establish why. --block-third-party-cookies is not a switch — the string is absent from the binary — and Chromium accepted the command line without a warning, which is the general hazard: an obsolete or misremembered flag is indistinguishable from a working one unless you check the effect. And --incognito is real but inert here, because Playwright's newContext() opens its own browser context rather than Chrome's Incognito profile; the library routed around the switch.

Network.setCookieControls is marked experimental in the protocol descriptor and its description says “Page reload is required before the new cookie behavior will be observed”. Treat it the way Chrome DevTools Protocol: what it covers, and for how long treats the Privacy Sandbox commands: first-class today, and capable of vanishing in a milestone.

Firefox does not launch in this container, so the following is read from the shipped files of the build itself rather than from a running browser — stated as source-level, not measured.

Playwright 1.62.1 ships Firefox 153.0, BuildID 20260722045016. Firefox stable on 2026-09-01 is 155.0¹¹⁾ and the ESR line is 140.15.0esr, so the automation build is neither the current release nor the ESR that Tor Browser tracks.

Of the 86 preferences Playwright sets on that build at launch, four touch this page's subject:

The dead one is the interesting one. Firefox 153's own category logic (ContentBlockingPrefs.sys.mjs inside omni.ja) reads only browser.contentblocking.features.strict, and its comment says: “The 'standard' category is defined as expecting default values of the listed prefs. The 'strict' category lists all prefs that will be set according to the strict feature pref.” The cookieBehavior0 element of Playwright's string — the part that would have switched cookie handling to accept everything — has nothing to read it. Meanwhile that build's browser/defaults/preferences/firefox.js ships pref("network.cookie.cookieBehavior", 5), and the same file's mapping names 5 nsICookieService.BEHAVIOR_PARTITION_FOREIGN.

The practical reading: a Playwright-driven Firefox is very likely partitioning third-party storage, and the flag intended to stop that no longer does anything. Whether the runtime pref really is 5 was not measured here — the browser would not start. Read it back yourself, in one line, before you believe either version:

''%%await page.goto('about:config'); // then read network.cookie.cookieBehavior%%''

or set it explicitly at launch and stop depending on a category name:

// Firefox arm, stated rather than assumed. 0 = accept all (the "off" arm),
// 5 = partition third-party storage (Total Cookie Protection, the Standard default),
// 1 = reject all third-party cookies (closest to ETP Strict's cookie behaviour).
const browser = await firefox.launch({
  firefoxUserPrefs: {
    'network.cookie.cookieBehavior': 0,
    'privacy.trackingprotection.enabled': false,
    'privacy.annotate_channels.strict_list.enabled': false,
  },
});

The same discipline applies to Chromium: Partitioning: Your Crawler and a Real Browser Disagree records that Playwright disables ThirdPartyStoragePartitioning by default, which is the Chromium-side version of exactly this problem.

Both of the corpus's best cross-arm studies do this, independently, and neither treats it as optional.

[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)] “deployed two instances of each tested policy to verify behavioral consistency and provide similarity-score baselines”, and the paper's compatibility metric is defined against the similarity of the two permissive profiles to each other, not against a theoretical maximum. [2Cassel, Darion; Lin, Su-Chin; Buraggina, Alessio; Wang, William; Zhang, Andrew; Bauer, Lujo; Hsiao, Hsu-Chun; Jia, Limin; Libert, Timothy (2022): "OmniCrawl: Comprehensive Measurement of Web Tracking With Real Desktop and Mobile Browsers", in: Proceedings on Privacy Enhancing Technologies. (DOI)] “use two identical Chrome instances to measure the […] baseline variability between visits to the same website”. (The bracket marks a two-column splice in the extracted text, not an omission by us; see browser_protection.)

The reason is that the web moves under you. Ads rotate, A/B tests fire, consent banners differ, a CDN serves a different bundle. Two crawls of the same site in the same condition already disagree, and you cannot interpret a between-arm difference until you know by how much. The duplicate arm costs one more crawler and converts a number into a result.

The probe above does the same thing in miniature: its first two rows are the identical default condition, and they match exactly — which is what makes the setCookieControls row's empty jar readable as an effect.

• The URL list, and the order. [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)] ran a stateless pilot crawl with stock Chromium over the Tranco 1k, spidered three links deep, and froze the resulting 3,419 page URLs so all eight arms visited exactly the same sequence. Letting each arm discover its own links makes the arms incomparable, because a protection changes what links exist.
• Time. Run the arms in parallel, not one after the other. [7Hoang, Nguyen Phong; Niaki, Arian Akhavan; Gill, Phillipa; Polychronakis, Michalis (2021): "Domain name encryption is not enough: privacy leakage via IP-based website fingerprinting", Proceedings on Privacy Enhancing Technologies 2021(4):420-440. (DOI)] crawled its test websites with Brave “at the same time” as the unblocked crawl for exactly this reason.
• Vantage point. One network, or the geography becomes a second treatment — Crawling location.
• Statefulness. A fresh profile per visit and a persistent profile across visits measure different protections; ITP's 7-day script-writeable-storage cap and 24-hour link-decoration cap are invisible to a stateless crawl by construction. See Stateful stateless.
• Consent. A protection arm that also differs in banner handling is two treatments — Consent.
• The browser version. Pin it and report it; see What to Report.

The corpus can date the designs, and they have moved. Of the 26 hand-audited papers, 7 are from 2017–2021, 8 from 2022–2023 and 11 from 2024–2026 — so this is a live design, not a historical one, and the 2024–2026 slice is where to look for a template.

Two absences, against the 2026 expectation.

No LLM method appears in any of the 26. Searching all 26 for LLM, large language model, GPT-n, ChatGPT, Llama or Gemini returns exactly two hits, both in 2026 acknowledgements sections thanking ChatGPT for copy-editing — one of which adds “No content was generated related to technical results, data, code, or analysis” [13Dao, Ha; Shinde, Abhishek; Athar, Sana; Gosain, Devashish (2026): "Clicking into Exposure: Uncovering Privacy Risks of Google Click Identifier in YouTube Ads", Proceedings on Privacy Enhancing Technologies 2026(2):92-107. (DOI)]. That is not a gap in the literature so much as a fact about the subject: a tracking protection is a deterministic rule engine, and the LLM-classification wave that reached Cookies and Consent has nothing here to classify. If you were expecting to be told to use an LLM on this page, the honest answer is that nobody in this corpus has found a use for one.

Nobody varies headless versus headful as an arm, although three of the 26 chose headful deliberately and said why: [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)] ran “non-headless (i.e., rendering to the Xvfb headless display server)” so the crawlers had “a fair chance at evading the most trivial forms of bot detection”; [12Hausladen, Katherine; Wang, Oliver; Eng, Sophie; Wang, Jocelyn; Wijaya, Francisca; May, Matthew; Zimmeck, Sebastian (2025): "Websites' Global Privacy Control Compliance at Scale and over Time", in: Proceedings of the USENIX Security Symposium. (Link)] “uses non-headless mode to appear more similar to a human user”; [14Randall, Audrey; Snyder, Peter; Ukani, Alisha; Snoeren, Alex C.; Voelker, Geoffrey M.; Savage, Stefan; Schulman, Aaron (2022): "Measuring UID smuggling in the wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] used Puppeteer in “headful” mode under Xvfb for the same reason. Given that [2Cassel, Darion; Lin, Su-Chin; Buraggina, Alessio; Wang, William; Zhang, Andrew; Bauer, Lujo; Hsiao, Hsu-Chun; Jia, Limin; Libert, Timothy (2022): "OmniCrawl: Comprehensive Measurement of Web Tracking With Real Desktop and Mobile Browsers", in: Proceedings on Privacy Enhancing Technologies. (DOI)] shows how you drive the browser is itself a treatment, a protection arm that differs in headlessness from its control is two treatments — see Crawler detection.

Two corpus papers ran a “Safari” arm by sending Safari's User-Agent string from headless Chrome: [15Dimova, Yana; Acar, Gunes; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (2021): "The CNAME of the game: Large-scale analysis of DNS-based tracking evasion", Proceedings on Privacy Enhancing Technologies 2021:394–412. (DOI) (Link)] “performed the experiment twice: once with the Chrome User-Agent string, and once with Safari's”, and [14Randall, Audrey; Snyder, Peter; Ukani, Alisha; Snoeren, Alex C.; Voelker, Geoffrey M.; Savage, Stefan; Schulman, Aaron (2022): "Measuring UID smuggling in the wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] records its second arm as Chrome with a spoofed Safari User-Agent.

This is not a measurement of ITP. It is a measurement of something else, and a good one: whether the site treats Safari users differently. [15Dimova, Yana; Acar, Gunes; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (2021): "The CNAME of the game: Large-scale analysis of DNS-based tracking evasion", Proceedings on Privacy Enhancing Technologies 2021:394–412. (DOI) (Link)] found that Criteo “would only resort to first-party tracking for Safari users” — a server-side adaptation that a real-Safari crawl would have confounded with ITP's own effect. Do it deliberately, call it a server-side-differentiation arm, and do not label the row “Safari”.

All corpus figures below come from the seven-venue publication corpus (CCS, IMC, NDSS, PoPETs, USENIX Security, TheWebConf, IEEE S&P, 2010–2026): 5,859 papers with a structured extraction, 5,869 with rendered full text. Any claim here is a claim about those seven venues.

The full-text sweep is case-sensitive for acronyms with ordinary-English homographs and whitespace-collapsed before matching, so a line break inside a phrase does not hide it. Population: the 5,869 papers with full text.

For scale, the same sweep over extension-side blockers, which are a different instrument and belong to Filter lists: Adblock Plus 124, Ghostery 110, uBlock Origin 75, AdGuard 71, Privacy Badger 63, NoScript 40. Tor Browser is named by 129 papers, more than any single desktop protection, but overwhelmingly as an anonymity system rather than as a tracking-protection arm.

By year. 2025 and 2026 are provisional venue-years — CCS 2026 and IMC 2026 have not been held, and IEEE S&P 2026 and TheWebConf 2026 are incompletely selected because selection screens on abstracts that are not yet in OpenAlex. Do not read the 2026 row as a decline.

2010–2016 are all zero, which is correct rather than a bug: ITP shipped in 2017 and ETP in 2019. The peak is 2022 and the count has not grown since, in absolute terms, while the corpus itself grew by about a third.

Crossed with the crawling population:

The first two rows share their numerator on purpose, not by accident: all 84 papers that crawl and name a protection also carry platforms containing web. The report asserts that and prints the exception list, which is empty.

Read the trend cautiously: the denominator includes every web crawl, and a phishing crawl or a CSP census has no reason to name ETP. It is an upper bound on non-engagement, not a defect rate. What it does show is that the share is not rising while the protections are: default-on Total Cookie Protection arrived in 2022 and the 2024–2026 slice is the lowest of the three.

crawlConfig.browsers is free text — 226 distinct strings across the crawling population for what is really a couple of dozen products. It was folded to product families by scripts/browser_fold.mjs, and the 42 unmapped strings are printed in full on the provenance page rather than dropped.

Denominator: the 529 of 1,120 crawling papers (47.2%) that state a browser at all. The other 593 said nothing, so every share below is a share of the ones that told you.

Two readings, both counted as distinct papers rather than by summing the table's rows — the field is multi-valued, so a paper naming both Chrome and Chromium appears twice above. 304 of the 529 (57.5%) drove Chrome or Chromium, the one mainstream browser with no default tracking protection, so the modal web measurement describes the web as seen by the least protected user and rarely says so. And 46 papers (8.7%) drove a privacy-branded browser — Tor Browser, Brave, DuckDuckGo, Firefox Focus or LibreWolf — of which 37 are Tor Browser, almost all of it anonymity work rather than tracking-protection work. That leaves 10 papers in sixteen years that drove Brave, DuckDuckGo, Firefox Focus or LibreWolf at all — and they are listed by name on browser_protection, because at that size a reader should be able to check the whole set.

Arms, as far as the extraction can see them:

• 80 papers (15.1% of the 529 stating; 7.1% of all 1,120 crawling) name two or more distinct real browser families.
• 25 papers (4.7% of the 529) name three or more. That is where a genuine cross-browser design lives, and it includes phishing-blocklist and XS-leak work as well as tracking work.

Version pinning is worse than browser naming. Of the 747 papers with a used-or-produced tool of category browser, only 276 (36.9%) attach a version string to any of them; restricted to the crawling population, 170 of 465 (36.6%). Given that [5Ali, Mir Masood; Chitale, Binoy; Ghasemisharif, Mohammad; Kanich, Chris; Nikiforakis, Nick; Polakis, Jason (2023): "Navigating Murky Waters: Automated Browser Feature Testing for Uncovering Tracking Vectors", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] found tracking behaviour differing across 126 versions of seven browsers, an unversioned browser is an unspecified treatment.

The inclusion rule, written before the table. The candidate pool is the 84 papers that both ran a crawl and name one of the six browser-shipped protections. Every candidate's protection mentions were read as ±320-character windows; the rows below were then read in their methodology and evaluation sections. A paper is:

• in — a browser-shipped protection was varied across arms, or evaluated against an explicit unprotected control;
• in-baseline — the protection was run or analysed as a comparison baseline for the authors' own classifier;
• in-instrument — the protection was the measuring instrument;
• spoof — a protected browser was impersonated by User-Agent rather than run;
• control-only — a single-arm crawl that states which protection state it was in;
• adjacent — the arms vary an extension or a blocking policy rather than a browser-shipped protection;
• out-background — named only in background, related work or the reference list.

The counts: 15 in, 3 in-baseline, 1 in-instrument, 2 spoof, 1 control-only, 4 adjacent, 58 out-background. Disagree with any assignment on browser_protection, where all 84 are listed with their verdicts. Nothing below is a share of anything; each row names the paper's own population.

And the four other ways the corpus uses a protection:

• As a baseline for your own classifier. [22Iqbal, Umar; Wolfe, Charlie; Nguyen, Charles; Englehardt, Steven; Shafiq, Zubair (2022): "Khaleesi: Breaker of Advertising and Tracking Request Chains", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2911-2928. USENIX Association, Boston, MA. (Link)] compares against Safari's ITP as one of four prior approaches; [8Yang, Zheng; Allen, Joey; Landen, Matthew; Perdisci, Roberto; Lee, Wenke (2023): "TRIDENT: Towards Detecting and Mitigating Web-based Social Engineering Attacks", in: Proceedings of the USENIX Security Symposium. (Link)] set Brave's ad-blocking component up locally and fed Brave Shields script and frame URL pairs; [11Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] compares against ITP's cap on first-party cookie expiry.
• As the instrument. [12Hausladen, Katherine; Wang, Oliver; Eng, Sophie; Wang, Jocelyn; Wijaya, Francisca; May, Matthew; Zimmeck, Sebastian (2025): "Websites' Global Privacy Control Compliance at Scale and over Time", in: Proceedings of the USENIX Security Symposium. (Link)] identifies trackers “with Firefox's built-in Enhanced Tracking Protection [54], which identifies tracker URLs and exposes an API that categorizes the trackers based on the Disconnect list”. Elegant and free — but it makes your tracker labels a function of a browser version, and it inherits every gap in Disconnect. See Filter lists.
• As a spoof. [15Dimova, Yana; Acar, Gunes; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (2021): "The CNAME of the game: Large-scale analysis of DNS-based tracking evasion", Proceedings on Privacy Enhancing Technologies 2021:394–412. (DOI) (Link)] and [14Randall, Audrey; Snyder, Peter; Ukani, Alisha; Snoeren, Alex C.; Voelker, Geoffrey M.; Savage, Stefan; Schulman, Aaron (2022): "Measuring UID smuggling in the wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] — see above.
• As a stated control. [6Munir, Shaoor; Lee, Patrick; Iqbal, Umar; Shafiq, Zubair; Siby, Sandra (2024): "PURL: Safe and Effective Sanitization of Link Decoration", in: 33rd USENIX Security Symposium (USENIX Security 24), pp. 4103-4120. USENIX Association, Philadelphia, PA. (Link)] is the exemplar for a single-arm crawl: “We turn off all built-in tracking protections provided by Firefox (Enhanced Tracking Protection [ETP])”, together with the browser version (v102), the statefulness, the list and the dates. One sentence, and the crawl becomes reproducible.

The adjacent four vary an extension or a policy rather than a browser feature, and are the right prior art if that is your design: [23Smith, Michael; Snyder, Peter; Livshits, Benjamin; Stefan, Deian (2021): "SugarCoat: Programmatically Generating Privacy-Preserving, Web-Compatible Resource Replacements for Content Blocking", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] (902 pages under three conditions, instrumented versus stock Chromium), [24Amjad, Abdul Haddi; Shafiq, Zubair; Gulzar, Muhammad Ali (2023): "Blocking JavaScript Without Breaking the Web: An Empirical Investigation", in: Proceedings on Privacy Enhancing Technologies. (DOI)], [25El Hajj Chehade, Saiid; Stock, Ben; Troncoso, Carmela (2025): "Double-Edged Shield: On the Fingerprintability of Customized Ad Blockers", in: Proceedings of the USENIX Security Symposium. (Link)] (whose Brave Shields row is tabulated but left out of the user-configuration analysis because Brave's community-forum posts “do not include the detailed browser filter-list configurations”, not because the forum is closed), and — the best-powered blocker experiment in the corpus — [26Lukić, Karlo; Papadopoulos, Lazaros (2026): "Privacy vs. Profit: The Impact of Google's Manifest Version 3 (MV3) Update on Ad Blocker Effectiveness", in: Proceedings on Privacy Enhancing Technologies. (Link)], which compared MV3 against MV2 instances of four ad blockers over 924 ad-supported websites × five measurement runs, plus 191- and 185-site stratified samples, in Chrome and Firefox, and found “no statistically significant reduction in ad-blocking or anti-tracking effectiveness for MV3 ad blockers compared to their MV2 counterparts”.

Microsoft Edge's Tracking Prevention is named as a mechanism by zero papers in the sweep above, and a zero must never come from one regex. Two widenings:

• A case-sensitive scan for the exact product name Tracking Prevention, excluding Safari's Intelligent Tracking Prevention, finds 18 papers, 20 occurrences. All 20 were read. Seventeen are reference-list entries to WebKit's or Microsoft's documentation. The three body occurrences are XSinator (CCS 2021), which calls Firefox's ETP “Enhanced Tracking Prevention” while noting that Edge's mechanism relies on blocklists; PURL (USENIX Security 2024), which makes the same slip about Firefox's ETP Strict; and a 2020 CCS survey whose Table 3 uses “Tracking Prevention” as a coding category. None of the three is about Edge.
• A scan for citations of Microsoft's own Edge tracking-prevention documentation — the learn.microsoft.com page, the 2019 msedgedev announcement, or a reference titled “Tracking Prevention in Microsoft Edge” — finds 5 papers, all of them citing it in passing while measuring something else.

So the field knows the feature exists, cites the vendor page for it, and has never run it. Edge appears in the crawlConfig.browsers fold for 15 papers, but as a browser being driven — for phishing-blocklist comparisons, XS-leaks and client-side security inconsistencies — not as a protection being measured.

This is a gap with a shape. Edge's Balanced mode is default-on for a browser with meaningful desktop share; it uses the same Disconnect lists as Firefox, so it is directly comparable; and it has a documented, unusual mitigation — the site-engagement relaxation — that nobody has measured the effect of. There is a paper here.

• Name the state of your single arm. A crawl with no protection arm is still in a protection state. Chrome and Chromium ship none, which is why they are the field's default and also why 57.5% of the crawls that state a browser describe the least protected user's web.
• “We used Firefox” is not a protection state. Firefox has meant no protection (before 2019), tracker-cookie blocking (2019), redirect-tracker protection (2020) and full third-party storage partitioning (2022) under the same name. So has “Safari”. Give the version.
• Your library is a third condition. Playwright's Firefox is 153.0 when stable is 155.0; its pref intended to disable ETP is dead in that build; it disables SameSite=Lax-by-default. Puppeteer and Selenium have their own lists. Read the state back.
• A metric can be non-monotone in protection strength. Edge's own documentation warns that Strict may appear to block fewer tracking requests than Balanced, because the trackers that would have made them were never loaded. Count what you observed against a permissive baseline; do not count what the browser says it blocked.
• A fresh profile is not a user's profile. Edge relaxes Balanced for organisations the profile has engaged with; Safari's ITP grants storage access on the basis of user interaction; Firefox clears storage from Disconnect-listed sites after 24 hours “unless the user has loaded the site as a first party in the previous 45 days” [14Randall, Audrey; Snyder, Peter; Ukani, Alisha; Snoeren, Alex C.; Voelker, Geoffrey M.; Savage, Stefan; Schulman, Aaron (2022): "Measuring UID smuggling in the wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]. A crawler has no history, so it sits at one extreme of a distribution nobody in the corpus has measured.
• Protection-as-instrument inherits the protection's blind spots. If ETP's API labels your trackers, your ground truth is the Disconnect list on the day your Firefox build shipped, with a browser vendor's compatibility exemptions baked in. That is a defensible choice and a circular one; say which list and which version. [9Koop, Martin; Tews, Erik; Katzenbeisser, Stefan (2020): "In-Depth Evaluation of Redirect Tracking and Link Usage", in: Proceedings on Privacy Enhancing Technologies. (DOI)] is the cautionary figure: Safari ITP 2.3 blocked 9 of 30 known redirect-tracker cookies.
• A User-Agent is not a browser. It measures server-side differentiation, which is real and worth measuring, and it measures nothing about the protection.
• Breakage is part of the result, not an inconvenience. [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)] built a quantitative breakage estimator because the privacy number alone is not a finding; [10Lin, Maxwell; Lin, Shihan; Wu, Helen; Wang, Karen; Yang, Xiaowei (2024): "Browsing without Third-Party Cookies: What Do You See?", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] exists because “the cookieless web looks different” was an untested premise, and largely false at the page level.
• Two instances of the same condition, or you cannot read the difference. Both large cross-arm studies in the corpus do this. See Run the same condition twice.
• Seven venues. EuroS&P, ACSAC, RAID, AsiaCCS, CHI, SOUPS, PAM and WPES are not in the corpus, and a good deal of blocker-effectiveness work is published there. The counts above are floors.

1. The exact browser and version for every arm — Firefox 102.0, Brave 1.68.141, Chromium 151.0.7922.34. Not “the latest Chrome”.
2. The protection level by name and by mechanism: not “ETP”, but “ETP Strict” and the prefs or settings that put it there.
3. How you verified the arm was in that state, as a fact you checked. One sentence, and a line of code in the artifact.
4. The automation library and version, and the flags and preferences you passed — because the library passes its own.
5. Whether the arms ran in parallel or in sequence, and over which dates.
6. Whether you ran a duplicate of any condition, and what the same-condition difference was. This is your noise floor and your reader cannot evaluate an effect size without it.
7. The URL list, its version, and whether every arm visited the same URLs in the same order.
8. Statefulness and consent handling, identically across arms.
9. Breakage, or an explicit statement that you did not measure it.
10. For a single-arm crawl: the protection state anyway. [6Munir, Shaoor; Lee, Patrick; Iqbal, Umar; Shafiq, Zubair; Siby, Sandra (2024): "PURL: Safe and Effective Sanitization of Link Decoration", in: 33rd USENIX Security Symposium (USENIX Security 24), pp. 4103-4120. USENIX Association, Philadelphia, PA. (Link)] is the model.

• Filter lists — the lists these protections consume, and why “blocked implies tracker” is circular.
• Requests — classifying the requests you collected, once you have decided which browser collected them.
• Cookies and Browser storage — what a partitioning protection actually partitions.
• Privacy Sandbox — the other half of the browser-as-variable problem, on the Chrome side.
• Stateful stateless — ITP's 7-day and 24-hour caps are invisible to a stateless crawl.
• Crawler detection — a protective browser has a distinctive fingerprint, and [19Venugopalan, Hari; Munir, Shaoor; Ahmed, Shuaib; Wang, Tangbaihe; King, Samuel T.; Shafiq, Zubair (2025): "FP-Inconsistent: Measurement and Analysis of Fingerprint Inconsistencies in Evasive Bot Traffic", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] shows bot detectors reading it.
• Longitudinal — a series that spans a protection's shipping date is measuring the browser.
• Crawling location — the other treatment you must hold constant.
• Fingerprinting — Brave's and Tor's randomisation and allowlisting are arms in half the fingerprinting papers above.
• Provenance of this page's figures.

Corpus figures come from the 5,859-paper extraction over seven venues (CCS, IMC, NDSS, PoPETs, USENIX Security, TheWebConf, IEEE S&P), 2010–2026; the full-text sweep covers the 5,869 papers with a rendered paper.cols.txt. Any claim here is a claim about those seven venues. 2025 and 2026 venue-years are provisional. Every share names its own denominator; crawlConfig.browsers is stated by only 47.2% of crawling papers, so browser shares are shares of the ones that told you.

All browser measurements were taken on 2026-09-01 against Chromium 151.0.7922.34 as shipped with Playwright 1.62.1, headless, in a Linux container. Firefox was not measured: the Playwright Firefox 153.0 build fails to start in this environment (RenderCompositorSWGL failed mapping default framebuffer), headless and headful under Xvfb alike, so every Firefox statement here is read from the shipped omni.ja and preference files rather than from a running browser, and is labelled as such. Safari, Brave, Edge, Tor Browser and DuckDuckGo were not available in this environment at all; their rows in What the Browsers Actually Ship come from vendor documentation fetched on 2026-09-01 and quoted verbatim.

The full query log — every population and denominator, the report script and its unedited output, the browser fold with its unmapped residue printed in full, the hand-audit verdicts for all 84 candidates, the quotes spot-checked and the external sources verified or rejected — is at browser_protection. Corpus-level caveats are on corpus.

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

Cassel, Darion; Lin, Su-Chin; Buraggina, Alessio; Wang, William; Zhang, Andrew; Bauer, Lujo; Hsiao, Hsu-Chun; Jia, Limin; Libert, Timothy (2022): "OmniCrawl: Comprehensive Measurement of Web Tracking With Real Desktop and Mobile Browsers", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[3]

Franken, Gertjan; Van Goethem, Tom; Joosen, Wouter (2018): "Who Left Open the Cookie Jar? A Comprehensive Evaluation of Third-Party Cookie Policies", in: Proceedings of the USENIX Security Symposium. (Link)

[4]

Vlummens, Tim; Girish, Aniketh; Weerasekara, Nipuna; Zuiderveen Borgesius, Frederik; Acar, Gunes; Vallina-Rodriguez, Narseo (2026): "Bridges to Self: Silent Web-to-App Tracking on Mobile via Localhost", in: Proceedings of the USENIX Security Symposium. (Link)

[5]

Ali, Mir Masood; Chitale, Binoy; Ghasemisharif, Mohammad; Kanich, Chris; Nikiforakis, Nick; Polakis, Jason (2023): "Navigating Murky Waters: Automated Browser Feature Testing for Uncovering Tracking Vectors", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[6]

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

[7]

Hoang, Nguyen Phong; Niaki, Arian Akhavan; Gill, Phillipa; Polychronakis, Michalis (2021): "Domain name encryption is not enough: privacy leakage via IP-based website fingerprinting", Proceedings on Privacy Enhancing Technologies 2021(4):420-440. (DOI)

[8]

Yang, Zheng; Allen, Joey; Landen, Matthew; Perdisci, Roberto; Lee, Wenke (2023): "TRIDENT: Towards Detecting and Mitigating Web-based Social Engineering Attacks", in: Proceedings of the USENIX Security Symposium. (Link)

[9]

Koop, Martin; Tews, Erik; Katzenbeisser, Stefan (2020): "In-Depth Evaluation of Redirect Tracking and Link Usage", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[10]

Lin, Maxwell; Lin, Shihan; Wu, Helen; Wang, Karen; Yang, Xiaowei (2024): "Browsing without Third-Party Cookies: What Do You See?", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[11]

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

[12]

Hausladen, Katherine; Wang, Oliver; Eng, Sophie; Wang, Jocelyn; Wijaya, Francisca; May, Matthew; Zimmeck, Sebastian (2025): "Websites' Global Privacy Control Compliance at Scale and over Time", in: Proceedings of the USENIX Security Symposium. (Link)

[13]

Dao, Ha; Shinde, Abhishek; Athar, Sana; Gosain, Devashish (2026): "Clicking into Exposure: Uncovering Privacy Risks of Google Click Identifier in YouTube Ads", Proceedings on Privacy Enhancing Technologies 2026(2):92-107. (DOI)

[14]

Randall, Audrey; Snyder, Peter; Ukani, Alisha; Snoeren, Alex C.; Voelker, Geoffrey M.; Savage, Stefan; Schulman, Aaron (2022): "Measuring UID smuggling in the wild", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[15]

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

[16]

Datta, Amit; Lu, Jianan; Tschantz, Michael Carl (2019): "Evaluating Anti-Fingerprinting Privacy Enhancing Technologies", in: Proceedings of the ACM Web Conference. (DOI)

[17]

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)

[18]

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

[19]

Venugopalan, Hari; Munir, Shaoor; Ahmed, Shuaib; Wang, Tangbaihe; King, Samuel T.; Shafiq, Zubair (2025): "FP-Inconsistent: Measurement and Analysis of Fingerprint Inconsistencies in Evasive Bot Traffic", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[20]

Trampert, Leon; Weber, Daniel; Gerlach, Lukas; Rossow, Christian; Schwarz, Michael (2025): "Cascading Spy Sheets: Exploiting the Complexity of Modern CSS for Email and Browser Fingerprinting", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[21]

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

[22]

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

[23]

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

[24]

Amjad, Abdul Haddi; Shafiq, Zubair; Gulzar, Muhammad Ali (2023): "Blocking JavaScript Without Breaking the Web: An Empirical Investigation", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[25]

El Hajj Chehade, Saiid; Stock, Ben; Troncoso, Carmela (2025): "Double-Edged Shield: On the Fingerprintability of Customized Ad Blockers", in: Proceedings of the USENIX Security Symposium. (Link)

[26]

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