| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| privacy:server_side_tracking [2026/08/21 06:55] – Generic-review fixes: qualify the 'no peer-reviewed detector' and 'only peer-reviewed runnable' claims (Moti et al. is peer-reviewed, at a workshop); correct the probe-union arithmetic to 25/41 and print it from the script; drop the unsupported 'adoption karel.kubicek.claude | privacy:server_side_tracking [2026/08/21 14:48] (current) – [Open Questions] karelkubicek |
|---|
| | 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 | {[fouad2024_devil]} | **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 | | | 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 | {[fouad2024_devil]} | **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 | {[moti2025_bitterpill]} | **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% | | | 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 | {[moti2025_bitterpill]} | **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 | {[mertens2026_gtm]} | **Current, and about to become the only runnable method published at a main venue** — it is accepted at CCS 2026 (Moti et al.'s is peer-reviewed too, but at a workshop). 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 | **Vendor template signatures**: enumerate the sGTM template marketplace and fingerprint each template's client-side artefacts | {[mertens2026_gtm]} | **Current, and about to become the only runnable method published at a main venue** — it is accepted at CCS 2026 (Moti et al.'s is peer-reviewed too, but at a workshop). 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 — and within sGTM, only the **94 of 202** server-side Tags that have permission to store a cookie, which is why it detects a Tag on just 10.5% of the containers it finds. Its compensating strength is that it names the //vendor//: it is the only method that reports non-Google platforms (Meta, Snapchat, TikTok, Microsoft, LINE) separately. 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 | {[jazlan2026_sstguard]} | **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 //extension// does not reproduce its released //feature data//, and two of its headline splits cannot be re-derived from the release at all** — see the next section before you build on it | | | 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 | {[jazlan2026_sstguard]} | **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 //extension// does not reproduce its released //feature data//, and two of its headline splits cannot be re-derived from the release at all** — 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 | | | — | **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 | |
| * **Assuming SST lives on a distinct subdomain.** **18.4%** of SST-Guard's detections route through a path on the main domain (''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. That 18.4% is the paper's own figure and **is not re-derivable from its release**: three defensible readings of the released columns put path-based deployments anywhere from 4% to 46% (see the audit below). Treat it as an order of magnitude, not a planning constant. And this is the direction of travel: **Google's current documentation recommends same-origin serving first**, ahead of the subdomain option.((''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.)) Design for path-based deployments now, not later. | * **Assuming SST lives on a distinct subdomain.** **18.4%** of SST-Guard's detections route through a path on the main domain (''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. That 18.4% is the paper's own figure and **is not re-derivable from its release**: three defensible readings of the released columns put path-based deployments anywhere from 4% to 46% (see the audit below). Treat it as an order of magnitude, not a planning constant. And this is the direction of travel: **Google's current documentation recommends same-origin serving first**, ahead of the subdomain option.((''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.)) Design for path-based deployments now, not later. |
| * **"Third-party cookies are going away, so SST is about to matter."** They are not. Google announced on **2025-04-22** that it would keep third-party cookie choice in Chrome and would not ship the planned prompt.((Anthony Chavez, VP Privacy Sandbox, "Privacy Sandbox: Next steps", ''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.)) Fouad et al. wrote in 2024 that "the end of third-party cookies planned for 2025 is having severe ramifications", and that premise is now false. SST did not go away with it — **later studies, under broader definitions, find far more of it than the 2024 one did** — but see [[#Open Questions]]: there is no time series, so nobody can say it //grew//. Filter-list evasion and signal loss to browser defences, not the cookie deprecation, are the live motivation. Do not reproduce the 2024 framing. | * **"Third-party cookies are going away, so SST is about to matter."** They are not. Google announced on **2025-04-22** that it would keep third-party cookie choice in Chrome and would not ship the planned prompt.((Anthony Chavez, VP Privacy Sandbox, "Privacy Sandbox: Next steps", ''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.)) Fouad et al. wrote in 2024 that "the end of third-party cookies planned for 2025 is having severe ramifications", and that premise is now false. SST did not go away with it — **later studies, under broader definitions, find far more of it than the 2024 one did** — but see [[#Open Questions]]: there is no time series, so nobody can say it //grew//. Filter-list evasion and signal loss to browser defences, not the cookie deprecation, are the live motivation. Do not reproduce the 2024 framing. |
| * **"Filter lists cannot see SST."** Too strong as of today. EasyPrivacy has evolved specific rules for it, and SST-Guard measures them blocking **93.50%** of the 40,199 sGA requests it reports finding (40,198 in the released file — see the audit). Verified live on 2026-08-21 (EasyPrivacy ''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. | * **"Filter lists cannot see SST."** Too strong as of today. EasyPrivacy has evolved specific rules for it, and SST-Guard measures them blocking **93.50%** of the 40,199 sGA requests it reports finding (40,198 in the released file — see the audit). Verified live on 2026-08-21 (EasyPrivacy ''Version: 202608210644'', commit ''94b83d3b'' — the version the provenance page's committed script output shows; it had already moved three times in the half hour before this sentence was written, which is the point): 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. |
| |
| ===== Auditing SST-Guard against its own released artefacts ===== | ===== Auditing SST-Guard against its own released artefacts ===== |
| |
| The SST-Guard repository((''github.com/jazlan01/sst-guard'', cloned 2026-08-21 at commit ''9e013d4'' of 2026-04-30 (UTC) — the only commit.)) 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 SST-Guard repository((''github.com/jazlan01/sst-guard'', at commit ''18a312c'' of 2026-08-21. **This section was first written against ''9e013d4'' (2026-04-30, then the only commit), and re-run against ''18a312c''.** In between, the author read this page and pushed two fixes — ''32fedb3'' "Bug fix for static browser fingerprint" and ''18a312c'' "Fixed regex patterns that mismatched from the training process" — which repair most, not all, of what is described below. Both revisions are audited here so a reader with an older checkout can tell which they have; only ''dist_chrome.zip'' changed.)) 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. Three scripts do this and their unedited output is on [[provenance:privacy:server_side_tracking|the provenance page]]. **This is a source audit, not a reproduction attempt**: no crawl was re-run. | 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. Three scripts do this and their unedited output is on [[provenance:privacy:server_side_tracking|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? ^ | ^ 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 | | | **''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 | | | **''_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. **Still true in ''18a312c''** — the ''17'' prefix is in ''pattern_1'', ''pattern_2'', ''pattern_5'', ''gaGlobal[vid]'' and ''cid'', and the 2026-08-21 fixes did not touch it. This is the one item in this table that a reader inheriting the code still has to fix | |
| | **''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 | | | **''window'' ''chrome_version'', ''platform_version'', ''architecture'', ''bitness'', and network ''uap'', ''uapv'', ''uaa'', ''uab''** | **Yes as of ''18a312c'' — no in ''9e013d4''.** In the first release these were literals pinning two //different// machines: ''%%/"144\.0\.7559\.97"/%%'', ''%%/"26\.2\.0"/%%'', ''%%/"arm"/%%'', ''%%/"64"/%%'' (an Apple-Silicon Mac) against ''/Linux/'', ''/5\.15\.0/'', ''/x86/'' (the paper's Ubuntu 22.04 crawl host), so the extension carried two mutually inconsistent environment fingerprints and neither was yours. ''18a312c'' templates them: ''chrome_version'', ''platform_version'' and ''uapv'' start as ''%%/(?!)/%%'' and are rewritten at startup from ''navigator.userAgentData.getHighEntropyValues(["uaFullVersion","platformVersion"])'', with the value regex-escaped; ''uaa''/''architecture'' widens to accept ''x86'' as well as ''arm'', ''uab''/''bitness'' to accept ''32'' as well as ''64'', and ''uap'' to the seven platform strings Chrome reports. **One residue to know about:** the runtime rewrite is wrapped in a bare ''catch {}'', so on any engine without UA Client Hints those three features stay ''%%/(?!)/%%'' and read as a confident zero rather than as missing — which is what happens if you reuse the extractor outside Chromium | |
| | **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)** | **Yes as of ''18a312c'' — no in ''9e013d4''.** The first release shipped ''%%/https:\/\/[\^\s&#]+/%%'', a character class containing an //escaped literal caret// rather than a negation, so it matched ''https://'' followed only by ''%%^%%'', whitespace, ''&'' or ''#'' — no ordinary URL at all, against 98.4% of the authors' own published rows. ''18a312c'' corrects it to ''%%/https:\/\/[^\s&#]+/%%'' and it now agrees with the published column on **100.0%** of those rows | |
| | **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''** | **Yes as of ''18a312c'' — no in ''9e013d4''.** 99.5% in the published data against 0.0% under the first release's regex; ''18a312c'' replaces it with an explicit brand-array alternation and reaches 100.0% agreement | |
| | **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 ''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 | | | **Network ''gcs'', ''tcfd'', ''ep.user_agent''** | **No — these three carry no information in either release.** All three columns are constant zero across all 40,198 published rows. In ''9e013d4'' the shipped regexes disagreed with that, firing on 73.3%, 11.0% and 2.9% of the same URLs; ''18a312c'' brings the extension into agreement, but by making the regexes inert — each is now wrapped in literal single quotes (''%%/'G[0-3\-]{3}'/%%'') that no query-parameter value contains. Extension and published data now agree at 100% because both are dead. If you want a consent-mode signal, write your own ''gcs'' pattern | |
| |
| ==== Replaying the shipped extractor over the published rows ==== | ==== Replaying the shipped extractor over the published rows ==== |
| |
| 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 **15** of the 23 features — 14 of them exactly, the fifteenth (''uapv'') at 99.9975%, which the report rounds to 100.0%. The residue is the rows above — ''dl'' and ''uafvl'' (shipped regex dead), ''gcs'' / ''tcfd'' / ''ep.user_agent'' (published column dead), ''gtm'' at 91.5% — plus two near-misses, ''_eu'' at 99.8% and ''_gid'' at 98.9%. | 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 **87.5%** per-cell agreement at ''18a312c'', up from **79.3%** at ''9e013d4''. A variant that tests each template against //every// parameter value gives **95.4%** (was 83.1%) and reaches **exactly 100%** for **19** of the 23 features (was 15, one of which only rounded to 100.0%). The whole remaining residue is the environment features: ''uapv'' at 4.2%, ''uab'' at 95.2%, ''uaa'' and ''uap'' at 97.2% — all of which now depend on the machine the extractor runs on, and ''uapv'' reads 4.2% here precisely because this replay ran under Node, where ''navigator.userAgentData'' does not exist and the ''%%/(?!)/%%'' placeholder survives. |
| |
| **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. | **Read that as: the offline pipeline is still not the shipped extension, and the offline pipeline is still not released** — 95.4% is not 100%, and the four features that miss are the ones a second machine cannot reproduce by construction. 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. |
| |
| ==== Figures that do and do not check out against the release ==== | ==== Figures that do and do not check out against the release ==== |
| - **Whether you counted path-based deployments**, and if not, that your figure excludes roughly a fifth of them //by the only published count//, which is itself not reproducible. | - **Whether you counted path-based deployments**, and if not, that your figure excludes roughly a fifth of them //by the only published count//, which is itself not reproducible. |
| - **Whether you required a CNAME.** If yes, your figure is roughly a quarter of the DNS-visible deployments. | - **Whether you required a CNAME.** If yes, your figure is roughly a quarter of the DNS-visible deployments. |
| - **Which tracking platform.** "SST" measured through Google Analytics artefacts is not "SST". Meta CAPI, TikTok Events API and any Measurement-Protocol deployment leave different artefacts or none. | - **Which tracking platform.** "SST" measured through Google Analytics artefacts is not "SST". Meta CAPI, TikTok Events API and any Measurement-Protocol deployment leave different artefacts or none. Non-Google platforms are visible when they ride in a GTM container, and only then — see the Open Questions. |
| - **Your filter-list baseline with its version and commit**, so the "what lists miss" claim is checkable. EasyPrivacy changes several times a day. | - **Your filter-list baseline with its version and commit**, so the "what lists miss" claim is checkable. EasyPrivacy changes several times a day. |
| - **Ground truth, and where it came from.** SST-Guard used Google Tag Assistant and deliberately kept it out of training so the system survives its deprecation. If you have no ground truth, say the word "lower bound" and mean it. | - **Ground truth, and where it came from.** SST-Guard used Google Tag Assistant and deliberately kept it out of training so the system survives its deprecation. If you have no ground truth, say the word "lower bound" and mean it. |
| ===== 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. |
| * **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 — {[elfraihi2024_meta]} shows it works — and it is undetected in the wild. | * **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. |
| | * **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 ===== |
