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 Devil is in the Details [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 — the first and still the only peer-reviewed measurement of SST in the wild, plus a legal analysis with a co-author who is a legal scholar. Read it for the detection logic and for the auditing argument, not for the prevalence figure.
• Client-side and Server-side Tracking on Meta [2El 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)], PETS 2024 — the complementary experiment: rather than detecting SST from the outside, the authors deployed the Meta Pixel and the Conversions API themselves and drove 2,400 recruited users through them. It is the only study that can say how well SST actually works, and the answer is “well enough, and less accurately”: CAPI matched 34%–51% of visitors to Meta profiles against the Pixel's 42%–61%, but fewer than 65% of CAPI's matches were the right person against the Pixel's 100%.
• SST-Guard [3Jazlan, 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)] — an arXiv preprint of 30 April 2026, not peer-reviewed (checked 2026-08-21: v1 only, no journal_ref). 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.
• SoK: Advances and Open Problems in Web Tracking [4Vekaria, Yash; Beugin, Yohan; Munir, Shaoor; Acar, Gunes; Bielova, Nataliia; Englehardt, Steven; Iqbal, Umar; Kapravelos, Alexandros; Laperdrix, Pierre; Nikiforakis, Nick; Polakis, Jason; Roesner, Franziska; Shafiq, Zubair; Zimmeck, Sebastian (2025): "SoK: Advances and Open Problems in Web Tracking". arXiv preprint arXiv:2506.14057. (Link)] for where SST sits in the wider tracking literature, and The Bitter Pill [5Moti, 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)] (DPM 2025) for what SST looks like in one high-monetisation vertical measured by hand.

Every row is a different question. Read the Definition detected column before the Result column.

Three things follow, and they are the reusable part of this table.

• The ordering of the results is the ordering of the interaction depth. Landing page, no clicks → 0.38%. Scroll and click and one subpage → 4.9%. A human shopping for a product → 38%. SST reports events; if your crawler generates no events past 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.
• Fouad et al. and SST-Guard are not measuring the same object. Fouad requires evidence that trackers moved — a shift visible only against a pre-2020 baseline — and so reports a deliberate, conservative lower bound: “we only detect a subset of the servers partaking in SST”. SST-Guard requires only that a Google Analytics artefact reaches a non-Google endpoint. 0.38% and 4.9% are consistent with each other.
• Denominator discipline. SST-Guard's own headline, 4.21%, divides by the 150,000-name list rather than by the 128,222 domains it actually classified. Over the crawled population the figure is 4.92%. Use the population you measured.

• Matching the third-party hostname, with or without a filter list, as a definition of tracking. This is the whole point of SST. Under SST the tracking request is first-party.
• Requiring a CNAME record. 73.51% of subdomain-based sGA uses A/AAAA [3Jazlan, 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)]. A CNAME-only detector reports roughly a quarter of the deployments and reports it as the total.
• 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. And this is the direction of travel: Google's current documentation recommends same-origin serving first, ahead of the subdomain option.²⁾ 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.³⁾ 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 — while SST adoption grew anyway. 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 found. 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.

The SST-Guard repository⁴⁾ 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.

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.

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.

• Request classification loses its most reliable label source. The current best practice for deciding what a cookie or a request is for is the provenance of the thing that created it — a cookie set by a resource a filter list blocked as advertising is an advertising cookie. Under SST there is no blocked advertising resource: there is one first-party endpoint that received data destined for an unknown number of platforms. SST-Guard's payload analysis makes this concrete — requests to sGA endpoints carry ep.fb_event_name and ep.event_id, i.e. Meta's Conversions API riding in the same container.
• Cookie classification mislabels by construction. A _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.
• Consent measurement gets an artefact you must declare. The two main studies sit at opposite extremes and it changes what their numbers mean. Fouad et al. “did not interact with cookie banners on the visited [websites]”, so every flow they report is pre-consent — which is what makes their legal analysis possible. SST-Guard drove Consent-O-Matic to accept everything, which maximises what fires and says nothing about lawfulness. Neither is wrong; reporting a prevalence without saying which one you did is.
• Legal and compliance work loses its evidence. Fouad et al., with a legal scholar, argue SST infringes both the GDPR and the ePrivacy Directive, and the operative reason is evidentiary rather than doctrinal: an auditor cannot see which third parties received the data, cannot attribute a purpose to a cookie whose setter is hidden, and a first-party cookie set by a first-party subdomain invites the (wrong) inference that it is strictly necessary and consent-exempt. See Legal enforcement for who to report to.
• The privacy effect is not uniformly negative, and saying so is not a defence of SST. Fouad et al. note that first-party SST cookies are confined to one site unless they are synced or fingerprint-augmented, so pushing collection into a first-party context can impede cross-site tracking: “paradoxically, this complexity can enhance privacy”. They then show 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.

1. Interact. This is the biggest lever (see the table above). At minimum: scroll to the bottom with pauses, click something inert, and visit one same-site subpage. A page_view-only crawl measures the floor.
2. Record request bodies, not just URLs. Google's transport can POST. A URL-only HAR loses the payload.
3. Snapshot 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.
4. Record DNS, not just HTTP. A/AAAA and CNAME for every first-party subdomain, then ASN and WHOIS organisation. Every method in the table needs this and most crawler stacks do not produce it; HAR files certainly do not.
5. Record the request initiator. SST-Guard used the Chrome DevTools Protocol, and found the initiator to be 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.
6. Decide statefulness deliberately. Fouad et al. crawled stateless and flagged the known consequence: stateless crawls see more third-party tracker requests than stateful ones [10Zeber, David; Bird, Sarah; Oliveira, Camila; Rudametkin, Walter; Segall, Ilana; Wolls´en, Fredrik; Lopatka, Martin (2020): "The Representativeness of Automated Web Crawls as a Surrogate for Human Browsing", in: Proceedings of The Web Conference 2020, pp. 167–178. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)]. See stateful vs stateless crawling.
7. Budget for being blocked. SST-Guard's false negatives were mostly its consent tool failing on a banner, or the crawl being detected as a bot. Report your success rate.
8. Say where you crawled from. SST behaviour is consent-signal dependent (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.

1. Your definition of SST, operationally. “A first-party endpoint receiving GA-shaped values” and “a subdomain that inherited parameters from a vanished tracker” are different studies. State the predicate.
2. Your population and your denominator. The list, its version, how many names you attempted and how many you successfully classified. Not the list length.
3. Interaction depth, consent action, statefulness, vantage. Without all four the prevalence is uninterpretable. These are the four fields that the corpus shows most often go unreported for crawls in general (see Corpus).
4. Whether you counted path-based deployments, and if not, that your figure excludes roughly a fifth of them.
5. Whether you required a CNAME. If yes, your figure is roughly a quarter of the DNS-visible deployments.
6. 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.
7. Your filter-list baseline with its version and commit, so the “what lists miss” claim is checkable. EasyPrivacy changes several times a day.
8. 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.

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 [2El 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.

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:

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.” 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 [2El 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. * No peer-reviewed SST detector exists that can be run today. The one refereed method needs a 2020 baseline crawl; the two runnable methods are preprints. Getting either through review would change what everyone else can cite. * 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 — [2El 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. * 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. Two of the four studies in the main table are preprints and a third is a DPM workshop paper; none is in the seven venues. A reading list built from this corpus alone would contain one paper.

• Every claim about “the literature” is a claim about seven venues. EuroS&P, ACSAC, RAID, AsiaCCS, WPES, CHI and SOUPS are absent, and three of the four studies in the main table were published outside the seven. Mertens et al.'s earlier EuroS&P 2025 work [13Mertens, Gilles; Bielova, Nataliia; Roca, Vincent; Santos, Cristiana (2025): "You Can't Trust Your Tag Neither: Privacy Leaks and Potential Legal Violations within the Google Tag Manager", in: Proceedings of the IEEE European Symposium on Security and Privacy, pp. 93-112. (DOI)] is likewise invisible to every corpus count here.
• The corpus figures count papers, never tuples, and the full-text probe counts a paper once however many times it uses a term.
• Probe width decides the number. The narrow probe (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.
• All 25 figures and quotes taken from the two corpus papers were checked against the papers' own full text, in three renderings. All 25 located. Six required short fragments rather than whole sentences, because the two-column .cols repair interleaves the columns mid-sentence — which is a property of the corpus, not of the papers.
• The SST-Guard audit is a source audit. No crawl was re-run and no claim here is that the paper's measurements are wrong. What is shown is that its released artefacts do not reproduce its released numbers, and which of its signals a reader can and cannot reuse.
• 2026 is a provisional venue-year and 2025 is thin at the edges. See Corpus.
• Full query log, scripts, unedited outputs, folds and residue, rejected sources: server_side_tracking.

• Classifying web requests — the method SST is designed to defeat, and where filter lists and their measured error rates are covered.
• Cookies — first-party versus third-party, and why the distinction stops carrying information under SST.
• Analysing and classifying JavaScript — where taint tracking and the window-level instrumentation live.
• Granting consent to websites — the consent action that decides what fires.
• Comparison of crawling libraries — what records POST bodies, window state, request initiators and DNS.
• Stateful vs stateless crawling, Interaction with websites, Crawling location.
• Legal enforcement — where a GDPR/ePD finding goes next.
• Provenance of this page's figures.

[1]

Fouad, 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)

[2]

El 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)

[3]

Jazlan, 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)

[4]

Vekaria, Yash; Beugin, Yohan; Munir, Shaoor; Acar, Gunes; Bielova, Nataliia; Englehardt, Steven; Iqbal, Umar; Kapravelos, Alexandros; Laperdrix, Pierre; Nikiforakis, Nick; Polakis, Jason; Roesner, Franziska; Shafiq, Zubair; Zimmeck, Sebastian (2025): "SoK: Advances and Open Problems in Web Tracking". arXiv preprint arXiv:2506.14057. (Link)

[5]

Moti, 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)

[6]

Mertens, 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)

[7]

Dimova, 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)

[8]

Dao, 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)

[9]

Aliyeva, 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)

[10]

Zeber, David; Bird, Sarah; Oliveira, Camila; Rudametkin, Walter; Segall, Ilana; Wolls´en, Fredrik; Lopatka, Martin (2020): "The Representativeness of Automated Web Crawls as a Surrogate for Human Browsing", in: Proceedings of The Web Conference 2020, pp. 167–178. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[11]

Nikkhah 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)

[12]

Weerasekara, 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)

[13]

Mertens, Gilles; Bielova, Nataliia; Roca, Vincent; Santos, Cristiana (2025): "You Can't Trust Your Tag Neither: Privacy Leaks and Potential Legal Violations within the Google Tag Manager", in: Proceedings of the IEEE European Symposium on Security and Privacy, pp. 93-112. (DOI)