You want to know whether a website hands a visitor's personal data — a name, an email address, a phone number, a postal address, a password, a search term, a health condition, a wallet address — to a company other than the one running the site. A landing-page crawl cannot see a value leave: nothing personal is on the page until someone types it, logs in, searches or buys, and when it leaves it is often hashed, encoded, split or compressed. What a measurement can actually observe is a short list: a value you planted, found again in outgoing traffic (or in a mailbox you own); a script reading a field before anything is sent; a tag configuration that says which fields it will send; and a visit to a page whose topic is itself sensitive. Each proves a narrower thing than “the site leaks PII”, and each has its own denominator. This page is about choosing among them, running them, and reporting them so the number survives review.

“PII” here is an operational label — values that identify or describe a person — and not a conclusion under any statute. Whether a flow is unlawful is a separate argument (Legal enforcement). The page sits between neighbours that each own part of the mechanism, and points to them rather than repeating them:

• Email tracking keeps the email address as an identifier: what arrives in a mailbox, hashed-email matching inside ad platforms, alias collisions, phone-number enumeration. Leaky Forms [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)] and the contact-form study [2Starov, Oleksii; Gill, Phillipa; Nikiforakis, Nick (2016): "Are You Sure You Want to Contact Us? Quantifying the Leakage of PII via Website Contact Forms", in: Proceedings on Privacy Enhancing Technologies. (DOI)] appear on both pages — there as the way the address first escapes, here as the measurement recipe. The boundary was decided before writing: of the 20 papers this page counts, 5 are cited on Email tracking, so the email slice is not the whole of this literature and broadening that page would have been wrong (pii_leakage).
• JavaScript owns the script-analysis instrument — call stacks, taint, PageGraph — including session-replay scripts as code. This page owns what those scripts are found sending.
• Server side tracking owns flows that leave through the site's own server. A browser cannot see them; the section Who received it says what can.
• Cookie syncing and Fingerprinting own pseudonymous identifiers. A cookie ID or a fingerprint alone is not counted here.
• Interaction and Registration are load-bearing: almost every value on this page reaches the page through a form, a login or a search box that a crawler had to operate.

The papers use five different outcomes under one word. Pick yours before you build the crawler, because each needs different evidence and supports a different sentence.

The page URL is the trap between rows two and four. A full URL sent to Meta is a personal-data leak only if the URL carries something personal — a search term, an email in a query string, a condition in the path. PIIxel Leaks measures full-URL reporting separately and finds it on 11.30% of a 2,000-site health sample against 65.85% of a 2,000-site e-commerce sample [3Bekos, Paschalis; Papadopoulos, Panagiotis; Kourtellis, Nicolas; Polychronakis, Michalis (2025): "PIIxel Leaks: Passive Identification of Personally Identifiable Information Leakage through Meta Pixel", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]; whether those URLs held personal data is a further step the count does not take. Libert's 2015 crawl of search results for 1,986 diseases is still the clearest statement of why it matters: 70% of Referer strings exposed a specific condition, treatment or disease [16Libert, Timothy (2015): "Privacy Implications of Health Information Seeking on the Web", Communications of the ACM 58(3):68-77. (DOI)].

Most value-based methods start by making a user's action happen — the bait and injected-form designs below are ways around it. That is the expensive part, it is where most of the false negatives come from, and it changes what you are allowed to do (Ethics of typing synthetic PII into real sites).

• Forms. Find the field (a classifier beats label matching: Leaky Forms found 76% more email fields with the Fathom model from Firefox Relay than by looking for type=email inputs alone [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)]), type it the way a person would, blur it, and decide whether to submit. Submitting and not submitting are different treatments — the contact-form study submits, Leaky Forms never does — so their rates are not comparable. Injecting your own form (Tracker Installations attaches one to every landing page [4Kieserman, Julia B.; Andreou, Athanasios; Geeng, Chris; Lauinger, Tobias; McCoy, Damon (2025): "Tracker Installations Are Not Created Equal: Understanding Tracker Configuration of Form Data Collection", in: Proceedings on Privacy Enhancing Technologies, pp. 679-695. (DOI)]) measures what a tag would collect from a form, not whether the site has one: that paper says plainly it did not measure whether a site actually had a PII form.
• Login and account pages. Profile data only exists behind a login. Kaizer and Gupta crawled 345 sites logged in and logged out, and in the logged-in crawl (HTTP only) found 42% leaking some PII [17Kaizer, Andrew J.; Gupta, Minaxi (2016): "Characterizing Website Behaviors Across Logged-in and Not-logged-in Users", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]. Dimova et al. registered on 50 of 103 sites with a CNAME tracker and found something sensitive reaching the tracker on 13 — but 10 of those were authentication cookies; a full name leaked on 1 site, a location on 2 and an email address on 4 [18Dimova, 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)]. Account creation is its own engineering and ethics problem: Registration.
• Search. A dummy term typed into a site's own search box is the cheapest personal-content canary there is, and it leaks through the URL and the Referer by default. Jelly Beans executed a search on 472,333 sites and found the term reaching a third party on 81.3% of them [7Kats, Daniel; Silva, David Luz; Roturier, Johann (2022): "Who Knows I Like Jelly Beans? An Investigation Into Search Privacy", in: Proceedings on Privacy Enhancing Technologies. (DOI)]. Note the denominator: the abstract pairs 81.3% with the 512,701 sites that had a search box, but the body and the paper's own table compute it over the sites where the search actually ran — and the paper itself calls that count of successful searches an upper bound, because 1.57% of those sites produced no network traffic at all.
• Checkout, payment and sign-up. A checkout can be crawled up to the payment step; a receipt page needs a real purchase. Goldfeder et al. crawled 130 Bitcoin-accepting merchants up to payment — 49 leaked some PII to third parties — and bought from 20 of them for the receipt pages [19Goldfeder, Steven; Kalodner, Harry; Reisman, Dillon; Narayanan, Arvind (2018): "When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies", Proceedings on Privacy Enhancing Technologies . (DOI)]. The gig-work study signed up for 16 platforms with fictional personas and with two authors' real, verifiable identities [20Pradeep, Amogh; Gunawan, Johanna; Feal, Álvaro; Hartzog, Woodrow; Choffnes, David (2025): "Gig Work at What Cost? Exploring Privacy Risks of Gig Work Platform Participation in the U.S.", Proceedings on Privacy Enhancing Technologies . (DOI)].
• Consent. Run the banner as a treatment, not a nuisance (Consent). Leaky Forms ran accept-all, reject-all and no-action crawls and found that, on the sites where it detected a consent dialog, rejecting cut the number of sites leaking to trackers from 228 to 199 in the US (the paper's 13%) and from 202 to 201 in the EU — the paper's text says 0.05%, but its Table 6 counts work out to 0.5% [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)]. Either way, rejecting barely mattered. Of the 16 papers here with a crawl configuration, 7 say they did not interact with the banner and 7 say nothing about it.

Interaction depth decides recall more than anything downstream. Jelly Beans reports its own: it failed to interact with a detected search input on 26% of sites that had one [7Kats, Daniel; Silva, David Luz; Roturier, Johann (2022): "Who Knows I Like Jelly Beans? An Investigation Into Search Privacy", in: Proceedings on Privacy Enhancing Technologies. (DOI)]. Tracker Installations hand-checked a sample of its negatives and found it had missed Meta form-data collection on 9.6% of them, naming consent and other dialogs that blocked the page, and bot detection, among the causes [4Kieserman, Julia B.; Andreou, Athanasios; Geeng, Chris; Lauinger, Tobias; McCoy, Damon (2025): "Tracker Installations Are Not Created Equal: Understanding Tracker Configuration of Form Data Collection", in: Proceedings on Privacy Enhancing Technologies, pp. 679-695. (DOI)]. A form your crawler never reached is not a form that does not leak; report the funnel at every step — frame, reached, field found, filled, submitted, captured, matched.

A canary is only as good as the list of disguises you search for. The reading behind this page coded, for each of the 20 papers, which transformations it says it searched (the deciding sentence of each is on the provenance page):

The three-layer search comes from email-tracking work [24Englehardt, Steven; Han, Jeffrey; Narayanan, Arvind (2018): "I never signed up for this! Privacy implications of email tracking", Proceedings on Privacy Enhancing Technologies 2018(1):109-126. (DOI)], and the reason it displaced the differential is stated in Leaky Forms: Starov et al.'s method “requires more crawls and manual analysis” [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)]. It still misses things, and Leaky Forms is the honest example: three of its detections — a substitution cipher whose key was in the script, LZString compression, and a hash with a fixed salt hard-coded in a script — were found only because the canary addresses received email the detector could not explain [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)]. Your mailbox is a second detector; use it.

What gets hashed is not necessarily what the user typed. Vendor documentation describes hashing a normalised string: Meta's Pixel hashes advanced-matching values automatically with SHA-256 and accepts “lowercase unhashed” or “normalized SHA-256 hashed” email addresses ¹⁾; Google tells operators who hash enhanced-conversions data themselves to lower-case, trim, format phone numbers to E.164 and drop the dots before @gmail.com before a hex SHA-256 ²⁾; TikTok's automatic advanced matching finds form fields itself and hashes what it finds, and TikTok advises healthcare and financial-services sites to use the manual mode instead ³⁾. A detector that hashes Jane.Doe@Example.org as typed will never match sha256(“jane.doe@example.org”). None of the 20 papers is found stating that it normalised its canary before hashing it — a reading-scoped negative: a paper may have done it without saying so — and that is a cheap thing to get right in yours. The cheapest fix is a canary that is already in normalised form — lower-case, trimmed, no plus-tag, not a Gmail address — which makes the question moot; that may be why no paper mentions it, and the risk is real only for canaries that are not.

The script below builds the needle set — seed variants (as typed, trimmed and lower-cased, plus-addressing dropped, Gmail dots dropped, both; digits only and with a leading + for phone numbers — not a full E.164 normaliser, so give the number with its country code) times encodings, chained to a chosen depth — and searches every request URL, header and body of a HAR file (responses are not searched). It is a starting point for the search, not a classifier, and it is deliberately small so you can read every line.

pii_needles.py

"""Search a HAR file for a canary value and its common transformations.
 
    python3 pii_needles.py capture.har "Jane.Doe+site42@example.org" [--depth N]
 
Builds the needle set (seed variants x encodings, chained up to --depth),
then searches every request URL, header value and POST body in the HAR.
Prints each hit with the request URL and the transformation chain that matched,
then the number of distinct HAR entries (requests) that carried the value.
Searches requests only. A miss means "not found in these encodings", never
"not sent".
"""
import base64, hashlib, json, re, sys, urllib.parse
 
def seeds(v):
    """Normalisations vendors document before hashing: lower-case + trim for emails,
    digits only / E.164 for phone numbers (Meta, Google)."""
    out = {v, v.strip(), v.strip().lower()}
    digits = re.sub(r"\D", "", v)
    if "@" not in v and len(digits) >= 7:                    # looks like a phone number
        out.update({digits, "+" + digits})
    if "@" in v:
        local, dom = v.strip().lower().split("@", 1)
        base = local.split("+")[0]
        out.add(base + "@" + dom)                            # plus-addressing dropped
        if dom in ("gmail.com", "googlemail.com"):          # Google: dots removed before gmail.com
            out.update({local.replace(".", "") + "@" + dom, base.replace(".", "") + "@" + dom})
    return {s for s in out if s}
 
ENC = {
    "urlenc": lambda s: urllib.parse.quote(s, safe=""),
    "urlenc+": lambda s: urllib.parse.quote_plus(s),         # differs from urlenc on spaces
    "base64": lambda s: base64.b64encode(s.encode()).decode(),
    "base64url": lambda s: base64.urlsafe_b64encode(s.encode()).decode().rstrip("="),
    "md5": lambda s: hashlib.md5(s.encode()).hexdigest(),
    "sha1": lambda s: hashlib.sha1(s.encode()).hexdigest(),
    "sha256": lambda s: hashlib.sha256(s.encode()).hexdigest(),
    "sha512": lambda s: hashlib.sha512(s.encode()).hexdigest(),
}
 
def needles(value, depth):
    found = {s: ("plain" if s == value else "normalised") for s in seeds(value)}
    frontier = dict(found)
    for _ in range(depth):
        nxt = {}
        for s, chain in frontier.items():
            for name, f in ENC.items():
                t = f(s)
                if t not in found and t not in nxt:
                    nxt[t] = chain + ">" + name
        found.update(nxt)
        frontier = nxt
    return {n: c for n, c in found.items() if len(n) >= 8}   # short needles match noise
 
def haystacks(har):
    # Request side only. Chrome's HAR export also carries WebSocket frames under
    # the non-standard "_webSocketMessages" key; this script does not read them.
    for n, e in enumerate(har["log"]["entries"]):
        r = e["request"]
        url = r["url"]
        yield n, url, "url", url
        for h in r["headers"]:
            yield n, url, "header:" + h["name"], h["value"]
        if "postData" in r and "text" in r["postData"]:
            yield n, url, "body", r["postData"]["text"]
 
def main():
    args = sys.argv[1:]
    depth = 2
    if "--depth" in args:
        i = args.index("--depth")
        depth = int(args[i + 1])
        del args[i:i + 2]
    har_path, value = args
    har = json.load(open(har_path, encoding="utf-8"))
    ns = needles(value, depth)
    print(f"{len(ns)} needles (depth {depth})")
    hits, requests = 0, set()
    for entry, url, where, text in haystacks(har):
        for n, chain in ns.items():
            # hex digests: match either case; everything else (base64!) is case-sensitive
            hay = text.lower() if all(c in "0123456789abcdef" for c in n) else text
            # percent-encoding: also try lower-case hex escapes (%2b as well as %2B)
            alts = {n, re.sub(r"%[0-9A-F]{2}", lambda m: m.group(0).lower(), n)}
            if any(a in hay for a in alts):
                hits += 1
                requests.add(entry)
                print(f"HIT {chain:<32} {where:<22} {url[:70]}")
    print(f"{hits} match(es) in {len(requests)} distinct request(s)")
 
if __name__ == "__main__":
    main()

Run against a fixture HAR with four planted leaks — a Meta-style SHA-256 of the normalised address in a pixel URL, a Base64 address in a POST body, a URL-encoded address in a Referer, and a SHA-256 of a Base64 of the normalised address — plus one clean request:

137 needles (depth 2)
HIT normalised>sha256                url                    https://tracker-a.test/tr?id=1&ud[em]=396d41004bcb22ea64d7cfb81003769d
HIT plain>base64                     body                   https://tracker-b.test/collect
HIT plain>urlenc                     header:Referer         https://tracker-c.test/p.gif
HIT normalised>base64>sha256         url                    https://tracker-d.test/g?x=acb7968d29e531c65c5fad469f338feca4c3d01dd5d
4 match(es) in 4 distinct request(s)

At --depth 1 the same run builds 22 needles and finds 3 of the 4 requests — the chained one is invisible, which is the whole argument for stating your depth. Two of the four hits exist only because of the normalised seed. The fixture, both outputs and the script are in the workdir (sandbox/pii/) and on the provenance page.

What this script does not do: read WebSocket frames (Chrome's HAR keeps them under a non-standard _webSocketMessages key), match a value that is only partly percent-encoded, or search responses. What no detector of this kind can see, and you should say so: keyed or salted hashes whose salt you do not know; custom ciphers; binary encodings (protobuf, MessagePack) and compression you do not decode; values split across requests or truncated; data types derived from the value rather than the value itself; anything sent before your capture starts or after it stops; WebSocket frames and service-worker traffic unless your instrument records them (No boundaries names WebSocket and WebRTC as gaps of its Firefox instrumentation [6Acar, Gunes; Englehardt, Steven; Narayanan, Arvind (2020): "No boundaries: data exfiltration by third parties embedded on web pages", Proceedings on Privacy Enhancing Technologies 2020(4):220-238. (DOI)]); and everything that leaves from the site's server. Validate the detector on a local fixture that sends each transformation you claim to cover — and some you do not — and report its recall on the fixture separately from the crawl.

Two older tricks still earn their place. The differential: submit twice with the same value and once with a different one, and flag any request parameter that is stable across the first two and changes in the third — it caught encodings without naming them in the contact-form study [2Starov, Oleksii; Gill, Phillipa; Nikiforakis, Nick (2016): "Are You Sure You Want to Contact Us? Quantifying the Leakage of PII via Website Contact Forms", in: Proceedings on Privacy Enhancing Technologies. (DOI)], and Agrigento applies the same differential idea to Android apps, perturbing device values across repeated runs [25Continella, Andrea; Fratantonio, Yanick; Lindorfer, Martina; Puccetti, Alessandro; Zand, Ali; Kruegel, Christopher; Vigna, Giovanni (2017): "Obfuscation-Resilient Privacy Leak Detection for Mobile Apps Through Differential Analysis", in: Proceedings of the Network and Distributed System Security Symposium. (DOI)]. The size differential: No boundaries appended a 200 KB chunk to the DOM and re-measured, and found 8 of its 28 DOM-exfiltrating scripts only that way, because their payload encodings were not in its detector [6Acar, Gunes; Englehardt, Steven; Narayanan, Arvind (2020): "No boundaries: data exfiltration by third parties embedded on web pages", Proceedings on Privacy Enhancing Technologies 2020(4):220-238. (DOI)]. Both produce candidates for manual inspection, not findings.

Third party, tracker and recipient are three labels, not one. Start from the registrable domain with a dated Public Suffix List, resolve the owning entity (Ownership resolution), and keep the raw hostname. Then decide whether “tracker” matters to your question. Leaky Forms counted only leaks to trackers, but did not take the blocklists' word for what a tracker is: it hand-labelled the receiving domains that none of four lists flagged and found 41 trackers among them [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)] — so a list-only filter undercounts, and a vendor that receives a password over HTTPS is still a third party: the app-versus-web study found four password flows on 50 services — to taplytics.com (Grubhub's analytics provider; the fix was an app update), usablenet.com (JetBlue) and Gigya, an identity-management service (two services) [21Leung, Christophe; Ren, Jingjing; Choffnes, David R.; Wilson, Christo (2016): "Should You Use the App for That?: Comparing the Privacy Implications of App- and Web-based Online Services", in: Proceedings of the ACM Internet Measurement Conference. (DOI)].

A first-party name may not be a first party. CNAME cloaking puts a tracker behind the site's own subdomain; the contact-form study already treated a same-domain subdomain in a different autonomous system as a third party [2Starov, Oleksii; Gill, Phillipa; Nikiforakis, Nick (2016): "Are You Sure You Want to Contact Us? Quantifying the Leakage of PII via Website Contact Forms", in: Proceedings on Privacy Enhancing Technologies. (DOI)], and Dimova et al.'s login experiment above is a CNAME result [18Dimova, 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)]. Leaky Forms leaves CNAME-cloaked trackers to future work [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)]. And the vendors now do the cloaking for you: Google's tag gateway serves the Google tag from the site's own domain and sends “some measurement requests” to Google through it ⁴⁾, so a recipient rule keyed on the hostname calls them first-party.

Server-side flows need a different instrument. A value that goes to the site and leaves from its server is invisible to the crawler — Server side tracking covers the detection problem. For personal data the working instrument is a per-site canary that can arrive somewhere you watch: an email address used on exactly one site. The contact-form study received 309 emails from third parties its crawler never contacted [2Starov, Oleksii; Gill, Phillipa; Nikiforakis, Nick (2016): "Are You Sure You Want to Contact Us? Quantifying the Leakage of PII via Website Contact Forms", in: Proceedings on Privacy Enhancing Technologies. (DOI)]; Leaky Forms received 290 emails from 88 sites without ever submitting a form [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)]; Kafle et al. found 8 of 26 campaign newsletters passing the address to other political organisations [5Kafle, Kaushal; Mandal, Prianka; Singh, Kapil; Andow, Benjamin; Nadkarni, Adwait (2024): "Understanding the Privacy Practices of Political Campaigns: A Perspective from the 2020 US Election Websites", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)]; and Kubicek et al. registered on 666 sites with a unique address per site and registration (1,234 addresses) and report that 4.1% of their addresses received mail from multiple senders — a sender domain that differs from the site's, which includes the same company under another domain [13Kubíček, Karel; Merane, Jakob; Cotrini, Carlos; Stremitzer, Alexander; Bechtold, Stefan; Basin, David (2022): "Checking Websites' GDPR Consent Compliance for Marketing Emails", Proceedings on Privacy Enhancing Technologies 2022(2). (DOI)]. A mailbox tells you that the value moved, not by which route, and its window is as long as you keep reading it.

For special-category data the request does not need to carry a value: the page does. Four papers in this population measure third parties on pages whose topic falls under the GDPR's special categories — the page counts them under that rule, though only Dambra et al. spell out what a tracker learns from the visit itself. Iordanou et al., with 350 real users' browsing, found requests to sensitive-topic sites to be 2.89% of tracking flows, health the most tracked category within them, and frame the result as cross-border flows of sensitive data [8Iordanou, Costas; Smaragdakis, Georgios; Poese, Ingmar; Laoutaris, Nikolaos (2018): "Tracing Cross Border Web Tracking", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]; Vallina et al. found 72% of the pornographic sites they analysed using third-party cookies [11Vallina, Pelayo; Feal, Álvaro; Gamba, Julien; Vallina-Rodriguez, Narseo; Anta, Antonio Fernández (2019): "Tales from the Porn: A Comprehensive Privacy Analysis of the Web Porn Ecosystem", in: Proceedings of the ACM Internet Measurement Conference. (DOI)]; Dambra et al. used real users' telemetry across sites in six sensitive categories, including health, sexuality, politics and religion [12Dambra, Savino; Sanchez-Rola, Iskander; Bilge, Leyla; Balzarotti, Davide (2022): "When Sally Met Trackers: Web Tracking From the Users' Perspective", in: Proceedings of the USENIX Security Symposium. (Link)]; and Bekos et al. counted Meta Pixel adoption on sites listed under health (16.9% of 7,679), politics, sexual orientation, ethnicity and religion (4.6% of 9,119) [26Bekos, Paschalis; Papadopoulos, Panagiotis; Markatos, Evangelos P.; Kourtellis, Nicolas (2023): "The Hitchhiker's Guide to Facebook Web Tracking with Invisible Pixels and Click IDs", in: Proceedings of the ACM Web Conference. (DOI)].

Three choices decide what such a figure means. How the topic was assigned — Iordanou et al. used advertising topic tags plus two examiners who had to agree; a vendor category feed is a different instrument with its own error (Website classification). What the third party received — a domain, a full URL, an event name like Purchase or AddToCart, or a value; PIIxel Leaks separates full-URL reporting for exactly this reason [3Bekos, Paschalis; Papadopoulos, Panagiotis; Kourtellis, Nicolas; Polychronakis, Michalis (2025): "PIIxel Leaks: Passive Identification of Personally Identifiable Information Leakage through Meta Pixel", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]. And whose visit it was — a crawler's visit discloses nothing about a person, so the claim is about what the site would send for a real visitor, which is a configuration claim in disguise.

Not one of the 20 papers counted here is a health-sector study, and none is about pharmacies or tax software. The corpus measures health only as one category inside a general crawl — Tracker Installations found Meta form-data collection on 30.8% of health and 20.3% of finance sites with a Meta Pixel, against 68% in the other verticals [4Kieserman, Julia B.; Andreou, Athanasios; Geeng, Chris; Lauinger, Tobias; McCoy, Damon (2025): "Tracker Installations Are Not Created Equal: Understanding Tracker Configuration of Form Data Collection", in: Proceedings on Privacy Enhancing Technologies, pp. 679-695. (DOI)]; PIIxel Leaks also finds PII-tracking configurations less common on health and finance sites [3Bekos, Paschalis; Papadopoulos, Panagiotis; Kourtellis, Nicolas; Polychronakis, Michalis (2025): "PIIxel Leaks: Passive Identification of Personally Identifiable Information Leakage through Meta Pixel", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]. The sector work lives outside the seven venues: medical journals census hospital sites (third-party tracking on 98.6% of US non-federal acute-care hospital websites [27Friedman, Ari B.; Merchant, Raina M.; Maley, Amey; Farhat, Karim; Smith, Kristen; Felkins, Jackson; Gonzales, Rachel E.; Bauer, Lujo; McCoy, Matthew S. (2023): "Widespread Third-Party Tracking On Hospital Websites Poses Privacy Risks For Patients And Legal Liability For Hospitals", Health Affairs 42(4). (DOI)]), a WPES paper instrumented patient portals and found medications and lab results reaching third parties from 5 of 459 patient portals and 4 telehealth sites [9Huo, Mingjia; Bland, Maxwell; Levchenko, Kirill (2022): "All Eyes On Me: Inside Third Party Trackers' Exfiltration of PHI from Healthcare Providers' Online Systems", in: Proceedings of the 21st Workshop on Privacy in the Electronic Society. (DOI)], and journalists ran the tax-filing measurement ⁵⁾. A longitudinal study of Meta Pixel configurations on 18K health sites via the Wayback Machine is in IMC 2026, which reached the extraction on the day this page was written, after the snapshot it counts: tracking-restriction features such as Meta's “Core Setup” rose on the health sites from 15.6% in 2023 to 34.3% in 2024 (control: 8.7% in 2024), and still “provide limited protection” [10Ghani, Abdullah; Vekaria, Yash; Shafiq, Zubair (2026): "PixelConfig: Longitudinal Measurement and Reverse-Engineering of Meta Pixel Configurations", in: Proceedings of the ACM Internet Measurement Conference. (DOI)].

That is the gap to know about before you design a sector study: the regulators acted on these flows before anyone in these venues measured them as a sector or at scale — the one in-corpus health leak is a prescription leak found by hand on a pharmacy site in a 2017–2018 session-replay pass [6Acar, Gunes; Englehardt, Steven; Narayanan, Arvind (2020): "No boundaries: data exfiltration by third parties embedded on web pages", Proceedings on Privacy Enhancing Technologies 2020(4):220-238. (DOI)].

Legal enforcement covers taking a finding to an authority. Pair any compliance claim with the jurisdiction, the controller, the data type, the purpose and the consent state you measured.

A synthetic value is still real traffic, and it creates real records: support tickets, sales leads, newsletter subscriptions, accounts, sometimes a phone call. Ethics covers the general apparatus; what is specific here:

• Prefer not submitting. Leaky Forms shows that substantial leakage happens before submit (1,844 EU and 2,950 US sites), so typing and blurring already answer many questions; the contact-form study's submissions produced 309 unsolicited third-party emails to the authors [2Starov, Oleksii; Gill, Phillipa; Nikiforakis, Nick (2016): "Are You Sure You Want to Contact Us? Quantifying the Leakage of PII via Website Contact Forms", in: Proceedings on Privacy Enhancing Technologies. (DOI)]. If your question can be answered by typing and blurring, stop there. PIIxel Leaks lists not affecting sites' ad budgets or traffic among the advantages of its static analysis [3Bekos, Paschalis; Papadopoulos, Panagiotis; Kourtellis, Nicolas; Polychronakis, Michalis (2025): "PIIxel Leaks: Passive Identification of Personally Identifiable Information Leakage through Meta Pixel", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]; Tracker Installations injected its own form rather than using the site's.
• Use identities that cannot be mistaken for a person. Fictional names, addresses on a domain you control, phone numbers you own. The gig-work study needed verifiable personas, so two of them were two authors' real identities, with real social security numbers — and the worst leak it found was SSN hashes sent to Meta and TikTok [20Pradeep, Amogh; Gunawan, Johanna; Feal, Álvaro; Hartzog, Woodrow; Choffnes, David (2025): "Gig Work at What Cost? Exploring Privacy Risks of Gig Work Platform Participation in the U.S.", Proceedings on Privacy Enhancing Technologies . (DOI)]. If a study needs a real identity, it needs an ethics review that says so.
• Do not touch high-consequence flows — medical booking, prescriptions, tax filing, government forms — without explicit approval. A plausible synthetic patient record can end up in a clinic's system.
• Disclose, and expect silence. Leaky Forms reported password collection to trackers and to more than 50 sites: Yandex and Mixpanel shipped fixes, LogRocket never replied, and none of the top 33 US sites it notified about email exfiltration answered [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)]. Lyft and Uber removed SSN hashing from their sign-up pages after the gig-work authors contacted them [20Pradeep, Amogh; Gunawan, Johanna; Feal, Álvaro; Hartzog, Woodrow; Choffnes, David (2025): "Gig Work at What Cost? Exploring Privacy Risks of Gig Work Platform Participation in the U.S.", Proceedings on Privacy Enhancing Technologies . (DOI)]. Four of 119 health and finance sites said they would review their configuration after Tracker Installations wrote to them [4Kieserman, Julia B.; Andreou, Athanasios; Geeng, Chris; Lauinger, Tobias; McCoy, Damon (2025): "Tracker Installations Are Not Created Equal: Understanding Tracker Configuration of Form Data Collection", in: Proceedings on Privacy Enhancing Technologies, pp. 679-695. (DOI)]. Notifying websites has the response-rate literature.
• Real users' traffic is a different study. The visit-based papers here used browser extensions or telemetry from consenting users; their captures contain the very data this page is about. Minimise, aggregate, and keep raw payloads out of your artifact.

The corpus is uneven on this. In the extraction's ethics fields, 4 of the 20 say anything about ethics review — three of them that none was sought or needed — against 33.8% of empirical papers corpus-wide, while 17 describe harm mitigation (62.3% corpus-wide) and 13 say whether they notified affected parties (46.0%). With 20 papers these are indications, not tests.

First / latest is what the 20 papers did. Status is this page's judgement, from those years, the 2025–2026 slice, work outside the seven venues and vendor documentation; with 20 papers it is not a ranking of what works.

Session-replay leakage was measured in this corpus once, on 2017–2018 data [6Acar, Gunes; Englehardt, Steven; Narayanan, Arvind (2020): "No boundaries: data exfiltration by third parties embedded on web pages", Proceedings on Privacy Enhancing Technologies 2020(4):220-238. (DOI)], plus the password collection Leaky Forms found in 2021 on 52 sites, 50 of them through Yandex Metrica's session recording [1Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)]. Vendor documentation describes different defaults today — Microsoft Clarity masks input boxes in every mode ¹⁵⁾; LogRocket offers a per-element data-private attribute and says password fields are never recorded ¹⁶⁾ — but neither the 2017 finding nor a vendor's documentation is evidence about a 2026 deployment. Measure the deployment.

None of these is a complete PII classifier. Keep an unlisted-recipient audit and a manual check of ambiguous matches in every study.

All figures below come from the publication corpus — CCS, IMC, NDSS, PoPETs, USENIX Security, TheWebConf and IEEE S&P, 2010–2026, 5,859 extracted papers, of which 5,855 have full text. The extraction was being extended with IMC 2026 and an IEEE S&P backfill while this page was written; every count here is on the 5,859-paper snapshot the other pages use, and the report prints how many later records it ignored. The report script report_pii_leakage.mjs, its unedited output, every verdict and the probes are on pii_leakage.

The gap pass that proposed this page counted 218 papers with five or more hits of its PII regex in paper.norm.txt; on whitespace-collapsed paper.cols.txt the same regex gives 226. Of those, 13 are IN (5.8% precision), and the regex finds 13 of the 20 (65.0% recall). Its noise is the noise the queuing note predicted: 4 of its top 20 hits are PII in or extracted from language models, and across all 226 the largest classes are mobile apps (61), attacks (27), user studies (24) and language models (20). What it misses is systematic: 7 papers, three of them the sensitive-visit studies, which never need the word “PII”, plus DiffAudit, the CNAME login experiment, the marketing-email study and the wallet study. The sentence probe finds 16 of the 20 and the sector probe 9; only the union finds all of them.

* provisional. The first paper is from 2016 and there is no year with more than four. With three to eight papers a bucket, the per-1,000 column is flat within noise; it does not support a trend in either direction. By venue: PoPETs 9 of the 20 (1.8% of its papers), IMC 5, USENIX Security 3, and one each at CCS, IEEE S&P and TheWebConf; NDSS none. Channel (multi-valued): outgoing traffic classified by data type 7, URL or Referer 6, typed form input 4, sensitive visit 4, tag event parameters 3, page or DOM content 3, the operator's server 2, session replay 1. Sector: general 11, sensitive-category visits 3, finance 2, and one each for politics, children, employment and adult content — health 0.

Configuration reading is new. Event-parameter leaks appear only in 2025 (all 3 papers), and reading the tag configuration first appears in 2023 and is in 2 of the 3 papers from 2025. The encoding search appears in 6 papers from 2017 to 2025 — never more than two a year. The canary itself is in 14 of the 20.

Each row compares the population with the corpus-wide baseline on the same denominator.

A study whose results depend on how far the crawler got into a form has to describe the crawler, and these do. The weak rows are the ones a reviewer of a PII study should push on: 16 of the 20 papers say nothing about an ethics review, in a literature where 14 of the 20 plant values they control on other people's sites — though the same papers describe harm mitigation and notification more often than the corpus does. The two rows not shown, interaction depth and authentication, are stated by nearly all 16 crawling papers, as expected for a form study. 8 of the 20 assessed a law in the extraction's legal field (GDPR in 5), against 388 of 5,118 empirical papers (7.6%). With 20 papers, every row here is an indication, not a test.

These are different experiments, years apart, on different populations. Do not pool them, and do not quote one as “the” leak rate.

Nor can it tell you what recipients do with what they receive — a platform's matching and targeting is Advertising and Email tracking; the queuing item's spine candidate Investigating sources of PII used in Facebook's targeted advertising [14Venkatadri, Giridhari; Lucherini, Elena; Sapiezynski, Piotr; Mislove, Alan (2019): "Investigating sources of PII used in Facebook’s targeted advertising", in: Proceedings on Privacy Enhancing Technologies. (DOI)] is context here for that reason — or anything about mobile apps, where the PII-leak detectors are older and larger (Mobile and app measurement).

For a reviewer to accept a PII-leakage result, the methodology needs, roughly in this order:

1. The outcome: read, transmitted, configured, sensitive visit, or shared after receipt — one per column, never merged.
2. The funnel, with a number on every step: frame (list and date) → reached → page or form found → value entered → interaction completed → capture usable → match. Name the denominator of every rate.
3. The canary: data types, how each value was made unique per site, and whether any real identity was used. A plus-tag (name+site42@) is cheap but collapses if a recipient strips plus-tags before hashing; a distinct local part or a domain per site survives normalisation.
4. The interaction: typed or injected, blurred, submitted or not, logged in or not, consent treatment and whether it took effect, vantage, browser and version, dwell time, retries.
5. The search space: every normalisation and transformation, their order and depth, where you searched (URL, Referer, other headers, cookies, bodies, WebSocket frames), what you could not decode, and the detector's recall on a fixture.
6. The recipient rule: registrable domain, entity map, CNAME handling, which lists, and how unlisted recipients were labelled.
7. Counts of sites, forms, recipients and requests, separately. One value matched in six encodings on one site is one leaking site.
8. What the client cannot see, said as a limit, and whether a mailbox or other canary covered it.
9. Ethics: what was submitted where, account cleanup, review outcome, disclosure and its result.

A template sentence (the numbers are illustrative, not from a paper): “On 18,204 of a 50,000-site Tranco list (ID XXXXX, 2026-09-01) our crawler found and filled an email field (Chromium 152, headful, German residential vantage, consent rejected via the CMP, no submission); a per-site address on a domain we control reached a third party on 612 sites (3.4%), 541 of them as a SHA-256 of the lower-cased address, under a search of 14 transformations to depth 3 that recovered 96 of 100 planted fixtures; 37 sites later sent mail to the address from another domain.”

• The population is a hand audit, not an extraction field. 314 candidates, one verdict each, against a rule written before the first count; every IN paper was read in full and its tags corrected from the reading; the 97 CONTEXT and web-platform OUT verdicts that existed when the audit was frozen were re-checked by a second reader (in full text for the groups most likely to hide a miss, from the first reader's notes for the rest), and the 196 other OUT verdicts — papers whose extraction does not list the web platform — were not. Borderline calls remain — DiffAudit, which classifies key names rather than values but ran logged-in test accounts whose personal values were in the payloads (the unauthenticated WebSocket crawl, also key-name evidence, is CONTEXT for that reason); the wallet-address paper (a wallet address is on the rule's list, but the paper says it is “not necessarily” linked to an identity), and the two mailbox studies, whose flows leave through the operator. Every verdict and its note are on the provenance page.
• Counts are of papers, never tuples; sentinels are never answers. Channel and method tags are multi-valued, so their columns do not sum to 20.
• The encoding table is coded from what papers say. A paper that searched for a hash without naming it is coded as not stating one; that makes the “6 of 12” a floor.
• Year counts are small and the 2025–2026 bucket is provisional.
• Per-paper figures are the papers' own, with the papers' own denominators, located verbatim in the paper's text; the needle check, with its mutation controls, is on the provenance page. External facts were fetched on 2026-10-08 by a script whose output is also there.
• Seven venues. See What the corpus cannot tell you and corpus for the corpus-wide caveats.
• Full query log, verdicts, probes and their residue, the second reader's audit, needle checks, external sources and reviewer findings: pii_leakage.

• Vekaria et al.'s SoK: Advances and Open Problems in Web Tracking [33Vekaria, 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)] (arXiv, revised 2026) — the field-wide survey to read alongside this page; it is not specific to personal-data leakage.

• Email tracking — the address as an identifier; the mailbox as an instrument.
• Interaction and Registration — getting the value onto the page.
• Server side tracking — the flows a crawler cannot see.
• JavaScript — attributing a read or a send to a script; session replay as code.
• Requests and Ownership resolution — labelling the recipient.
• Consent — the banner as a treatment.
• Advertising — what a platform does with what it receives.
• Ethics, Notifying websites and Legal enforcement — before, after, and what regulators did.
• Mobile and app measurement — the app-side PII-leak detectors.

[1]

Senol, Asuman; Acar, Gunes; Humbert, Mathias; Zuiderveen Borgesius, Frederik (2022): "Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission", in: 31st USENIX Security Symposium (USENIX Security 22). (Link)

[2]

Starov, Oleksii; Gill, Phillipa; Nikiforakis, Nick (2016): "Are You Sure You Want to Contact Us? Quantifying the Leakage of PII via Website Contact Forms", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[3]

Bekos, Paschalis; Papadopoulos, Panagiotis; Kourtellis, Nicolas; Polychronakis, Michalis (2025): "PIIxel Leaks: Passive Identification of Personally Identifiable Information Leakage through Meta Pixel", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[4]

Kieserman, Julia B.; Andreou, Athanasios; Geeng, Chris; Lauinger, Tobias; McCoy, Damon (2025): "Tracker Installations Are Not Created Equal: Understanding Tracker Configuration of Form Data Collection", in: Proceedings on Privacy Enhancing Technologies, pp. 679-695. (DOI)

[5]

Kafle, Kaushal; Mandal, Prianka; Singh, Kapil; Andow, Benjamin; Nadkarni, Adwait (2024): "Understanding the Privacy Practices of Political Campaigns: A Perspective from the 2020 US Election Websites", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[6]

Acar, Gunes; Englehardt, Steven; Narayanan, Arvind (2020): "No boundaries: data exfiltration by third parties embedded on web pages", Proceedings on Privacy Enhancing Technologies 2020(4):220-238. (DOI)

[7]

Kats, Daniel; Silva, David Luz; Roturier, Johann (2022): "Who Knows I Like Jelly Beans? An Investigation Into Search Privacy", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[8]

Iordanou, Costas; Smaragdakis, Georgios; Poese, Ingmar; Laoutaris, Nikolaos (2018): "Tracing Cross Border Web Tracking", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[9]

Huo, Mingjia; Bland, Maxwell; Levchenko, Kirill (2022): "All Eyes On Me: Inside Third Party Trackers' Exfiltration of PHI from Healthcare Providers' Online Systems", in: Proceedings of the 21st Workshop on Privacy in the Electronic Society. (DOI)

[10]

Ghani, Abdullah; Vekaria, Yash; Shafiq, Zubair (2026): "PixelConfig: Longitudinal Measurement and Reverse-Engineering of Meta Pixel Configurations", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[11]

Vallina, Pelayo; Feal, Álvaro; Gamba, Julien; Vallina-Rodriguez, Narseo; Anta, Antonio Fernández (2019): "Tales from the Porn: A Comprehensive Privacy Analysis of the Web Porn Ecosystem", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[12]

Dambra, Savino; Sanchez-Rola, Iskander; Bilge, Leyla; Balzarotti, Davide (2022): "When Sally Met Trackers: Web Tracking From the Users' Perspective", in: Proceedings of the USENIX Security Symposium. (Link)

[13]

Kubíček, Karel; Merane, Jakob; Cotrini, Carlos; Stremitzer, Alexander; Bechtold, Stefan; Basin, David (2022): "Checking Websites' GDPR Consent Compliance for Marketing Emails", Proceedings on Privacy Enhancing Technologies 2022(2). (DOI)

[14]

Venkatadri, Giridhari; Lucherini, Elena; Sapiezynski, Piotr; Mislove, Alan (2019): "Investigating sources of PII used in Facebook’s targeted advertising", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[15]

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)

[16]

Libert, Timothy (2015): "Privacy Implications of Health Information Seeking on the Web", Communications of the ACM 58(3):68-77. (DOI)

[17]

Kaizer, Andrew J.; Gupta, Minaxi (2016): "Characterizing Website Behaviors Across Logged-in and Not-logged-in Users", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[18]

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)

[19]

Goldfeder, Steven; Kalodner, Harry; Reisman, Dillon; Narayanan, Arvind (2018): "When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies", Proceedings on Privacy Enhancing Technologies . (DOI)

[20]

Pradeep, Amogh; Gunawan, Johanna; Feal, Álvaro; Hartzog, Woodrow; Choffnes, David (2025): "Gig Work at What Cost? Exploring Privacy Risks of Gig Work Platform Participation in the U.S.", Proceedings on Privacy Enhancing Technologies . (DOI)

[21]

Leung, Christophe; Ren, Jingjing; Choffnes, David R.; Wilson, Christo (2016): "Should You Use the App for That?: Comparing the Privacy Implications of App- and Web-based Online Services", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[22]

Brookman, Justin; Rouge, Phoebe; Alva, Aaron; Yeung, Christina (2017): "Cross-Device Tracking: Measurement and Disclosures", Proceedings on Privacy Enhancing Technologies 2017(2). (DOI)

[23]

Ferreira Torres, Christof; Willi, Fiona; Shinde, Shweta (2023): "Is Your Wallet Snitching On You? An Analysis on the Privacy Implications of Web3", in: 32nd USENIX Security Symposium (USENIX Security 23). (Link)

[24]

Englehardt, Steven; Han, Jeffrey; Narayanan, Arvind (2018): "I never signed up for this! Privacy implications of email tracking", Proceedings on Privacy Enhancing Technologies 2018(1):109-126. (DOI)

[25]

Continella, Andrea; Fratantonio, Yanick; Lindorfer, Martina; Puccetti, Alessandro; Zand, Ali; Kruegel, Christopher; Vigna, Giovanni (2017): "Obfuscation-Resilient Privacy Leak Detection for Mobile Apps Through Differential Analysis", in: Proceedings of the Network and Distributed System Security Symposium. (DOI)

[26]

Bekos, Paschalis; Papadopoulos, Panagiotis; Markatos, Evangelos P.; Kourtellis, Nicolas (2023): "The Hitchhiker's Guide to Facebook Web Tracking with Invisible Pixels and Click IDs", in: Proceedings of the ACM Web Conference. (DOI)

[27]

Friedman, Ari B.; Merchant, Raina M.; Maley, Amey; Farhat, Karim; Smith, Kristen; Felkins, Jackson; Gonzales, Rachel E.; Bauer, Lujo; McCoy, Matthew S. (2023): "Widespread Third-Party Tracking On Hospital Websites Poses Privacy Risks For Patients And Legal Liability For Hospitals", Health Affairs 42(4). (DOI)

[28]

Figueira, Olivia; Trimananda, Rahmadi; Markopoulou, Athina; Jordan, Scott (2024): "DiffAudit: Auditing Privacy Practices of Online Services for Children and Adolescents", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[29]

Cory, Thomas; Küpper, Axel (2026): "Addressing Labelled Data Scarcity: Taxonomy-Agnostic Annotation of PII Values in HTTP Traffic using LLMs". arXiv:2605.06305. Accepted to the 2026 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), per the arXiv record, checked 2026-10-08 (Link)

[30]

Chatzimpyrros, Manolis; Solomos, Konstantinos; Ioannidis, Sotiris (2020): "You Shall Not Register! Detecting Privacy Leaks Across Registration Forms", in: Computer Security, pp. 91-104. (DOI)

[31]

Dao, Ha; Fukuda, Kensuke (2021): "Alternative to Third-Party Cookies: Investigating Persistent PII Leakage-Based Web Tracking", in: Proceedings of the 17th International Conference on emerging Networking EXperiments and Technologies. (DOI)

[32]

Krishnamurthy, Balachander; Naryshkin, Konstantin; Wills, Craig E. (2011): "Privacy Leakage vs. Protection Measures: the Growing Disconnect", in: Web 2.0 Security and Privacy Workshop (W2SP). (Link)

[33]

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)