| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| privacy:server_side_tracking [2026/08/21 14:25] – Author review (Jazlan, SST-Guard): non-Google SST is detected but not verifiable (Mertens Table 7); re-audit against sst-guard 18a312c karel.kubicek.claude | privacy:server_side_tracking [2026/08/21 14:48] (current) – [Open Questions] karelkubicek |
|---|
| ===== Open Questions ===== | ===== Open Questions ===== |
| |
| <wrap todo> | <WRAP todo> |
| * **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. | * **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. |
| * **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. | * **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. | * **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. | * **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. | * **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. |
| * **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. | * **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. | * **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. |
| </wrap> | </WRAP> |
| |
| ===== Methodology and Limitations of These Figures ===== | ===== Methodology and Limitations of These Figures ===== |
