petsymposium.org/2026/cfposters.php and …/accepted-posters.php, both fetched 2026-08-21.This is an old revision of the document!
Server-side tracking (SST, also server-side tagging) moves the reporting half of a tracker off the user's device. The browser still collects the data, but instead of sending it to google-analytics.com or facebook.com/tr it sends it to an endpoint the publisher controls — sgtm.example.com, or just example.com/collect — and that endpoint forwards it to the tracking platforms server-to-server. Google shipped it as server-side Google Tag Manager in August 2020; Meta, Microsoft, TikTok, Snapchat, Reddit and Netflix all sell an equivalent.
This page is about what that does to your measurement, not about how to deploy it. If you are classifying web requests, cookies or JavaScript, SST is the reason your instrument can be working perfectly and still be wrong: the direct client-to-tracker request that every request-level method keys on is simply absent, and the cookie that used to be third-party is now first-party and named whatever the publisher chose.
The one thing to understand before you start: the four published prevalence estimates differ by a factor of a hundred, and almost none of the difference is real. They range from 0.38% of visited sites to 38%, and the spread is produced by what each study defined as SST, what it crawled, and — most of all — whether the crawler did anything on the page. SST fires on events (page_view, scroll, click); a landing-page-only crawl that never interacts sees the fewest of them. Of the four studies, one is an unrefereed preprint and another is accepted but not yet presented. Until CCS 2026 is held there is exactly one peer-reviewed SST detection method in the seven venues of this site's publication corpus — Fouad et al. [1Fouad, Imane; Santos, Cristiana; Laperdrix, Pierre (2024): "The Devil is in the Details: Detection, Measurement and Lawfulness of Server-Side Tracking on the Web", Proceedings on Privacy Enhancing Technologies 2024(4):450-465. (DOI)], PETS 2024 — and it cannot be re-run, because it requires a crawl made before August 2020. A second, Mertens et al. [2Mertens, Gilles; Bielova, Nataliia; Roca, Vincent; Bouhoula, Ahmed; Akassab, Marouane (2026): "Detecting and Measuring Client- and Server-Side Google Tag Manager and its Tags in 80K Websites", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. Accepted at CCS 2026 (verified on the SIGSAC accepted-papers list, 21 August 2026); to appear. Preprint at HAL hal-05466083v2, submitted 6 February 2026, under the title "An Analysis of Client- and Server-Side Google Tag Manager and its Tags on the Web" (Link)], is accepted at CCS 2026 and is therefore absent from every corpus figure on this page purely because that venue-year has not happened yet. So do not open with “prior work finds SST on X% of sites”. Say which definition, which population, and which interaction depth, or the number means nothing.
journal_ref). It was shown as a poster at PETS 2026 on 22 July 2026, which is a venue appearance but not a review: the call for posters says proposals are “lightly reviewed for relevance to PETS and adherence to formatting guidelines” and “Posters will not be peer-reviewed”.1). Read it because it is the current state of the detection art and because its artefacts are public; read the audit in Auditing SST-Guard against its own released artefacts before you reuse either.Every row is a different question. Read the Definition detected column before the Result column.
| Study | Status | Population, vantage, interaction | Definition detected | Result |
|---|---|---|---|---|
| Fouad et al. [1Fouad, Imane; Santos, Cristiana; Laperdrix, Pierre (2024): "The Devil is in the Details: Detection, Measurement and Lawfulness of Server-Side Tracking on the Web", Proceedings on Privacy Enhancing Technologies 2024(4):450-465. (DOI)] | Peer-reviewed, PETS 2024 | Alexa top 10,000 → 7,367 sites visited in all crawls; EU vantage; OpenWPM + Firefox; stateless; no banner interaction; landing page only | First-party SST: a subdomain that (1) appeared only after Aug 2020, (2) resolves to a different WHOIS organisation, (3) sets or receives an ID cookie, and (4) receives parameters or cookies that two or more now-absent trackers used to receive | 28 sites (0.38%) deploy SST. 389 sites (5.28%) carry a cloaked tracker |
| Moti et al. [6Moti, Zahra; Frings, Kimberley; Utz, Christine; Zuiderveen Borgesius, Frederik; Acar, Gunes (2025): "The Bitter Pill: Tracking and Remarketing on EU Pharmacy Websites", in: Data Privacy Management, Cryptology and Information Security. (Link)] | Peer-reviewed workshop (DPM 2025), outside these seven venues | 50 EU pharmacy sites, five countries; manual shopping for a pregnancy test; accept and reject conditions | Requests carrying any of 36 parameters common to GTM-initiated requests, confirmed by WHOIS organisation mismatch on the first-party subdomain | 19 of 50 (38%); 12 of the 19 SST servers hosted by Google |
| Mertens et al. [2Mertens, Gilles; Bielova, Nataliia; Roca, Vincent; Bouhoula, Ahmed; Akassab, Marouane (2026): "Detecting and Measuring Client- and Server-Side Google Tag Manager and its Tags in 80K Websites", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. Accepted at CCS 2026 (verified on the SIGSAC accepted-papers list, 21 August 2026); to appear. Preprint at HAL hal-05466083v2, submitted 6 February 2026, under the title "An Analysis of Client- and Server-Side Google Tag Manager and its Tags on the Web" (Link)] | Accepted at ACM CCS 2026, to appear; the only text available today is the HAL preprint of 2026-02-06 | 80,000 popular sites worldwide | Server-side GTM identified by template signatures derived from the GTM template marketplace | sGTM on ~3,000 sites (~3.8%); 398 server-side Tag instances |
| SST-Guard [4Jazlan, Muhammad; Gamero-Garrido, Alexander; Shafiq, Zubair; Vekaria, Yash (2026): "SST-Guard: Detecting and Characterizing Server-Side Google Analytics in the Wild". Preprint, arXiv v1 of 30 April 2026; also presented as a poster at PETS 2026, which states that posters "will not be peer-reviewed". Not peer-reviewed as of 21 August 2026 (DOI)] | arXiv preprint, 2026-04-30; also a PETS 2026 poster, and PETS states that posters “will not be peer-reviewed” | Tranco top-150K → 128,222 domains classified; Chrome + Playwright; Consent-O-Matic set to accept all; scroll to bottom, random pauses, random clicks, one same-site subpage | Server-side Google Analytics only: regex value templates matched against request parameters, first-party cookies and window variables | 6,314 domains — 4.21% of the 150K list, 4.92% of the 128,222 actually classified |
Three things follow, and they are the reusable part of this table.
page_view, you are measuring the floor. This is the single largest methodological lever on this page and nobody has isolated it — see Open Questions.A ranking of what the literature did is a fact about the literature, not advice about what to do now. Statuses below are as of 2026-08-21. The corpus reaches 2026, but its 2025–2026 venue-years are provisional (CCS and IMC 2026 have not been held; IEEE S&P and TheWebConf 2026 are incompletely selected — see Corpus), so every “current” row was checked against material outside the corpus as well.
| Era | Method | Work | Status in 2026 |
|---|---|---|---|
| 2020–2021 | Resolve the CNAME chain, then match the target against a tracker list | [7Dimova, 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)], [8Dao, Ha; Mazel, Johan; Fukuda, Kensuke (2021): "CNAME Cloaking-Based Tracking on the Web: Characterization, Detection, and Protection", IEEE Transactions on Network and Service Management 18(3):3873-3888. (DOI)], [9Aliyeva, Assel; Egele, Manuel (2021): "Oversharing Is Not Caring: How CNAME Cloaking Can Expose Your Session Cookies", in: Proceedings of the ACM Asia Conference on Computer and Communications Security, pp. 123-134. (DOI)] | Necessary but no longer sufficient. SST-Guard finds only 26.49% of subdomain-based sGA deployments use a CNAME at all; the other 73.51% point straight at an A/AAAA record with no DNS indirection to detect. Safari's CNAME mitigation and AdGuard's CNAME list2) both address the 26% |
| 2022–2024 | Temporal shift plus organisation cloaking: diff a pre-SST crawl against a post-SST crawl, keep subdomains that are new, WHOIS-mismatched, ID-bearing, and that inherited parameters from vanished trackers | [1Fouad, Imane; Santos, Cristiana; Laperdrix, Pierre (2024): "The Devil is in the Details: Detection, Measurement and Lawfulness of Server-Side Tracking on the Web", Proceedings on Privacy Enhancing Technologies 2024(4):450-465. (DOI)] | Historical, and not reproducible. It is the only peer-reviewed SST detector in these seven venues and its logic is still the clearest published statement of what SST is. But step one needs a crawl predating August 2020. You cannot run this method today unless you happen to own a 2020 crawl of your population. Cite it for the definition; do not plan a study around it |
| 2025 | Parameter-intersection heuristic, history-free: take the parameter names common to GTM-initiated requests, look for them on first-party endpoints, confirm with WHOIS | [6Moti, Zahra; Frings, Kimberley; Utz, Christine; Zuiderveen Borgesius, Frederik; Acar, Gunes (2025): "The Bitter Pill: Tracking and Remarketing on EU Pharmacy Websites", in: Data Privacy Management, Cryptology and Information Security. (Link)] | Current, cheap, and the one to start with if you need an SST flag as a side quantity in a larger study. It needs only request logs plus DNS and WHOIS. Its cost is measured: SST-Guard replicated it with the 36 parameters obtained from those authors and recovered 129 of 403 ground-truth domains, 32% accuracy, against SST-Guard's 401 and 99.5% |
| 2026 | Vendor template signatures: enumerate the sGTM template marketplace and fingerprint each template's client-side artefacts | [2Mertens, Gilles; Bielova, Nataliia; Roca, Vincent; Bouhoula, Ahmed; Akassab, Marouane (2026): "Detecting and Measuring Client- and Server-Side Google Tag Manager and its Tags in 80K Websites", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. Accepted at CCS 2026 (verified on the SIGSAC accepted-papers list, 21 August 2026); to appear. Preprint at HAL hal-05466083v2, submitted 6 February 2026, under the title "An Analysis of Client- and Server-Side Google Tag Manager and its Tags on the Web" (Link)] | Current, and about to become the only peer-reviewed runnable method — it is accepted at CCS 2026. Narrow by construction, though: it covers sGTM only, so it misses gtag.js deployments and any custom container, and it can only recognise templates that are on the marketplace. SST-Guard declines to compare against it, on the stated grounds of low dataset overlap and no available validation |
| 2026 | Value templates across three browser modalities — regexes matched against the values in request parameters, first-party cookies and window variables, one logistic regression per modality plus a meta-classifier | [4Jazlan, Muhammad; Gamero-Garrido, Alexander; Shafiq, Zubair; Vekaria, Yash (2026): "SST-Guard: Detecting and Characterizing Server-Side Google Analytics in the Wild". Preprint, arXiv v1 of 30 April 2026; also presented as a poster at PETS 2026, which states that posters "will not be peer-reviewed". Not peer-reviewed as of 21 August 2026 (DOI)] | The state of the art, and not peer-reviewed. It is the right idea: the reporting endpoint is attacker-controlled but the semantics of what GA collects are not, because Google cannot rename dataLayer without breaking millions of sites. Its measured numbers are the best published. Its released artefacts do not reproduce its own figures — see the next section before you build on it |
| — | Taint tracking from DOM event to network request | nobody | The open problem, and SST-Guard names it as such: “the more a tracker decouples client-side collection from server-side reporting, the less our approach has to match against”. It is also the only approach that would generalise past Google |
example.com/collect), which no subdomain-based or DNS-based method can see — SST-Guard says so plainly and excludes them from its own network analysis. And this is the direction of travel: Google's current documentation recommends same-origin serving first, ahead of the subdomain option.3) Design for path-based deployments now, not later.Version: 202608210608, commit 0ad9e733): the list carries ?v=2&tid=G-$~third-party — note the $~third-party modifier, which exists precisely to catch first-party tracking — plus &sst.sw_exp= and &sst.gcsub= for server-side container parameters, and per-site rules including ||mstm.motorsport.com^ and nine hosts beginning sst. What lists cannot see is the customised tail: 166 domains (2.62%) where nothing was blocked, and 223 domains sending base64-encoded payloads.The SST-Guard repository5) publishes the ground truth, the classifier output on the ground truth, the 40k-row request-level output of the 150K crawl, the list of 6,314 detected domains, and a packaged Chrome extension. It does not publish the pipeline that produced the paper's numbers. The extension is the only code, and it ships minified.
The detection heuristics that decide whether a request is sGA are therefore in the bundle, not in the paper, so they were extracted from it and exercised. Two scripts do this and their unedited output is on the provenance page. This is a source audit, not a reproduction attempt: no crawl was re-run.
| Signal | Reproducible from a crawl you can run? |
|---|---|
window variables — dataLayer event shapes, gaGlobal[hid], gaGlobal[from_cookie], google_tag_data container ID | Yes, and this is the modality to build on. It is the paper's own strongest argument and it holds: Google cannot rename dataLayer or google_tag_data without breaking every publisher integration built on them. Note this modality needs a window snapshot, which most crawlers do not take |
_ga / _ga_X / _gid cookie patterns, and the network cid | Yes — until 2027-01-15. All five shipped cookie templates and the cid template hard-code the literal 17 prefix of a ten-digit Unix timestamp (/^GA1\.[123](-2)?\.[0-9]{6,10}\.17[0-9]{8,13}$/). That prefix covers 2023-11-14 to 2027-01-15 and nothing after it. Verified by running the shipped regexes against synthetic values: t=1799999999 matches, t=1800000000 does not |
window chrome_version, platform_version, architecture, bitness | No. These are literals: /"144\.0\.7559\.97"/, /"26\.2\.0"/, /"arm"/, /"64"/. They fire only for one Chrome build on one Apple-Silicon machine and match nothing on your crawler |
Network uap, uapv, uaa | No. /Linux/, /5\.15\.0/, /x86/ — that is the paper's own crawl host (Ubuntu 22.04, Linux 5.15.0). Note these pin a different machine from the window templates above, so the shipped extension carries two mutually inconsistent environment fingerprints |
Network dl (document location) | No — the shipped regex is broken. /https:\/\/[\^\s&#]+/ is a character class containing an escaped literal caret, not a negation, so it matches https:// followed only by ^, whitespace, & or #. It matches no ordinary URL. It is 1 in 98.4% of the authors' own published rows and 0.0% under the released extension |
Network uafvl | No. 99.5% in the published data, 0.0% under the shipped regex |
Network sid /\d{10}/, _p /\d{13}/, uab /64/, tfd /\d{3,4}/, _eu, ul | Yes, but they carry no information. 1234567890 sets sid and tfd; x86_64 sets uab; de sets _eu and ul. Any HTTP status code matches tfd. These are consistent with the paper's own 73.36% request-level precision on its training labels |
Network gcs, tcfd, ep.user_agent | Not exercised in the release at all — all three columns are constant zero across all 40,198 published rows, while the shipped regexes fire on 73.3%, 11.0% and 2.9% of the same URLs |
The extension's extractor tests each template against the query parameter of the same name. Replaying it over the 40,198 published request URLs and diffing against the published feature columns gives 79.3% per-cell agreement. A variant that tests each template against every parameter value gives 83.1%, and reaches 100% for 12 of the 23 features. The residue is exactly the rows above: dl and uafvl (shipped regex dead), gcs / tcfd / ep.user_agent (published column dead), and gtm at 91.5%.
Read that as: the offline pipeline is not the shipped extension, and the offline pipeline is not released. That is a normal state of affairs for a preprint artefact and it is not evidence against the paper's conclusions — the window-variable insight in particular is unaffected. It does mean you cannot reuse SST-Guard as a black box and report its accuracy as yours.
| Preprint claim | Against the released data |
|---|---|
| sGA on 6,314 domains | Confirmed. sst-domains.txt has exactly 6,314 lines, all distinct, and adblock-filtered.csv has exactly 6,314 distinct domain values |
| 403 ground-truth sGA domains, 4.02% of Tranco top-10k | Confirmed (403 distinct non-empty domains; 403/10,000 is 4.03%, not 4.02%) |
| 40,199 sGA requests | 40,198. The file has 40,199 lines including its header |
/g/collect on 71.94% of sGA endpoints, */collect on 79.97% | Close, not exact: 72.71% and 82.23% of the 6,314 domains |
| 81.59% subdomain-based / 18.4% path-based | Not reproducible, because the rule is not stated. Three defensible readings of the released columns give 53.67%, 85.92% and 95.91% |
| “21.05% [of subdomain deployments] use CNAME cloaking” (abstract) | Inconsistent with the body, which says 1,365 of 5,152 subdomain deployments, 26.49%. 21.05% is 1,329 divided by all 6,314 detected domains, not by the subdomain ones |
README names ground-truth-labels.csv | No such file; the repository ships sst-guard-output.csv |
For completeness, the peer-reviewed paper has an internal inconsistency of its own: Fouad et al.'s Table 1 gives 389 websites carrying a cloaked tracker, and §5.3 says “these trackers appear on 397 websites (5.28% of the visited websites)” — but 5.28% of 7,367 is 389, and the abstract says 389. Use 389.
This is the part that matters even if SST is not your topic.
ep.fb_event_name and ep.event_id, i.e. Meta's Conversions API riding in the same container._ga cookie set by analytics.example.com looks like a first-party analytics cookie and will be classified as one. Fouad et al. looked their SST cookies up in Cookiepedia and 35% came back as Targeting/Advertising. Worse, they found 119 cloaked trackers receiving ID cookies set by 91 distinct other third-party domains — a Same-Origin Policy bypass, because a first-party subdomain can read cookies its operator never set.analytics.bmj.com syncing with doubleclick.net to defeat exactly that. Whether SST is a privacy gain depends on the threat model, and a paper that asserts one direction without checking for syncing has skipped a step.page_view-only crawl measures the floor.window. Enumerate and JSON.stringify the window properties after load. This is the one signal that survives request and cookie obfuscation, and virtually no standard crawler does it — see the crawler comparison.googletagmanager.com for 31.5% of sites — meaning a third of deployments still load their tag from a blockable third-party domain even though the reporting moved. Note their own caveat that CDP returns no stack for a substantial share of requests.gcd, dma_cps in the payloads are Google's consent and DMA parameters), so an EU vantage and a US vantage are different experiments — see Crawling location.Two independent passes over the publication corpus — 7 venues (CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf, IEEE S&P), 2010–2026. Every figure below names its own population; the script and its unedited output are on the provenance page.
Pass A — the structured extraction. Of the 5,859 papers with an extraction record, two name server-side tracking in their title, and both are PETS 2024: [1Fouad, Imane; Santos, Cristiana; Laperdrix, Pierre (2024): "The Devil is in the Details: Detection, Measurement and Lawfulness of Server-Side Tracking on the Web", Proceedings on Privacy Enhancing Technologies 2024(4):450-465. (DOI)] and [3El fraihi, Asmaa; Amieur, Nardjes; Rudametkin, Walter; Goga, Oana (2024): "Client-side and Server-side Tracking on Meta: Effectiveness and Accuracy", Proceedings on Privacy Enhancing Technologies 2024(3):431-445. (DOI)]. The extraction schema has no field for SST, and a deliberately wide keyword sweep of detection[] tuples for “cname” or “server-side” returns 63 papers, of which only 7 concern web tracking at all — the other 56 are unrelated server-side security work (server-side malware, phishing cloaking, TCP injection, CDN CNAME chains) and are printed in full on the provenance page. The dataset cannot answer this page's question on its own; the full text had to be probed.
Pass B — full-text probe. Denominator: 5,869 papers with a readable paper.cols.txt. End-of-line hyphenation was joined and whitespace collapsed before matching, because server-\nside tracking otherwise silently fails.
| Probe | Papers | Share of 5,869 |
|---|---|---|
server-side tracking or server-side tagging | 11 | 0.2% |
Google's product names (sGTM, sGA, server-side Tag Manager/Analytics) | 2 | 0.0% |
Conversions API / CAPI / Events API | 16 | 0.3% |
| any description of moving collection to the server side | 18 | 0.3% |
CNAME cloaking / tracking / redirection | 46 | 0.8% |
CNAME anywhere at all | 151 | 2.6% |
Measurement Protocol | 7 | 0.1% |
This is one of the quietest topics on this site. Eleven papers in sixteen years of seven venues use the term, and only one of the eleven detects SST in the wild. By contrast the neighbouring technique, CNAME cloaking, has 46 — and the 105 papers that say CNAME without saying anything about cloaking are printed in full on the provenance page rather than silently dropped, because most of them are DNS, CDN and TLS work with no bearing on tracking.
And the trend is not “growing interest”. Papers matching the term, the products or the APIs, by year:
| Year | Papers | Of scanned | Year | Papers | Of scanned | |
|---|---|---|---|---|---|---|
| 2019 | 1 | 402 | 2023 | 4 | 720 | |
| 2020 | 1 | 402 | 2024 | 3 | 701 | |
| 2021 | 2 | 380 | 2025 | 4 | 770 | |
| 2022 | 3 | 546 | 2026 (provisional) | 4 | 415 |
2010–2018 contributes three hits in total and all three are false positives: a 2010 paper describing an extension that warns about “server-side tracking using web bugs” — the phrase, but not the architecture, which did not exist until 2020 — and two matches on CAPI meaning Microsoft's CryptoAPI and a hyphenated “social capi-talists”. 2026 is provisional and must not be read as a complete year — CCS 2026 and IMC 2026 have not been held and two other venue-years are incompletely selected.
What the 2025–2026 papers actually do with SST is cite it as the reason their own method fails. None measures it. The clearest instance is CookieGuard [11Nikkhah 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), whose own conclusion reads: “Emerging practices like server-side tracking bypass client-side defenses, including our own CookieGuard […], by proxying exfiltration through seemingly first-party endpoints […].” (the elisions are a section cross-reference and three citation markers) Others — the gclid study at PETS 2026, the WebView study [12Weerasekara, Nipuna; Moreno, José Miguel; Matic, Srdjan; Reardon, Joel; Tapiador, Juan; Vallina-Rodríguez, Narseo (2025): "Tracking Without Borders: Studying the Role of WebViews in Bridging Mobile and Web Tracking", Proceedings on Privacy Enhancing Technologies 2025(4). (DOI)] at PETS 2025, PiiXel at CCS 2025, the localhost web-to-app study at USENIX Security 2026 — cite [3El fraihi, Asmaa; Amieur, Nardjes; Rudametkin, Walter; Goga, Oana (2024): "Client-side and Server-side Tracking on Meta: Effectiveness and Accuracy", Proceedings on Privacy Enhancing Technologies 2024(3):431-445. (DOI)] for the proposition that Meta's CAPI bypasses browser defences and move on. If you are planning an SST measurement, that is your gap: the field has agreed SST defeats client-side defences and has published almost nothing measuring it.
Legal assessment. Of the 402 corpus papers that assess compliance with a law, [1Fouad, Imane; Santos, Cristiana; Laperdrix, Pierre (2024): "The Devil is in the Details: Detection, Measurement and Lawfulness of Server-Side Tracking on the Web", Proceedings on Privacy Enhancing Technologies 2024(4):450-465. (DOI)] is the only one that assesses SST, against both the GDPR and the ePrivacy Directive, finding violations of each.
* Nobody has isolated the effect of interaction depth on measured SST prevalence. It is the largest apparent driver of the 0.38%–38% spread and it is a clean, cheap experiment: one population, one vantage, four interaction depths. This page would most like this done. * As of today, no peer-reviewed SST detector exists that can be run. The one refereed method needs a 2020 baseline crawl; of the three runnable methods, one is peer-reviewed but at a workshop outside these venues [6Moti, Zahra; Frings, Kimberley; Utz, Christine; Zuiderveen Borgesius, Frederik; Acar, Gunes (2025): "The Bitter Pill: Tracking and Remarketing on EU Pharmacy Websites", in: Data Privacy Management, Cryptology and Information Security. (Link)], one is a preprint [4Jazlan, Muhammad; Gamero-Garrido, Alexander; Shafiq, Zubair; Vekaria, Yash (2026): "SST-Guard: Detecting and Characterizing Server-Side Google Analytics in the Wild". Preprint, arXiv v1 of 30 April 2026; also presented as a poster at PETS 2026, which states that posters "will not be peer-reviewed". Not peer-reviewed as of 21 August 2026 (DOI)], and one is accepted at CCS 2026 [2Mertens, Gilles; Bielova, Nataliia; Roca, Vincent; Bouhoula, Ahmed; Akassab, Marouane (2026): "Detecting and Measuring Client- and Server-Side Google Tag Manager and its Tags in 80K Websites", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. Accepted at CCS 2026 (verified on the SIGSAC accepted-papers list, 21 August 2026); to appear. Preprint at HAL hal-05466083v2, submitted 6 February 2026, under the title "An Analysis of Client- and Server-Side Google Tag Manager and its Tags on the Web" (Link)] but not yet presented or published. That last one closes this gap when CCS 2026 is held — check before repeating this sentence. * Nothing detects SST for any platform other than Google. SST-Guard says so explicitly and names the reason: Meta, TikTok, Snapchat and Reddit ship no debugging tool equivalent to Google Tag Assistant, so there is no ground-truth source to bootstrap from. Meta CAPI is the obvious next target — [3El fraihi, Asmaa; Amieur, Nardjes; Rudametkin, Walter; Goga, Oana (2024): "Client-side and Server-side Tracking on Meta: Effectiveness and Accuracy", Proceedings on Privacy Enhancing Technologies 2024(3):431-445. (DOI)] shows it works — and it is undetected in the wild. * Path-based and same-origin deployments are unmeasured by anyone. They are ~18% of detections today, they are invisible to every DNS-based method, and Google's documentation now recommends them first. Any method that finds them is new. * Measurement-Protocol deployments leave no client-side artefact at all and are excluded from the scope of every study above. Whether they are a rounding error or the real story is unknown. * SST-Guard's own suggestion — taint tracking from DOM event to network request — is unattempted for SST. The taint-tracking browsers exist (see JavaScript); nobody has pointed one at this. * Work in flight that is not yet readable. The same group behind SST-Guard also showed a PETS 2026 poster, “Reverse Engineering Google Tag Manager Configurations in the Wild” (Nabeel, Jazlan and Shafiq), which is the obvious complement to detection — what the container is configured to do — and for which no paper exists yet. Search for it before you start that project. * Longitudinal growth is unmeasured. Fouad et al. named it as future work in 2024 and it has not been done. There is no published SST time series, so “SST is growing” is currently an assertion. * Venue coverage is itself a limitation here. A reading list built from this corpus alone would contain one paper: of the four studies in the main table, one is a preprint, one is a DPM workshop paper outside these venues, and one is accepted at CCS 2026 but not yet held. The state of a literature and the state of a corpus of it are not the same thing.
server-side tracking) returns 11 papers; adding product names and API names returns 26; the widest phrasing probe adds 18 more. All widths are printed above and on the provenance page precisely so the choice is visible. No claim on this page rests on a probe alone: the eleven narrow hits were read individually..cols repair interleaves the columns mid-sentence — which is a property of the corpus, not of the papers.window-level instrumentation live.window state, request initiators and DNS.petsymposium.org/2026/cfposters.php and …/accepted-posters.php, both fetched 2026-08-21.github.com/AdguardTeam/cname-trackers — checked 2026-08-21 via the GitHub API: not archived, last push 2026-08-17, so actively maintained.developers.google.com/tag-platform/tag-manager/server-side/custom-domain, read 2026-08-21, page's own “Last updated 2025-06-27”: “Same-origin serving is a best practice that lets you leverage the security and durability benefits of server-set cookies” and “To unlock the benefits of a first-party context, such as more durable cookies, your tagging server and your website have to run on the same domain.” The setup guide adds: “Make sure to host your tagging server in the same origin (best practice) or as a subdomain of your current website” (…/manual-setup-guide, “Last updated 2026-05-08”). These pages render client-side, so curl returns a shell; the quotes were read from the rendered page and only the HTTP 200 is checked by the provenance script.privacysandbox.google.com/blog/privacy-sandbox-next-steps, 2025-04-22: “we've made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies.” Checked 2026-08-21.github.com/jazlan01/sst-guard, cloned 2026-08-21 at commit 9e013d4 of 2026-04-29 — the only commit.