Third-party cookies were not removed from Chrome, and the APIs that were built to replace them are now being removed instead. Both halves of that sentence matter to a crawl you design in 2026, and neither is what the 2022 Privacy Sandbox roadmap says.

This page is about the second half: Topics, Protected Audience, Attribution Reporting, Shared Storage, Private Aggregation, Fenced Frames, CHIPS, the Storage Access API, Related Website Sets and Private State Tokens — what shipped, what is being torn out, what a crawler can see of any of it, and what the seven-venue publication corpus has and has not measured. The cookie side is Cookies; the partitioning of storage is Browser storage; what your automation library does to the engine's partitioning posture is Since 2022 the engine decides, not you.

• Fledging Will Continue Until Privacy Improves [1Calderonio, Giuseppe; Ali, Mir Masood; Polakis, Jason (2024): "Fledging Will Continue Until Privacy Improves: Empirical Analysis of Google's Privacy-Preserving Targeted Advertising", in: Proceedings of the USENIX Security Symposium, pp. 4121-4138. (Link)], USENIX Security 2024 — the only deployment-scale crawl of Protected Audience in this corpus, and the model for how to instrument one. Read §3 for the method (wrapper functions injected by Puppeteer) before you read the results.
• Exploiting the Shared Storage API [2Nisenoff, Alexandra; Stefan, Deian; Christin, Nicolas (2025): "Exploiting the Shared Storage API", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], CCS 2025 — the most recent Privacy Sandbox measurement in the corpus, and the one that shows what the attestation artefacts give you for free.
• Interest-disclosing Mechanisms for Advertising are Privacy-Exposing (not Preserving) [3Beugin, Yohan; McDaniel, Patrick (2024): "Interest-disclosing Mechanisms for Advertising are Privacy-Exposing (not Preserving)", in: Proceedings on Privacy Enhancing Technologies. (DOI)], PoPETs 2024 — the systematic privacy analysis of Topics, with the re-identification numbers everyone cites.
• A First Look at Related Website Sets [4McQuistin, Stephen; Snyder, Peter; Haddadi, Hamed; Tyson, Gareth (2024): "A First Look at Related Website Sets", in: Proceedings of the ACM Internet Measurement Conference. (DOI)], IMC 2024 — the template for measuring a Privacy Sandbox governance artefact (a GitHub list and its pull requests) rather than a browser API.
• Then the primary sources, because no paper is current: Google's own Privacy Sandbox feature status page and the per-feature entries on Chrome Platform Status.

Every row was checked on 2026-09-01 against Chrome Platform Status' JSON API and Google's own status page — not against documentation, blog posts or memory. The Detection column is the expression this page measured in Chromium 151.0.7922.34; read Presence is not availability, and neither is a return value before you use it.

Google's status page also lists Fenced Storage Read, Private Proofs, Probabilistic Reveal Tokens and Script Blocking as Do not launch, and Partitioned Popins and Related Website Partition as Discontinue. If you meet one of those names in a 2024 explainer, it never shipped.⁴⁾

The single most common error in a Privacy Sandbox paper is to cite a Google announcement as though it described the browser. Between 2020 and 2026 the announced plan changed direction four times, and each reversal invalidated the motivation section of papers already in submission.

Measured here, 2026-09-01, Chromium 151.0.7922.34 as shipped with Playwright 1.62.1. Every Privacy Sandbox JS surface is present under the default flags of both Playwright and Puppeteer, and document.featurePolicy.allowsFeature() returns true for all six ads-API Permissions-Policy features (browsing-topics, join-ad-interest-group, run-ad-auction, attribution-reporting, shared-storage, private-aggregation). Adding --enable-features=PrivacySandboxAdsAPIsOverride changed nothing, in either library. (Puppeteer was pointed at the same Chromium binary via chromium.executablePath(), so this is a comparison of the two libraries' default flag sets, not of two browser builds.)

That is the easy half. The hard half is that calling them tells you nothing either. On an HTTPS page served from a domain that is definitely not enrolled, every call returned a benign empty value rather than throwing:

document.browsingTopics()              RETURNED []
navigator.joinAdInterestGroup()        RETURNED undefined
navigator.runAdAuction()               RETURNED null
sharedStorage.set()                    RETURNED undefined
document.hasPrivateToken()             RETURNED false
document.requestStorageAccess()        RETURNED undefined
fetch(..., {attributionReporting})     RETURNED 200

The same four outputs came back from localhost, from a mapped non-enrolled public-looking domain, with the ads-API override on, and with --privacy-sandbox-enrollment-overrides pointed at the origin. A crawler cannot distinguish “the API is on and there was nothing to report” from “the API is off for this profile” from “this caller is not enrolled” by looking at the return value. An empty Topics array is the expected result on a fresh profile with no history, and it is also what a disabled API gives you.

The consequence for a measurement is direct: do not report “N% of sites can use the Topics API” from a feature-detection sweep. Presence of the symbol is a fact about the browser build, identical on every site. The only site-level facts are (a) whether site code called the API, and (b) whether the caller is enrolled — and those need the instrumentation below.

Chromium's CDP Storage domain carries first-class Privacy Sandbox instrumentation, which is far cheaper than injecting wrappers. Enumerated from the browser's own /json/protocol descriptor, Chromium 151.0.7922.34, 2026-09-01:

Tip-of-tree is the ChromeDevTools/devtools-protocol master descriptor, fetched 2026-09-01: the Privacy Sandbox commands and all five events are already absent there. The instrumentation is being removed with the API. If you intend to record Protected Audience or Shared Storage activity, pin a Chromium at or before the removal milestone and say which one; a crawl on evergreen Chrome will silently stop producing events.

This is the script this page ran, in full, not an abridged illustration: it stands up a local HTTPS origin with a bidding script, a decision script and a Shared Storage worklet, maps a non-localhost name onto it, drives every API, and prints what CDP delivered. Pointing the same listeners at an ordinary site you do not control will usually print nothing, which is why the mock origin is part of the script rather than an exercise for the reader.

ps_cdp_probe.mjs

// Can a crawler RECORD Privacy Sandbox activity? The CDP Storage domain has
// tracking toggles for interest groups, Shared Storage and Attribution
// Reporting. This probe turns them on, drives each API from a page, and prints
// the events that actually arrive.
//
//   PLAYWRIGHT_BROWSERS_PATH=/workspace/.playwright node sandbox/ps_cdp_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(), 'pscdp-'));
execSync(
  `openssl req -x509 -newkey rsa:2048 -nodes -keyout ${dir}/k.pem -out ${dir}/c.pem -days 2 -subj "/CN=probe.example" -addext "subjectAltName=DNS:probe.example"`,
  { stdio: 'ignore' }
);
 
const PAGE = `<!doctype html><meta charset=utf-8><title>ps</title>`;
const BID = `function generateBid(){return {ad:'a',bid:1,render:'https://probe.example:8444/ad.html'};}
function reportWin(){}`;
const DEC = `function scoreAd(){return 1;} function reportResult(){}`;
const WORKLET = `class P { async run() { return 0; } }
register('p', P);`;
 
const server = https.createServer(
  { key: fs.readFileSync(`${dir}/k.pem`), cert: fs.readFileSync(`${dir}/c.pem`) },
  (req, res) => {
    const js = { 'content-type': 'application/javascript' };
    if (req.url === '/bid.js') return res.writeHead(200, js).end(BID);
    if (req.url === '/decide.js') return res.writeHead(200, js).end(DEC);
    if (req.url === '/w.js') return res.writeHead(200, js).end(WORKLET);
    if (req.url === '/ad.html') return res.writeHead(200, { 'content-type': 'text/html' }).end('<b>ad</b>');
    res.writeHead(200, { 'content-type': 'text/html' }).end(PAGE);
  }
);
await new Promise((r) => server.listen(8444, '127.0.0.1', r));
 
const b = await chromium.launch({
  headless: true,
  args: [
    '--host-resolver-rules=MAP probe.example 127.0.0.1',
    '--ignore-certificate-errors',
    '--enable-features=PrivacySandboxAdsAPIsOverride',
    '--privacy-sandbox-enrollment-overrides=https://probe.example:8444',
  ],
});
const ctx = await b.newContext({ ignoreHTTPSErrors: true });
const page = await ctx.newPage();
const cdp = await ctx.newCDPSession(page);
 
const events = [];
for (const ev of [
  'Storage.interestGroupAccessed',
  'Storage.interestGroupAuctionEventOccurred',
  'Storage.interestGroupAuctionNetworkRequestCreated',
  'Storage.sharedStorageAccessed',
  'Storage.sharedStorageWorkletOperationExecutionFinished',
  'Storage.attributionReportingSourceRegistered',
  'Storage.attributionReportingTriggerRegistered',
]) cdp.on(ev, (p) => events.push([ev, JSON.stringify(p).slice(0, 220)]));
 
const toggles = [
  ['Storage.setInterestGroupTracking', { enable: true }],
  ['Storage.setInterestGroupAuctionTracking', { enable: true }],
  ['Storage.setSharedStorageTracking', { enable: true }],
  ['Storage.setAttributionReportingTracking', { enable: true }],
];
for (const [m, params] of toggles) {
  try {
    await cdp.send(m, params);
    console.log(`  toggle OK    ${m}`);
  } catch (e) {
    console.log(`  toggle FAIL  ${m}: ${String(e.message).slice(0, 90)}`);
  }
}
 
await page.goto('https://probe.example:8444/', { waitUntil: 'domcontentloaded' });
const res = await page.evaluate(`(async () => {
  const o = {};
  const t = async (n, f) => { try { o[n] = 'ok ' + JSON.stringify(await f()); } catch (e) { o[n] = 'ERR ' + String(e.message).slice(0,110); } };
  await t('joinAdInterestGroup', () => navigator.joinAdInterestGroup({
    owner: location.origin, name: 'probe', biddingLogicURL: location.origin + '/bid.js',
    ads: [{ renderURL: location.origin + '/ad.html', metadata: {} }],
  }, 3600));
  await t('runAdAuction', () => navigator.runAdAuction({
    seller: location.origin, decisionLogicURL: location.origin + '/decide.js',
    interestGroupBuyers: [location.origin], resolveToConfig: false,
  }));
  await t('sharedStorage.set', () => window.sharedStorage.set('k', 'v'));
  await t('sharedStorage.addModule', () => window.sharedStorage.worklet.addModule('/w.js'));
  await t('sharedStorage.run', () => window.sharedStorage.run('p', {}));
  return o;
})()`);
await page.waitForTimeout(2500);
 
console.log('\n== API calls from the page ==');
for (const [k, v] of Object.entries(res)) console.log(`  ${k.padEnd(22)} ${v}`);
console.log(`\n== CDP events received (${events.length}) ==`);
for (const [ev, p] of events) console.log(`  ${ev.padEnd(52)} ${p}`);
if (!events.length) console.log('  (none)');
 
await b.close();
server.close();

Its real output on 2026-09-01: three toggles accepted, Storage.setAttributionReportingTracking rejected with a protocol error (it does not exist), and seven events delivered — one auction started, two auction network requests (bidderJs and sellerJs), three sharedStorageAccessed (set, addModule, run) and one sharedStorageWorkletOperationExecutionFinished. Removing the setSharedStorageTracking toggle drops that to three, so the toggles are load-bearing rather than decorative.

A sharedStorageAccessed event carries accessTime, scope (window or the worklet), method (set, addModule, run, selectURL, …), ownerOrigin, ownerSite and the call's params — that is, everything needed to reproduce [2Nisenoff, Alexandra; Stefan, Deian; Christin, Nicolas (2025): "Exploiting the Shared Storage API", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]'s prevalence figure without writing a page-script wrapper at all. An auction produces interestGroupAuctionEventOccurred with a uniqueAuctionId and the full auctionConfig, followed by interestGroupAuctionNetworkRequestCreated entries tagged bidderJs and sellerJs — the seller attribution that gives [1Calderonio, Giuseppe; Ali, Mir Masood; Polakis, Jason (2024): "Fledging Will Continue Until Privacy Improves: Empirical Analysis of Google's Privacy-Preserving Targeted Advertising", in: Proceedings of the USENIX Security Symposium, pp. 4121-4138. (Link)]'s 99.8% figure.

Topics and Attribution Reporting have no CDP surface at all, in any Chromium version checked. For those, the corpus's method is the one to copy: [1Calderonio, Giuseppe; Ali, Mir Masood; Polakis, Jason (2024): "Fledging Will Continue Until Privacy Improves: Empirical Analysis of Google's Privacy-Preserving Targeted Advertising", in: Proceedings of the USENIX Security Symposium, pp. 4121-4138. (Link)] “used Puppeteer to orchestrate Chrome”, visiting each domain in a fresh browser instance, and “injects wrapper functions into the page and logs all” calls to navigator.runAdAuction, navigator.joinAdInterestGroup and navigator.leaveAdInterestGroup. Inject the wrapper before any page script runs — page.addInitScript() in Playwright, page.evaluateOnNewDocument() in Puppeteer — and wrap document.browsingTopics, the attributionReporting option on fetch, and the attributionSrc setter on HTMLAnchorElement/HTMLImageElement the same way.

Two things this costs you, both worth a sentence in your methods section: a wrapper is visible to page script and is therefore detectable (Crawler detection), and it sees only the main world unless you also install it into every frame and worklet.

Firefox and Safari never implemented Topics, Protected Audience, Shared Storage, Fenced Frames or Private Aggregation. The Storage Access API and CHIPS are the exceptions with genuine cross-browser support. Two attribution efforts outside Chrome are worth dating rather than assuming:

• Firefox Privacy-Preserving Attribution (PPA) shipped as an experiment in Firefox 128 (July 2024), scoped to Mozilla-operated sites, and drew a noyb complaint to the Austrian DPA for being on by default. Bugzilla 1979093, “Remove checkbox in settings for feature that was never enabled”, is RESOLVED FIXED against the 143 Branch (last changed 2025-08-21).⁷⁾
• W3C Attribution Level 1 is a live W3C Working Draft from the Private Advertising Technology Working Group, fetched 2026-09-01 at w3.org/TR/attribution. Google's 2025-10-17 post says it will “continue to engage on it through the web standards process”. No browser ships it. This is the surface to watch, not to measure.

OpenWPM cannot observe any of this, because it drives Firefox — still true at v0.36.0, released 2026-08-24, whose README opens “OpenWPM is built on top of Firefox”. If your instrument is OpenWPM, a Privacy Sandbox measurement is not a configuration change, it is a different crawler.

Privacy Sandbox is unusually generous with public artefacts, and three of the four measurement papers in the corpus lean on them. All counts below were taken on 2026-09-01.

The enrollment report is also a measurement in itself. Of its 326 rows, the Chrome APIs each enrollee asked for:

25 of the 326 rows declare no Chrome API at all (they are Android-only enrolments). Read this as intent to call, not as deployment: an enrolment is a form somebody filled in, and [2Nisenoff, Alexandra; Stefan, Deian; Christin, Nicolas (2025): "Exploiting the Shared Storage API", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] found that the API traffic on real sites came from four domains, not from hundreds.

The full-text sweep ran over the 5,869 papers with a paper.cols.txt in the corpus (seven venues, 2010–2026; the structured extraction covers 5,859 of them). Free-text API names were folded through scripts/ps_fold.mjs so that FLoC counts with Topics, FLEDGE and TURTLEDOVE with Protected Audience, and First-Party Sets with Related Website Sets.

This is the page's central limitation and it belongs at the top of the section rather than in a footnote. A dozen papers in seven venues over sixteen years is not a literature; it is a handful of studies, and every generalisation on this page rests on them. Anything you want to know that the table below does not answer, the corpus cannot tell you — go to the specs and to Chrome Platform Status.

And by year, which is the more useful shape — this is a topic the corpus noticed late and is already losing interest in:

The field is crawling Chrome and not looking at what Chrome now does.

“Web crawl” is crawlConfig != null or studyTypes containing automated-web-crawl, and platforms containing web. The last row's denominator is papers that stated a browser: crawlConfig.browsers is stated by only 47.2% of the 1,120 crawling papers in the corpus, so 86 is a lower bound on Chrome-driving crawls, and 9.3% is a share of the ones that told you.

If you are looking for a gap to fill, Attribution Reporting is measured by nobody. Three papers in 5,869 name it — a related-work list, a browser-permissions census that counts how often sites feature-detect it, and one arXiv citation in a reference list. Not one instruments it, crawls for it, or reports its deployment prevalence. Given the M153 target, the window to measure a deployed Attribution Reporting API in Chrome is now measured in days.

Each row names the paper's own population. Nothing here is a share of the corpus.

One adjacent paper gives the CHIPS context without measuring the attribute: [12Nikkhah Bahrami, Pouneh; Fass, Aurore; Shafiq, Zubair (2025): "CookieGuard: Characterizing and Isolating the First-Party Cookie Jar", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] (IMC 2025) describes CHIPS as “an opt-in model for cookie partitioning” and contrasts it with Firefox's Total Cookie Protection and Safari's ITP, which partition by default — which is why a CHIPS adoption figure is a measure of publisher and tracker uptake, not of browser policy. ([13Kancherla, Gayatri Priyadarsini; Goel, Dishank; Bichhawat, Abhishek (2025): "Least Privilege Access for Persistent Storage Mechanisms in Web Browsers", in: Proceedings of the ACM Web Conference. (DOI)] is cited on this page only for its third-party storage-access figures on Browser storage; it never discusses CHIPS, and an earlier draft wrongly attached this claim to it.) The only dedicated CHIPS adoption study we found is outside these seven venues: Zöllner, Feldmann and Dao, A First Look at Cookies Having Independent Partitioned State, PAM 2025.⁸⁾ We have not read it and quote no figure from it.

• A site-level prevalence figure is a fact about a handful of scripts. [2Nisenoff, Alexandra; Stefan, Deian; Christin, Nicolas (2025): "Exploiting the Shared Storage API", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] found Shared Storage on 10.1% of reachable sites and four distinct callers. [1Calderonio, Giuseppe; Ali, Mir Masood; Polakis, Jason (2024): "Fledging Will Continue Until Privacy Improves: Empirical Analysis of Google's Privacy-Preserving Targeted Advertising", in: Proceedings of the USENIX Security Symposium, pp. 4121-4138. (Link)] found FLEDGE on 9.5% of 70K sites and 99.8% of auctions run by one seller. Publish the distinct-caller count in the same table as the site share, or your reader will conclude that a tenth of the web adopted an API when a tenth of the web embeds one ad tag.
• A union over snapshots is not a prevalence. [1Calderonio, Giuseppe; Ali, Mir Masood; Polakis, Jason (2024): "Fledging Will Continue Until Privacy Improves: Empirical Analysis of Google's Privacy-Preserving Targeted Advertising", in: Proceedings of the USENIX Security Symposium, pp. 4121-4138. (Link)]'s 6,682 sites is the union over three crawls; the per-snapshot counts fell, 4,628 in June to 3,903 in July to 3,585 in September 2023. Say which one your number is.
• Presence, enablement and use are three different measurements, and only the third is a property of the site. See Presence is not availability, and neither is a return value.
• Enrollment is intent, not deployment. 326 enrolled companies; four observed callers.
• The browser version is the measurement. These APIs shipped at M114–M116 in mid-2023 and are targeted for removal at M152–M155 in 2026. A crawl that does not report its Chrome version has reported nothing checkable, and a longitudinal series that spans the removal is measuring the browser, not the web. This is the longitudinal problem in its sharpest form.
• Your automation library is not a stock browser. Playwright disables ThirdPartyStoragePartitioning by default, which is exactly the axis CHIPS is about — see Partitioning: Your Crawler and a Real Browser Disagree and Since 2022 the engine decides, not you. Measured on this page: Playwright's default list does not disable any of the ads APIs.
• Cross-browser comparison is not available. No non-Chromium engine implements the ads APIs, so “Chrome vs Firefox” on a Privacy Sandbox question compares an implementation with an absence.
• What we could not establish: whether Chrome's ads APIs are gated differently in the EEA or the UK than elsewhere. It would be reasonable to expect a DMA-driven consent gate, but reasonable is not measured: Google's two API-availability pages both return HTTP 404 as of 2026-09-01, we found no primary statement of the current regional behaviour anywhere on Google's documentation, and this run had a single vantage point. If your crawl is comparative across regions (Crawling location), test this yourself and report what you found — do not assume either way.

1. The exact Chromium/Chrome version, not “Chrome”. 151.0.7922.34, not “the latest Chrome”. Everything on this page changes between milestones.
2. The automation library and version, and the full --enable-features / --disable-features lists you passed, because the library passes its own.
3. Which observation surface you used: CDP Storage events, injected JS wrappers, or the enrollment/attestation artefacts. They see different things and none of them sees all of it.
4. Whether you enrolled or overrode enrollment, and for which origins.
5. The distinct-caller count alongside any site-level prevalence.
6. Per-snapshot counts, not only the union, for any repeated crawl.
7. The date the artefact list was taken, for the enrollment report, the attestation .dat and the RWS list — all three change under you, and two of the three are now frozen by archival.
8. That the API still existed in your build, stated as a fact you checked rather than assumed. After M153 this stops being pedantry.

• Classifying cookies — the mechanism that did not go away, and the 2025 reversal in its own context.
• Storage beyond cookies — partitioning of localStorage, IndexedDB and the caches, and the Playwright-versus-Puppeteer disagreement about whether it is on.
• Stateful vs stateless crawling — why your crawler's third-party state does not resemble a real user's.
• Cookie and ID syncing — where identifiers went instead, and the same correction to the “third-party cookies are disappearing” framing.
• Classifying web requests and Filter lists — the classifiers that a Privacy Sandbox call is invisible to.
• When the website notices your crawler — injected API wrappers are detectable.
• Repeating a measurement over time — pinning the browser, which here is the whole problem.
• Crawling location — if regional gating exists, this is where it bites.
• Provenance of this page's figures.

Corpus figures come from the 5,859-paper extraction over seven venues (CCS, IMC, NDSS, PETS, 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. EuroS&P, ACSAC, RAID, AsiaCCS, CHI, SOUPS, PAM and WPES are not in it, and the CHIPS study named above is an example of relevant work that therefore does not appear in any count. 2025 and 2026 venue-years are provisional.

Every browser measurement on this page was taken on 2026-09-01 against Chromium 151.0.7922.34 as shipped with Playwright 1.62.1, in a Linux container, headless. Non-Chromium engines were not probed first-hand: the Firefox build available here fails to launch in this environment, so the Firefox and Safari statements rest on Bugzilla and vendor documentation, not on measurement.

The full query log — every population and denominator, the report script and its unedited output, the folding rules with the regexes that were measured and rejected, the quote spot-checks, the external sources verified and the ones discarded — is at privacy_sandbox. Corpus-level caveats are on corpus.

[1]

Calderonio, Giuseppe; Ali, Mir Masood; Polakis, Jason (2024): "Fledging Will Continue Until Privacy Improves: Empirical Analysis of Google's Privacy-Preserving Targeted Advertising", in: Proceedings of the USENIX Security Symposium, pp. 4121-4138. (Link)

[2]

Nisenoff, Alexandra; Stefan, Deian; Christin, Nicolas (2025): "Exploiting the Shared Storage API", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[3]

Beugin, Yohan; McDaniel, Patrick (2024): "Interest-disclosing Mechanisms for Advertising are Privacy-Exposing (not Preserving)", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[4]

McQuistin, Stephen; Snyder, Peter; Haddadi, Hamed; Tyson, Gareth (2024): "A First Look at Related Website Sets", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[5]

Berke, Alex; Calacci, Dan (2022): "Privacy Limitations of Interest-based Advertising on The Web: A Post-mortem Empirical Analysis of Google's FLoC", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[6]

Jha, Nikhil; Trevisan, Martino; Leonardi, Emilio; Mellia, Marco (2023): "On the Robustness of Topics API to a Re-Identification Attack", Proceedings on Privacy Enhancing Technologies 2023(4):66-78. (DOI)

[7]

Alvim, Mário S.; Fernandes, Natasha; McIver, Annabelle; Nunes, Gabriel H. (2024): "The Privacy-Utility Trade-off in the Topics API", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[8]

Turati, Florian; Kubicek, Karel; Cotrini, Carlos; Basin, David (2023): "Locality-Sensitive Hashing Does Not Guarantee Privacy! Attacks on Google's FLoC and the MinHash Hierarchy System", Proceedings on Privacy Enhancing Technologies 2023(4):117-131. (DOI)

[9]

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)

[10]

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)

[11]

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)

[12]

Nikkhah Bahrami, Pouneh; Fass, Aurore; Shafiq, Zubair (2025): "CookieGuard: Characterizing and Isolating the First-Party Cookie Jar", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[13]

Kancherla, Gayatri Priyadarsini; Goel, Dishank; Bichhawat, Abhishek (2025): "Least Privilege Access for Persistent Storage Mechanisms in Web Browsers", in: Proceedings of the ACM Web Conference. (DOI)