Differences

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

--- privacy:server_side_tracking [2026/08/21 14:34] – [Open Questions] karelkubicek
+++ privacy:server_side_tracking [2026/08/21 14:48] (current) – [Open Questions] karelkubicek
@@ Line 164: / Line 164: @@
   * **No SST detector published at a main security or measurement venue can be run today.** The one that was — Fouad et al. at PETS 2024 — needs a 2020 baseline crawl. Of the three runnable methods, one //is// peer-reviewed but at a workshop outside these seven venues {[moti2025_bitterpill]}, one is a preprint {[jazlan2026_sstguard]}, and one is accepted at CCS 2026 {[mertens2026_gtm]} but not yet presented. **That last one closes this gap when CCS 2026 is held** — check before repeating this sentence. An earlier draft of it read "no peer-reviewed SST detector exists that can be run", which was simply wrong about Moti et al.
   * **Non-Google SST is detected but not //verifiable//.** This is the correction that matters most on this page, and it came from SST-Guard's author (Jazlan, 2026-08-21), who notes he is not a disinterested reader: an earlier draft said "nothing detects SST for any platform other than Google", which is wrong. Both current methods surface non-Google platforms when those platforms are deployed //through a GTM container//. Mertens et al.'s Table 7 reports Meta Conversions API on **161** websites (from the ''_gtmeec'' and ''_fbp'' cookies), Snapchat on **15** (''_scid''), TikTok Events API on **9** (''_ttp''), Microsoft and LINE on 1–2 each — Meta is the //largest// single server-side Tag group they find, larger than any Google Tag. SST-Guard reaches the same platforms from the payload side: requests to sGA endpoints carry ''ep.fb_event_name'' and ''ep.event_id'', which the paper reads as proof "that other server-side trackers are being implemented alongside sGA, most likely with sGTM". What is missing is not detection but **ground truth and attribution**, and in three distinct senses: (i) no vendor except Google ships a debugging tool equivalent to Tag Assistant, so there is nothing to train or validate against — this is the limitation SST-Guard states, and it is a limitation about //verifiability//, not about visibility; (ii) the signal does not identify the Tag — Mertens et al. cannot tell which of five different Meta CAPI templates set those cookies, and say so; (iii) nothing here confirms that data actually reached Meta. And all of it is confined to GTM: a CAPI deployment that does not go through a container, or that remaps event names server-side, leaves nothing. **Both of the useful open problems are downstream of that**: bootstrap a non-Google ground truth without a vendor debugger, and detect a non-GTM CAPI deployment at all.
-  * **The one heuristic Mertens et al. make available for Meta is very weak, and its author says so.** Because a server-side CAPI Tag sets ''_fbp'' and ''_gtmeec'' from the container, you can look for ''_fbp'' present as a first-party cookie //while// no client-side Meta Pixel template is detected on the page, and treat that as a CAPI candidate. Jazlan's own assessment: "It is a super super super weak heuristic". Take that at face value — ''_fbp'' is a first-party cookie in the ordinary client-side pixel deployment too, so the whole discriminating power sits in the //absence// of the client-side template, which is exactly the thing an obfuscated container is designed to hide (Mertens et al. find 6.7% of GTM sites obfuscating). If you use it, use it to build a candidate list for manual confirmation, never as a prevalence estimate.
+  * **A cheap Meta heuristic that Mertens et al.'s result makes available — nobody proposes it, and a competitor rates it very weak.** Because a server-side CAPI Tag sets ''_fbp'' and ''_gtmeec'' from the container, you can look for ''_fbp'' present as a first-party cookie //while// no client-side Meta Pixel template is detected on the page, and treat that as a CAPI candidate. **Read the provenance of that assessment before you weigh it.** Mertens et al. do not propose this heuristic and do not evaluate it; the wording here is the construction Jazlan (SST-Guard) offered when reviewing this page, together with his verdict on it — "It is a super super super weak heuristic" — and SST-Guard is a directly competing detector, so this is one method's author rating what a rival's result enables, not a self-assessment by the people who published it. Nobody on Mertens et al. was asked. The technical objection stands on its own regardless of who raised it: ''_fbp'' is a first-party cookie in the ordinary client-side pixel deployment too, so all the discriminating power sits in the //absence// of the client-side template — exactly what an obfuscated container is built to hide, and Mertens et al. find **6.7%** of GTM sites obfuscating. Use it to build a candidate list for manual confirmation, never as a prevalence estimate.
   * **Path-based and same-origin deployments are unmeasured by anyone.** They are ~18% of detections by the one published count, and between 4% and 46% depending on how you read its release, 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.