Differences

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

--- privacy:browser_protection [2026/09/01 21:48] – Note that the crawled and web-crawled protection rows share their numerator by fact, asserted in the report. Authored by Claude karel.kubicek.claude
+++ privacy:browser_protection [2026/09/01 22:10] (current) – Generic review: correct the ETP Strict row from the build's own strict feature string (cookieBehavior5, same as Standard); add reusable-artifacts section, the canary read-back recipe, an OpenWPM row, and a hearsay marker on the driving table; fix an inden karel.kubicek.claude
@@ Line 1: / Line 1: @@
 ====== Measuring with Browser Tracking Protections On ======
-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.
+Every crawl runs in some tracking-protection state. Most crawls never say which one — 52.8% of the crawling papers in the seven-venue corpus do not even name the browser. And a crawl can be in a state its authors did not choose: the measurement below found four of five plausible ways to switch a protection on in Chromium doing nothing at all. That is evidence about tooling. Whether published crawls are in fact mis-stated is not something this page measures, and nobody has.
 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.
@@ Line 10: / Line 10: @@
 **Verify the arm. Do not configure it and assume.**
-Measured here on **2026-09-01**, Chromium **151.0.7922.34** driven by Playwright **1.62.1**, against a local first-party page embedding a local third party that sets a cookie by header and by ''document.cookie'': of five plausible ways to build a "third-party cookies blocked" arm, **four produced a control arm** and only one worked.
+Measured here on **2026-09-01**, Chromium **151.0.7922.34** driven by Playwright **1.62.1**, against a local first-party page embedding a local third party that sets a cookie by header and by ''document.cookie'': of five plausible ways to build a "third-party cookies blocked" arm, **four produced a control arm** and only one worked. Three of the four failed //silently//; the fourth threw a protocol error, which is the outcome you want when something is wrong.
   * ''%%--test-third-party-cookie-phaseout%%'' — a **real switch** (the string is in the binary) — changed nothing.
@@ Line 35: / Line 35: @@
 ^ Browser ^ Feature ^ On by default? ^ Mechanism ^ Shipped ^
-| **Firefox** | Enhanced Tracking Protection, **Standard** | yes | Blocks third-party //tracking// cookies by the Disconnect list; **Total Cookie Protection** partitions all remaining third-party storage into a per-site jar | ETP default-on for all users with **Firefox 69, 2019-09-03**((Mozilla, [[https://blog.mozilla.org/en/products/firefox/todays-firefox-blocks-third-party-tracking-cookies-and-cryptomining-by-default/|"Today's Firefox Blocks Third-Party Tracking Cookies and Cryptomining by Default"]], 2019-09-03, Firefox 69: "Today, Firefox on desktop and Android will — by default — empower and protect all our users by blocking third-party tracking cookies and cryptominers." Announced for new installs on 2019-06-04. Both fetched 2026-09-01.)); Total Cookie Protection default in Standard, **2022-06-14**((Mozilla, [[https://blog.mozilla.org/en/products/firefox/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/|"Firefox Rolls Out Total Cookie Protection By Default To All Users Worldwide"]], 2022-06-14, page updated 2024-08-28: Total Cookie Protection "works by creating a separate 'cookie jar' for each website you visit". Fetched 2026-09-01.)) |
+| **Firefox** | Enhanced Tracking Protection, **Standard** | yes | Blocks third-party //tracking// cookies by the Disconnect list; **Total Cookie Protection** partitions all remaining third-party storage into a per-site jar | ETP default-on for all users with **Firefox 69, 2019-09-03**((Mozilla, [[https://blog.mozilla.org/en/products/firefox/todays-firefox-blocks-third-party-tracking-cookies-and-cryptomining-by-default/|"Today's Firefox Blocks Third-Party Tracking Cookies and Cryptomining by Default"]], 2019-09-03, Firefox 69: "Today, Firefox on desktop and Android will — by default — empower and protect all our users by blocking third-party tracking cookies and cryptominers." The earlier post [[https://blog.mozilla.org/en/firefox/firefox-now-available-with-enhanced-tracking-protection-by-default/|"Firefox Now Available with Enhanced Tracking Protection by Default"]], 2019-06-04, is the new-installs announcement: "Enhanced Tracking Protection will automatically be set on by default as part of the 'Standard' setting in the browser and will block known 'third-party tracking cookies' according to the Disconnect list." Both fetched 2026-09-01.)); Total Cookie Protection default in Standard, **2022-06-14**((Mozilla, [[https://blog.mozilla.org/en/products/firefox/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/|"Firefox Rolls Out Total Cookie Protection By Default To All Users Worldwide"]], 2022-06-14, page updated 2024-08-28: Total Cookie Protection "works by creating a separate 'cookie jar' for each website you visit". Fetched 2026-09-01.)) |
-| **Firefox** | ETP **Strict** | no — opt-in | Everything in Standard, plus blocking //all// cross-site cookies, tracking-query-parameter stripping, and Bounce Tracking Protection | query stripping available from Firefox 102, June 2022, Strict only {[shaoor2024purl]} |
+| **Firefox** | ETP **Strict** | no — opt-in | **Same cookie behaviour as Standard.** Read from the build examined here, ''browser.contentblocking.features.strict'' is ''%%tp,tpPrivate,cookieBehavior5,cookieBehaviorPBM5,cryptoTP,fp,stp,emailTP,emailTPPrivate,-consentmanagerSkip,-consentmanagerSkipPrivate,lvl2,rp,rpTop,qps,qpsPBM,fpp,fppPrivate,btp,lna%%'' — so Strict differs by turning on tracking-protection //blocking// (''tp''), the level-2 blocklist (''lvl2''), cryptomining, fingerprinting and social-tracker blocking, query-parameter stripping (''qps''), fingerprinting protection (''fpp''), referrer trimming and Bounce Tracking Protection (''btp'') — **not** by a different ''cookieBehavior''((Mozilla's user-facing documentation describes Strict as blocking all cross-site cookies. That is a description of what partitioning //achieves// — a partitioned cookie cannot be read across sites — not of a different ''cookieBehavior'' value, and both this row and the code below are written from the build rather than from the wording. An earlier revision of this page said Strict blocks all cross-site cookies; that was wrong for this build and was caught in review. If the distinction matters to your arm, read the pref back.)) | query stripping available from Firefox 102, June 2022, Strict only {[shaoor2024purl]}; the strict string above is from Firefox 153.0, ''BuildID'' ''20260722045016'' |
 | **Safari** | Intelligent Tracking Prevention | yes | Blocks all third-party cookies with no exceptions; caps JS-set cookies at 24 hours after a decorated link; deletes script-writeable storage after 7 days without interaction; downgrades third-party referrers to the origin; partitions third-party LocalStorage, IndexedDB, service workers and HTTP cache((Apple, [[https://webkit.org/tracking-prevention/|"Tracking Prevention in WebKit"]], fetched 2026-09-01, quoted verbatim.)) | ITP 2017; **full third-party cookie blocking 2020-03-24**, Safari 13.1: "Cookies for cross-site resources are now blocked by default across the board"((John Wilander, [[https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/|"Full Third-Party Cookie Blocking and More"]], WebKit blog, 2020-03-24. Fetched 2026-09-01.)) |
-| **Brave** | Shields | yes | Blocks third-party ads and trackers by filter list plus heuristics; third-party storage is ephemeral; fingerprint randomisation. An **Aggressive** setting additionally blocks first-party ads((Brave Help Center, [[https://support.brave.app/hc/en-us/articles/360022973471-What-is-Shields|"What is Shields?"]] and [[https://support.brave.app/hc/en-us/articles/360022806212-How-do-I-use-Shields-while-browsing|"How do I use Shields while browsing?"]], fetched 2026-09-01. Brave's help centre has moved from ''support.brave.com'' to ''support.brave.app''; the old paths 301 to the new ones, so citations in papers before the migration still resolve. Both are behind a CDN gate that returns 403 to ''curl'' — fetched through a real browser.)) | Shields since launch; stable **1.94.118** on 2026-09-01, on Chromium 152.0.7977.64((''api.github.com/repos/brave/brave-browser/releases'', release entry ''v1.94.118'', published 2026-09-01T07:05:48Z. Read from the JSON API, not from ''releases.atom'', whose element order pairs versions with the wrong dates.)) |
+| **Brave** | Shields | yes | Blocks third-party ads and trackers by filter list plus heuristics; third-party storage is ephemeral; fingerprint randomisation. An **Aggressive** setting additionally blocks first-party ads((Brave Help Center, [[https://support.brave.app/hc/en-us/articles/360022973471-What-is-Shields|"What is Shields?"]] and [[https://support.brave.app/hc/en-us/articles/360022806212-How-do-I-use-Shields-while-browsing|"How do I use Shields while browsing?"]], fetched 2026-09-01. Brave's help centre has moved from ''support.brave.com'' to ''support.brave.app''; the old paths 301 to the new ones, so citations in papers before the migration still resolve. Both are behind a CDN gate that returns 403 to ''curl'' — fetched through a real browser.)) | Shields since launch; stable **1.94.117**, released 2026-08-26, on Chromium 152.0.7977.64((GitHub API ''repos/brave/brave-browser/releases/latest'', which excludes prereleases, returns ''v1.94.117'', published 2026-08-26T08:10:10Z; Brave's own release-notes page agrees ("Release Notes v1.94.117 (Aug 27, 2026)"). The newer-looking ''v1.94.118'' in the unfiltered releases list carries ''prerelease: true''. Both read from the JSON API, not from ''releases.atom'', whose element order pairs versions with the wrong dates. Fetched 2026-09-01.)) |
 | **Microsoft Edge** | Tracking Prevention, **Balanced** | yes | Disconnect Tracker Protection lists, delivered as a browser component; blocks storage access and, for some categories, resource loads; **relaxed for organisations the profile has engaged with**((Microsoft, [[https://learn.microsoft.com/en-us/microsoft-edge/web-platform/tracking-prevention|"Tracking prevention in Microsoft Edge"]], ''updated_at'' 2026-06-12. Quotes and the enforcement matrix taken verbatim; fetched 2026-09-01.)) | preview announced **2019-06-27**, Balanced already the default((Microsoft Edge Team, [[https://blogs.windows.com/msedgedev/2019/06/27/tracking-prevention-microsoft-edge-preview/|"Introducing tracking prevention, now available in Microsoft Edge preview builds"]], 2019-06-27: "Today, we're releasing an experimental preview of tracking prevention for Microsoft Edge" and "The default tracking prevention setting is Balanced". Fetched 2026-09-01. Microsoft's current documentation does not carry this date, which is why the announcement is cited rather than the docs.)) |
 | **Chrome** | — | **no** | No built-in tracker blocking. Third-party cookies stayed: Chrome will not roll out the prompt, announced 2025-04-22 — see [[Privacy:Privacy Sandbox]] | — |
@@ Line 51: / Line 51: @@
 **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 nothing in the corpus uses: ''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 ([[Privacy:Privacy Sandbox#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.
 ===== Designing the Paired Crawl =====
@@ Line 58: / Line 56: @@
 ==== The arm you did not verify is a control arm ====
-This is the whole page in one experiment. Two local HTTPS origins, a third party in an iframe setting a cookie two ways, and six Chromium configurations that a reasonable person would expect to differ.
+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.
 <file javascript bp_arms_probe.mjs>
@@ Line 242: / Line 240: @@
 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%%''
+<code javascript>
+// Read it back rather than trusting the category name: open about:config in a tab
+// and inspect network.cookie.cookieBehavior, or use the canary origin below.
+</code>
 or set it explicitly at launch and stop depending on a category name:
@@ Line 248: / Line 249: @@
 <code javascript>
 // Firefox arm, stated rather than assumed. 0 = accept all (the "off" arm),
-// 5 = partition third-party storage (Total Cookie Protection, the Standard default),
+// 5 = partition third-party storage (Total Cookie Protection) -- the default in BOTH
-// 1 = reject all third-party cookies (closest to ETP Strict's cookie behaviour).
+//     ETP Standard and ETP Strict in Firefox 153; Strict differs elsewhere, not here,
+// 1 = reject all third-party cookies. No ETP category ships this: it is a custom
+//     state, stronger than anything a Firefox user gets by picking a preset.
 const browser = await firefox.launch({
   firefoxUserPrefs: {
@@ Line 281: / Line 284: @@
 ==== How to drive each browser ====
+**Only the Chromium row below was exercised in this environment** (see [[#Methodology and limitations of these figures]]); the rest is how the corpus's papers did it and what the vendor documentation says. Treat them as leads to verify, not as tested recipes.
 ^ Arm ^ How it is actually driven ^ Watch out for ^
@@ Line 286: / Line 291: @@
 | Chromium, third-party cookies blocked | CDP ''Network.setCookieControls'' — measured above | experimental command; reload required |
 | Firefox, ETP levels | Playwright/Selenium with explicit ''firefoxUserPrefs'', or a prepared profile | the category name is not the state; set the prefs |
+| Firefox through **OpenWPM**, the field's dominant Firefox harness | OpenWPM sets its own preference bundle on top of Firefox's defaults and exposes a ''browser_params'' object; {[koop2020_redirect]} built its arms this way | **not examined here.** OpenWPM is a third pref-setting layer between you and the browser, so the read-back matters more, not less. See [[Programming:Crawler:OpenWPM]] |
 | Brave | Brave is Chromium: point Playwright or Puppeteer at the Brave binary with ''executablePath'' | Shields settings live in the profile, not on the command line, so prepare a profile per arm and verify it |
 | Brave's blocking engine //without// Brave | the ''adblock-rs'' npm package, Brave's own engine, **0.13.3, published 2026-08-20** | this is what {[yang2023_trident]} did, feeding it script and frame URLs. The unrelated npm package named ''adblock-rust'' is stuck at 9.0.0 from 2021 and is not Brave's |
@@ Line 292: / Line 298: @@
 | Edge | Edge is Chromium: ''executablePath'', or ''msedgedriver'' | the Balanced level depends on the profile's site-engagement history — see above |
 | DuckDuckGo, Firefox Focus | mobile apps; Appium on real devices, as {[cassel2022_omnicrawl]} did | there is no desktop automation path |
+==== Which of these designs is current, and which is not ====
+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.
+^ Design ^ When the corpus used it ^ Status in 2026 ^
+| **Impersonating a protected browser by User-Agent** | 2021, 2022 | **Superseded for this purpose.** It measures the site's behaviour towards a browser, not the browser's behaviour. Still the right design for the question it does answer — see below |
+| **Two or more real browsers as arms** | 2018 onwards, and 7 of the 11 papers from 2024–2026 | **Current practice.** Chromium-based products (Brave, Edge) take an ''executablePath''; Firefox takes explicit preferences |
+| **Varying the storage policy inside one engine** | 2022 {[jueckstock2022_privacy]}, 2024 {[lin2024_browsing]} | **Current, and the strongest design** where the question is about the policy rather than the product: it removes every confound except the one you varied |
+| **Per-mechanism testing across many browser versions** | 2023 {[ali2023_navigating]}, and how 2025–2026 papers test bypasses | **Current.** It is also the only design that survives the fact that a protection changes between milestones |
+| **Running the protection's engine as a library**, without the browser | 2023 {[yang2023_trident]}, 2023 {[shaoor2023cookiegraph]} analytically | **Current and cheap** for a blocking-decision comparison; useless for anything involving storage, state or timing, because there is no browser |
+| **Driving the protected browser by hand** | 2020 {[koop2020_redirect]}, 30 domains | **Still the only route for Safari** off macOS. Small-n and honest beats absent |
+| **Using the protection as the tracker classifier** | 2025 {[hausladen2025_websites]} | **Current, and newly attractive** — but it makes your labels a function of a browser build. See [[Programming:Filter lists]] |
+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" {[dao2026_gclid]}. 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 [[Privacy:Cookies]] and [[Privacy: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: {[jueckstock2022_privacy]} 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"; {[hausladen2025_websites]} "uses non-headless mode to appear more similar to a human user"; {[randall2022_uidsmuggling]} used Puppeteer in "headful" mode under Xvfb for the same reason. Given that {[cassel2022_omnicrawl]} shows how you drive the browser is itself a treatment, a protection arm that differs in headlessness from its control is two treatments — see [[Programming:Crawler detection]].
+==== Bounce tracking has an instrumentation route nobody uses ====
+''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 beside them, which are being removed ([[Privacy:Privacy Sandbox#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 an arm wants and a user's browser does not. **No paper in the corpus names either command**: a full-text sweep over the 5,869 papers for the two literal command strings returns zero (''scripts/bp_cdp_sweep.mjs'', output on [[provenance:privacy:browser_protection]]).
+==== The one read-back that works for every arm ====
+Reading a preference back only works where there is a preference to read: Brave's Shields level and Edge's Tracking Prevention level live in a profile, and Safari's ITP has no knob at all. The recipe that generalises is the one the probe above is built on, turned outward: **stand up a canary origin and visit it first in every arm of the real crawl.**
+Serve a page from a domain you control that embeds a second domain you control; have the second one set a cookie by header and by ''document.cookie'', request a URL that every mainstream blocklist carries, and read back a fingerprinting surface. Log what each arm saw. It costs one page load per arm, it produces a per-arm record you can put in the artifact, and it works identically for Chromium switches, Firefox preferences, Brave's profile settings and a Safari you are driving by hand. **If two arms return the same canary record, they are the same arm, whatever you configured.**
+Nothing in the corpus does this. It is a recommendation, not a measured practice.
 ==== The User-Agent shortcut, and what it does and does not measure ====
@@ Line 298: / Line 335: @@
 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. {[dimova2021cname]} 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".
+===== What You Can Reuse Instead of Crawling =====
+Eight parallel arms is a lot of machine-time to spend rediscovering something. Every URL below was fetched on **2026-09-01**; only the last row is a dataset rather than code.
+^ From ^ What it is ^ Where ^
+| {[jueckstock2022_privacy]} | **Chromium patches implementing the four storage policies** — permissive, blocking, site-keyed, page-length. If your question is about the policy rather than the product, this is the arm-building work already done | ''github.com/jueckstock/ephemeral-storage-patches''. **The URL printed in the paper, under the ''wspr-ncsu'' organisation, is now a 404**; the repository lives under the first author's account, last pushed 2020-10-15 |
+| {[cassel2022_omnicrawl]} | the cross-platform crawl harness, desktop plus Appium-driven Android | ''github.com/OmniCrawl'' |
+| {[ali2023_navigating]} | **CanITrack** — the read/write test harness for 21 browser mechanisms across browser versions | ''github.com/masood/canitrack'' |
+| {[franken2018_cookiejar]} | the third-party-request test-case generator, browsers plus extensions | ''github.com/DistriNet/xsr-framework'' |
+| {[lin2024_browsing]} | the three-arm Firefox harness with the screenshot/text/image differ | ''github.com/maxwellmlin/IMC2024-CookielessBrowsing'' |
+| {[ukani2025_local]} | the local-frame bypass test site and results | ''osf.io/9yq57'' |
+| {[trampert2025_cascading]} | the CSS fingerprinting templates, 1,176 OS-browser combinations | ''github.com/cispa/cascading-spy-sheets'' and Zenodo ''10.5281/zenodo.13712489'' |
+| {[vlummens2026_bridges]} | the localhost-bridge measurement artefacts | Zenodo ''10.5281/zenodo.17880051'' |
+| {[datta2019_evaluating]} | **PETInspector**, the anti-fingerprinting-PET differ | ''github.com/tadatitam/pet-inspector'' |
+| {[rieder2025_beyond]} | classifier code, and the T.EX-collected **Chrome / Firefox / Brave request datasets** — a cross-browser corpus you did not have to crawl | ''github.com/wolfrieder/http-response-classifier'' |
+Two of the fifteen ''in'' papers mention no artifact at all in the extraction ({[koop2020_redirect]}, {[solomos2021_tales]}), and the dead ''wspr-ncsu'' URL is a reminder that a paper's printed link is not an archival deposit — see [[:artifacts]].
 ===== Use in Publications =====
@@ Line 342: / Line 397: @@
 | web crawls published 2019–2022 | 266 | 43 (16.2%) |
 | web crawls published 2023–2026* | 332 | 37 (11.1%) |
-| web crawls published 2024–2026* | 235 | 24 (10.2%) |
 **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.
+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 June 2022, and the share of web crawls naming any protection is lower in 2023–2026 than in 2019–2022. The two windows are disjoint on purpose — an earlier draft added a 2024–2026 row, which is a //subset// of 2023–2026 and therefore cannot be read as a third point in a trend. Both windows still end in provisional venue-years, so the direction is safer than the magnitude.
 ==== Which browser the field actually drives ====
@@ Line 369: / Line 423: @@
 | Firefox Focus | 1 | 0.2% |
-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 [[provenance:privacy:browser_protection]], because at that size a reader should be able to check the whole set.
+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 across the corpus's seventeen venue-years (2010–2026)** that drove Brave, DuckDuckGo, Firefox Focus or LibreWolf at all — and they are listed by name on [[provenance:privacy: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:
@@ Line 394: / Line 448: @@
 ^ Paper ^ Arms ^ What it took to run them ^
 | {[franken2018_cookiejar]} USENIX Sec 2018 | 7 browsers × their built-in third-party cookie policies, plus 31 ad-blocking and 15 anti-tracking extensions | a generated test-case suite covering every way to trigger a third-party request, behind an intercepting proxy. Also crawled the Alexa top 10,000, 160,059 pages, to check whether the bypasses were used in the wild — they were not |
-| {[datta2019_evaluating]} TheWebConf 2019 | 15 anti-fingerprinting PETs incl. Brave and the Tor Browser Bundle, against unmodified Chrome and Firefox | original fingerprints revealed 13.002 bits for Chrome and 12.359 for Firefox; **13 of the 15 PETs moved that from about 13 bits to about 11**. Tor Browser Bundle reached **under 3 bits**. Brave "spoofs the User-Agent to appear like Chrome, but modifies the Accept-Language header, language and plugins differently than baseline Chrome" |
+| {[datta2019_evaluating]} TheWebConf 2019 | 15 anti-fingerprinting PETs incl. Brave and the Tor Browser Bundle, against unmodified Chrome and Firefox | original fingerprints revealed 13.002 bits for Chrome and 12.359 for Firefox; **13 of the 15 PETs left over 11 bits** — all but Brave and the Tor Browser Bundle, which the paper calls "reveal over 11 bits of entropy and hence are marginally better than [...] not using any AFPET at all" (the bracket is another two-column splice). Only Brave and the Tor Browser Bundle did better, and Tor Browser Bundle reached **under 3 bits**. Read this as the null result it is: a protection arm can move your metric hardly at all, and that is a finding. Brave "spoofs the User-Agent to appear like Chrome, [...] but modifies the Accept-Language header, language and [...] plugins differently than baseline Chrome" — a protection that makes its users stand out from the Chrome users it imitates |
 | {[koop2020_redirect]} PoPETs 2020 | OpenWPM Firefox under several browser settings, plus Ghostery, plus Safari ITP 2.3 | Safari could not be automated, so the ITP arm was **done by hand** on the top 30 redirect-tracker domains: Ghostery blocked 11 of 30, Safari 9 of 30, and Safari's 9 were still present in the browser cache |
 | {[solomos2021_tales]} NDSS 2021 | Brave in strict mode against four anti-fingerprinting extensions and an unprotected baseline | Brave left **12 bits** of fingerprinting entropy where the extensions left 18–21 |
@@ Line 412: / Line 466: @@
   * **As a baseline for your own classifier.** {[iqbal2022_khaleesi]} compares against Safari's ITP as one of four prior approaches; {[yang2023_trident]} set Brave's ad-blocking component up locally and fed Brave Shields script and frame URL pairs; {[shaoor2023cookiegraph]} compares against ITP's cap on first-party cookie expiry.
-  * **As the instrument.** {[hausladen2025_websites]} identifies trackers "with Firefox's built-in Enhanced Tracking Protection, 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 [[Programming:Filter lists]].
+  * **As the instrument.** {[hausladen2025_websites]} 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 [[Programming:Filter lists]].
   * **As a spoof.** {[dimova2021cname]} and {[randall2022_uidsmuggling]} — see above.
   * **As a stated control.** {[shaoor2024purl]} 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: {[smith2021_sugarcoat]} (902 pages under three conditions, instrumented versus stock Chromium), {[amjad2023_blocking]}, {[elhajjchehade2025_double]}, and — the best-powered blocker experiment in the corpus — {[lukic2026_mv3]}, 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".
+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: {[smith2021_sugarcoat]} (902 pages under three conditions, instrumented versus stock Chromium), {[amjad2023_blocking]}, {[elhajjchehade2025_double]} (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 — {[lukic2026_mv3]}, 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".
 ==== Nobody has measured Edge ====
-Microsoft Edge's Tracking Prevention is named by **zero** papers in the sweep above. That zero is not a probe artefact: a separate case-sensitive scan for the exact product name ''Tracking Prevention'', excluding Safari's ''Intelligent Tracking Prevention'', finds it in **18 papers, 20 occurrences**, and reading all 20 shows they are almost entirely reference-list entries to WebKit's or Microsoft's own documentation. The two substantive body mentions are one paper describing Edge as relying on blocklists, in a sentence about ITP and ETP, and one listing Edge among browsers with a bundled blocker.
+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.
-Edge has 15 papers in the ''crawlConfig.browsers'' fold, but as a browser being driven, not as a protection being measured.
+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.
@@ Line 432: / Line 489: @@
   * **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's Disconnect-based blocking has a 45-day first-party-visit exemption. A crawler has no history, so it sits at one extreme of a distribution nobody in the corpus has measured.
+  * **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" {[randall2022_uidsmuggling]}. 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. {[koop2020_redirect]} 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.
@@ Line 455: / Line 512: @@
 <WRAP todo>
-  * **Microsoft Edge Tracking Prevention has never been measured** in these seven venues — zero papers name it as a mechanism. It is default-on, it uses the same Disconnect lists as Firefox, and it has a documented site-engagement relaxation whose effect nobody has quantified.
+  * **Microsoft Edge Tracking Prevention has never been measured** in these seven venues — see [[#Nobody has measured Edge]].
-  * **Nobody has measured the crawler-profile bias in protection behaviour.** Edge's Org Engagement mitigation, Safari's interaction-based storage grants and Firefox's 45-day first-party exemption all make protection strength a function of browsing history. Every crawl sits at history = none. How far is that from a real user? The corpus does not say.
+  * **Nobody has measured the crawler-profile bias in protection behaviour.** Edge's Org Engagement mitigation, Safari's interaction-based storage grants and Firefox's 45-day first-party-visit exemption {[randall2022_uidsmuggling]} all make protection strength a function of browsing history. Every crawl sits at history = none. How far is that from a real user? The corpus does not say.
   * **No post-2024 paired crawl of Firefox ETP Standard versus off.** Total Cookie Protection has been default-on since June 2022; the corpus's ETP arms are {[vlummens2026_bridges]}'s per-mechanism test and {[shaoor2024purl]}'s deliberate switch-off. There is no web-scale before/after.
   * **Why ''%%--test-third-party-cookie-phaseout%%'' did nothing** in Chromium 151 on the Playwright path, when the switch exists in the binary. This run established the effect, not the cause.