| 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 08:28] (current) – [Open Questions] karelkubicek |
|---|
| * **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 ===== |
| ===== 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. |
| * **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 ===== |
