| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| privacy:email_tracking [2026/09/02 07:10] – Number-guard fixes: all eight silence base rates now computed by the page's own report (artifacts.availability corrected to 59.5% on the comparable denominator); ethics comparison corrected from 33.8% to the comparable 38.6%; legal-assessment breakdown ad karel.kubicek.claude | privacy:email_tracking [2026/09/02 07:40] (current) – Generic + re-verification review fixes: state the real hand-map accounting (183 mapped / 125 with a written reason / 171 defaulted at title level) instead of claiming 183 hand-written reasons; correct '73 papers outside the pool' to 67 distinct / 72 menti karel.kubicek.claude |
|---|
| You are about to measure something that arrives in a mailbox or on a handset: a tracking pixel in a newsletter, whether an unsubscribe link works, how much spam a filter lets through, what an SMS scam campaign looks like. This page is about the **instrument** that question needs — an address you control, a way to make mail arrive at it, and a way to render it without becoming part of the measurement — and about which of the field's methods are still current. | You are about to measure something that arrives in a mailbox or on a handset: a tracking pixel in a newsletter, whether an unsubscribe link works, how much spam a filter lets through, what an SMS scam campaign looks like. This page is about the **instrument** that question needs — an address you control, a way to make mail arrive at it, and a way to render it without becoming part of the measurement — and about which of the field's methods are still current. |
| |
| It is not a tutorial on SMTP, MIME or what a ''1x1'' GIF is. It assumes you can read [[https://www.rfc-editor.org/rfc/rfc5322.txt|RFC 5322]] yourself. What it adds is the part no spec tells you: that the mailbox provider now sits between you and the sender, that two of the four things you might want to measure have essentially never been measured in these venues, and that the interesting slice of this topic stopped being email some years ago. | It is not a tutorial on SMTP, MIME or what a ''1x1'' GIF is. It assumes you can read [[https://www.rfc-editor.org/rfc/rfc5322.txt|RFC 5322]] yourself. What it adds is the part no spec tells you: that the mailbox provider now sits between you and the sender and changes what your instrument can see; that one of the four things you might want to measure here has **never** been measured in these seven venues, and a second — what those provider defences do to a tracking measurement — has not been measured either; and that the busiest part of this topic stopped being email some years ago. |
| |
| <WRAP important> | <WRAP important> |
| **The one thing to understand before you start: the mailbox provider is now a party to your measurement, and it does not do the same thing to every signal.** Gmail proxies remote images, so the sender learns nothing about the recipient's IP, user agent or cookies — but still learns that the message was opened. Google says both parts in the same help article: "Senders can't use image loading to get information about your computer or location", "Senders can't use the image to set or read cookies in your browser", and then "Sometimes, senders may know whether you've opened an email that has an image."((Google, [[https://support.google.com/mail/answer/145919|"Turn images on or off in Gmail"]], section "Learn how Gmail helps make images safe". Fetched 2026-09-02.)) Apple Mail Privacy Protection, on by default since iOS 15 (2021), takes the other half too: it "hides your IP address so senders can't link it to your other online activity or determine your exact location" and "prevents senders from seeing if you've opened the email message they sent you", by fetching remote content in the background on arrival rather than on view.((Apple, [[https://support.apple.com/guide/iphone/use-mail-privacy-protection-iphf084865c7/ios|"Use Mail Privacy Protection on iPhone"]]. Fetched 2026-09-02 with a real browser; the page is client-rendered and ''curl'' alone returns a shell.)) | **The one thing to understand before you start: the mailbox provider is now a party to your measurement, and it does not do the same thing to every signal.** Gmail proxies remote images, so the sender learns nothing about the recipient's IP, user agent or cookies — but still learns that the message was opened. Google says both parts in the same help article: "Senders can't use image loading to get information about your computer or location", "Senders can't use the image to set or read cookies in your browser", and then "Sometimes, senders may know whether you've opened an email that has an image."((Google, [[https://support.google.com/mail/answer/145919|"Turn images on or off in Gmail"]], section "Learn how Gmail helps make images safe". Fetched 2026-09-02.)) Apple Mail Privacy Protection, available since iOS 15 (2021), takes the other half too: it "hides your IP address so senders can't link it to your other online activity or determine your exact location" and "prevents senders from seeing if you've opened the email message they sent you", by fetching remote content in the background on arrival rather than on view.((Apple, [[https://support.apple.com/guide/iphone/use-mail-privacy-protection-iphf084865c7/ios|"Use Mail Privacy Protection on iPhone"]]. Fetched 2026-09-02. The quoted sentences were read out of a real headless browser, because the guide is client-rendered; ''curl'' returns a navigation shell **plus** a noscript copy of the body, which is why the check in ''external_checks_email_tracking.sh'' also finds the needle. Trust the browser fetch, not the ''curl'' pass. iOS 15 is the oldest version the guide's own version selector offers, which is the date evidence. Apple documents it as a setting the user turns on and publishes no take-up figure, so **do not assume it is on and do not assume it is off** — from the sender side you cannot tell, and that is itself the measurement problem.)) |
| |
| So "we found a tracking pixel in 24.6% of messages" and "the sender learned that 24.6% of messages were opened" are now different claims, and which one you can make depends on **which client you rendered in**. None of the email-tracking papers in this corpus measures the effect of that change: the newest of them {[chand2025_doubly]} was published in 2025 and still treats the pixel fetch as the signal. If you are planning this measurement, the client is a treatment you have to vary on purpose, and you have no baseline in this literature to compare against. See [[#What a Pixel Can Still Measure in 2026]]. | So "we found a tracking pixel in 24.6% of messages" and "the sender learned that 24.6% of messages were opened" are now different claims, and which one you can make depends on **which client you rendered in**. None of the email-tracking papers in this corpus measures the effect of that change: the newest of them {[chand2025_doubly]} was published in 2025 and still treats the pixel fetch as the signal. If you are planning this measurement, the client is a treatment you have to vary on purpose, and you have no baseline in this literature to compare against. See [[#What a Pixel Can Still Measure in 2026]]. |
| ===== What to Read First ===== | ===== What to Read First ===== |
| |
| * **Englehardt, Han and Narayanan, //I never signed up for this! Privacy implications of email tracking//** {[englehardt2018_email]} (PoPETs 2018) — the method paper for this whole topic. Subscribe to 12,618 mailing lists with a distinct address each, render what arrives in instrumented clients, and look for the address in outbound requests. Everything since is a variation on it. | * **Englehardt, Han and Narayanan, //I never signed up for this! Privacy implications of email tracking//** {[englehardt2018_email]} (PoPETs 2018) — the method paper for this whole topic. Crawl 15,700 sites, sign up for mail on each with a distinct address, render what arrives in instrumented clients, and look for the address in outbound requests. The corpus that came out is **12,618 emails from 902 distinct senders** — a 38% submission success rate, of which 32% were mailing-list subscriptions. Quote the 902, not the 12,618, when you mean senders. Everything since is a variation on it. |
| * **Hu and Wang, //Characterizing Pixel Tracking through the Lens of Disposable Email Services//** {[hu2019_characterizing]} (IEEE S&P 2019) — the other vantage point, and read it for the denominator shock: on a disposable-mail provider, **94.75%** of the mail is spam and only 3.63% is registration, so its "24.6% of messages carry tracking" is a statement about a different population than Englehardt's. | * **Hu and Wang, //Characterizing Pixel Tracking through the Lens of Disposable Email Services//** {[hu2019_characterizing]} (IEEE S&P 2019) — the other vantage point, and read it for the denominator shock: on a disposable-mail provider, **94.75%** of the mail is spam and only 3.63% is registration, so its "24.6% of messages carry tracking" is a statement about a different population than Englehardt's. |
| * **Kirchner et al., //A Black-Box Privacy Analysis of Messaging Service Providers' Chat Message Processing//** {[kirchner2024_black]} (PoPETs 2024) — the same method, carried to 105 messaging platforms with honey messages and honey tokens. The most useful single paper if your channel is not email. | * **Kirchner et al., //A Black-Box Privacy Analysis of Messaging Service Providers' Chat Message Processing//** {[kirchner2024_black]} (PoPETs 2024) — the same method, carried to 105 messaging platforms with honey messages and honey tokens. The most useful single paper if your channel is not email. |
| | **The mailbox as the instrument**, object elsewhere — honey accounts, canary addresses, notification and DSAR mail | **12** | 2016–2026 | A section, because it is where a student most often actually needs a mailbox | | | **The mailbox as the instrument**, object elsewhere — honey accounts, canary addresses, notification and DSAR mail | **12** | 2016–2026 | A section, because it is where a student most often actually needs a mailbox | |
| |
| **Seventy papers, then.** A parent page with a 0-paper child and an 8-paper child would have been four red links and one real page. The judgement, the counts behind it, and the alternatives considered are on [[provenance:privacy:email_tracking]]. | **Seventy papers, then.** A parent plus children would have put one page's worth of material behind five links, one of which has nothing at all to say and three of which have fewer papers than [[programming:crawler:openwpm]] has for a single tool. The judgement, the counts behind it, and the alternatives considered are on [[provenance:privacy:email_tracking]]. |
| |
| ==== What is deliberately not here ==== | ==== What is deliberately not here ==== |
| |
| Four neighbouring clusters are larger than anything on this page and are **not** on it. Each is named so you do not conclude the corpus is silent about it: | Four neighbouring clusters were screened out of the same candidate pool and are **not** on this page. Three of them are larger than any slice that is. Each is named so you do not conclude the corpus is silent about it: |
| |
| * **Email transport, authentication and encryption deployment** — SPF, DKIM, DMARC, DANE, MTA-STS, STARTTLS, S/MIME, sender spoofing, delivery paths. **31 papers**, heavily 2018–2026, and the single biggest coherent slice the pool turned up. It is page-sized and it is not tracking; it belongs under ''security:'' and does not exist yet. Start from Durumeric et al. {[durumeric2015_neither]} and Shen et al. {[shen2021_weak]} if you need it now. | * **Email transport, authentication and encryption deployment** — SPF, DKIM, DMARC, DANE, MTA-STS, STARTTLS, S/MIME, sender spoofing, delivery paths. **31 papers**, heavily 2018–2026. The social-spam cluster below is larger, but it is not one topic; this is, and it is page-sized. It is also not tracking; it belongs under ''security:'' and does not exist yet. Start from Durumeric et al. {[durumeric2015_neither]} and Shen et al. {[shen2021_weak]} if you need it now. |
| * **Phishing and its interventions**, with email as the vector — **28 papers**. [[Security:Phishing]] owns this. The line drawn here: a paper about what a message //discloses to a third party// is on this page; a paper about whether a user //falls for// a message is on that one. | * **Phishing and its interventions**, with email as the vector — **28 papers**. [[Security:Phishing]] owns this. The line drawn here: a paper about what a message //discloses to a third party// is on this page; a paper about whether a user //falls for// a message is on that one. |
| * **Social-platform, review, forum, SEO and ad-click spam** — **37 papers**, more than any slice on this page. "Spam" in these venues usually means Twitter accounts or product reviews, not mail. It is a platform question ([[Design:Platforms]]), not a message-channel one. | * **Social-platform, review, forum, SEO and ad-click spam** — **37 papers**, more than any slice on this page. "Spam" in these venues usually means Twitter accounts or product reviews, not mail. It is a platform question ([[Design:Platforms]]), not a message-channel one. |
| ==== What the corpus cannot tell you ==== | ==== What the corpus cannot tell you ==== |
| |
| * **Nothing here measures what a mailbox provider's own defences do to a tracking measurement.** Gmail's image proxy has been on since 2013 and Apple's Mail Privacy Protection since 2021; no paper on this page reports its results per client, or holds the client fixed and varies the provider. This is the single largest methodological gap on the page and it is squarely a measurement question. | * **Nothing here measures what a mailbox provider's own defences do to a tracking measurement.** Gmail's image proxy has been on since December 2013((Gmail Blog, [[https://gmail.googleblog.com/2013/12/images-now-showing.html|"Images Now Showing"]], 12 December 2013: "Instead of serving images directly from their original external host servers, Gmail will now serve all images through Google's own secure proxy servers", rolling out on desktop that day and to the mobile apps in early 2014. Fetched 2026-09-02.)) and Apple's Mail Privacy Protection since iOS 15 in 2021; no paper on this page reports its results per client, or holds the client fixed and varies the provider. This is the single largest methodological gap on the page and it is squarely a measurement question. |
| * **No paper here measures unsubscription.** See below; this is not a corpus-coverage caveat, it is a zero. | * **No paper here measures unsubscription.** See below; this is not a corpus-coverage caveat, it is a zero. |
| * **The lead-marketing pipeline is measured in halves.** {[venkatadri2019_auditing]} audits offline brokers through an ad platform; {[kempen2026_consumer]} sends CCPA requests to brokers; nothing in the extraction joins "who collected the address" to "what arrived in the mailbox". The paper that does exist — Vekaria, Demir, Kollnig and Shafiq, //Understanding Data Collection, Brokerage, and Spam in the Lead Marketing Ecosystem//, IEEE S&P 2026, doi ''10.1109/sp63933.2026.00162'' — **is in the bibliographic index and absent from the extraction**, because IEEE S&P 2026 has 252 index records and only **58** with an abstract, selection screens on abstracts, and **194** of that venue-year were therefore never screened. Read it; it is not in any figure on this page. | * **The lead-marketing pipeline is measured in halves.** {[venkatadri2019_auditing]} audits offline brokers through an ad platform; {[kempen2026_consumer]} sends CCPA requests to brokers; nothing in the extraction joins "who collected the address" to "what arrived in the mailbox". The paper that does exist — Vekaria, Demir, Kollnig and Shafiq, //Understanding Data Collection, Brokerage, and Spam in the Lead Marketing Ecosystem//, IEEE S&P 2026, doi ''10.1109/sp63933.2026.00162'' — **is in the bibliographic index and absent from the extraction**, because IEEE S&P 2026 has 252 index records and only **58** with an abstract, selection screens on abstracts, and **194** of that venue-year were therefore never screened. A free preprint and the authors' code and data are available, so "read it" is not blocked by the paywall.((''arxiv.org/abs/2604.06759'', submitted 8 April 2026, title and all four authors matching the IEEE record; code and data at ''github.com/Yash-Vekaria/lead-marketing-spam''. The DOI resolves to ''ieeexplore.ieee.org/document/11573454''. Checked 2026-09-02.)) It is not in any figure on this page. |
| * **Nobody has repeated the "your feed is not the population" comparison** since 2012 {[pitsillidis2012_taster]}, on any channel. It was true of spam feeds then. Whether it is true of the public smishing forums that the 2022–2025 papers all draw on is unknown, and three of them draw on overlapping sources. | * **Nobody has repeated the "your feed is not the population" comparison** since 2012 {[pitsillidis2012_taster]}, on any channel. It was true of spam feeds then. Whether it is true of the public smishing forums that the 2022–2025 papers all draw on is unknown, and three of them draw on overlapping sources. |
| |
| | **Cookies set or read by the image request** | yes | no | no | | | **Cookies set or read by the image request** | yes | no | no | |
| | **Which links were clicked** | yes | yes — clicks leave the mail client | yes | | | **Which links were clicked** | yes | yes — clicks leave the mail client | yes | |
| | **Address echoed in a URL** (the leak {[englehardt2018_email]} measured) | yes | yes — proxying the fetch does not remove the token from the URL | yes, if a link is clicked; the prefetch also fetches it | | | **Address echoed in a URL** (the leak {[englehardt2018_email]} measured) | yes | yes — proxying the fetch does not remove the token from the URL | yes, if a link is clicked; the prefetch also fetches it. Apple's Link Tracking Protection does not change this — see below | |
| | |
| | **A note on Apple's Link Tracking Protection, because it looks like it belongs in that last row and does not.** Safari 17 / iOS 17 (2023) added Link Tracking Protection, which strips a curated list of known tracking parameters from the query string and fragment of a URL when the user navigates between sites. WebKit describes it as a **Safari Private Browsing** protection and specifies what it covers: "The specific parts of the URL covered are query parameters and the fragment", against "known tracking" parameters, so that third-party scripts on the destination cannot read them.((WebKit, [[https://webkit.org/blog/15697/private-browsing-2-0/|"Private Browsing 2.0"]], the "Link Tracking Protection" section; fetched 2026-09-02. It lists the protection under "protections and defenses added to Private Browsing in Safari 17.0". Widely repeated claims that the same stripping applies to links opened from Mail, and that iOS 26 extended it to all of Safari, are **not** in this or any other Apple primary source this page's author could locate; they are therefore not asserted here. If your method depends on it, test it.)) That is a different mechanism from the one this table's last row is about: it removes named ad-network parameters such as ''gclid'', not an arbitrary hashed recipient address embedded in a path or query, which is what {[englehardt2018_email]} and {[hu2019_characterizing]} measured. **If your identifier happens to be a known ad-network parameter it may be stripped; if it is your own hash it will not be. Test rather than assume, in the exact client you are reporting on.** |
| |
| Two consequences for a study design. First, **"tracker present in the message" and "tracker learned something" have come apart**, and a prevalence figure has to say which it is. Second, the client is now a **treatment**: render the same corpus in two or three clients and report per client. No paper on this page does this, so if you do it you are producing the baseline, not comparing against one. The same logic as [[Privacy:Browser protection]], one layer up the stack. | Two consequences for a study design. First, **"tracker present in the message" and "tracker learned something" have come apart**, and a prevalence figure has to say which it is. Second, the client is now a **treatment**: render the same corpus in two or three clients and report per client. No paper on this page does this, so if you do it you are producing the baseline, not comparing against one. The same logic as [[Privacy:Browser protection]], one layer up the stack. |
| | CAN-SPAM | **2** | | | CAN-SPAM | **2** | |
| | the word %%unsubscrib*%% anywhere | 56 | | | the word %%unsubscrib*%% anywhere | 56 | |
| | | %%opt out of the mailing / e-mail / newsletter / marketing / list%% | **2** | |
| |
| The one ''List-Unsubscribe'' hit names the header in a table of RFC 6376 signable header fields; it measures nothing about it.((Chen et al., //A Large-scale and Longitudinal Measurement Study of DKIM Deployment//, USENIX Security 2022. The header appears in its Class-2 field list. Read by hand 2026-09-02.)) Both CAN-SPAM hits are motivational asides. Of the 56 ''unsubscrib*'' papers, **ten** are using the MQTT, pub/sub or SDN protocol verb, **three** mean the CCPA "do not sell" opt-out or an advertising opt-out cookie, **four** mean turning off a security notification, and the remaining 39 have a single passing mention in a paper about something else. | The one ''List-Unsubscribe'' hit names the header in a table of RFC 6376 signable header fields; it measures nothing about it.((Chen et al., //A Large-scale and Longitudinal Measurement Study of DKIM Deployment//, USENIX Security 2022. The header appears in its Class-2 field list. Read by hand 2026-09-02.)) Of the two CAN-SPAM hits, one is a motivational aside in an introduction and the other is a paper that extracts opt-out statements from privacy-policy //text// — neither measures a mechanism. Of the 56 ''unsubscrib*'' papers, **ten** are using the MQTT, pub/sub or SDN protocol verb, **three** mean the CCPA "do not sell" opt-out or an advertising opt-out cookie, **four** mean turning off a security notification, and the remaining 39 have a single passing mention in a paper about something else. |
| |
| **The nearest thing in the corpus is one sub-check inside one paper.** Kubicek et al. {[kubicek2022_emails]} report that **16%** of websites sending marketing mail provided neither an unsubscribe method nor a legal notice, alongside **17.3%** of such websites having at least one potential consent violation at the registration form, **21.9%** having one somewhere, **59%** sending a double opt-in confirmation first, and **2.3%** mailing the user's own password back in plaintext. | **The nearest thing in the corpus is one sub-check inside one paper.** Kubicek et al. {[kubicek2022_emails]} report that **16%** of websites sending marketing mail provided neither an unsubscribe method nor a legal notice, alongside **17.3%** of such websites having at least one potential consent violation at the registration form, **21.9%** having one somewhere, **59%** sending a double opt-in confirmation first, and **2.3%** mailing the user's own password back in plaintext. |
| |
| That is availability, not function. Nothing in these venues measures whether an unsubscribe link works, how long it takes to take effect, or whether the one-click mechanism that Google and Yahoo have required of bulk senders **since 1 February 2024** is actually implemented. The requirement is specific and testable: bulk senders — more than 5,000 messages a day to Gmail addresses — must supply ''List-Unsubscribe'' and ''List-Unsubscribe-Post'', citing RFC 2369 and RFC 8058, and must "process and honor unsubscribe requests within 48 hours".((Google, [[https://support.google.com/mail/answer/81126|"Email sender guidelines"]] and [[https://support.google.com/mail/answer/15263077|"Email subscription guidelines for senders"]], fetched 2026-09-02. Yahoo announced the same requirements first, on 3 October 2023: "we will require senders to support one-click unsubscribe and honor our users requests within two days" — Marcel Becker, [[https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam|"More Secure, Less Spam"]].)) Google also publishes the spam-rate thresholds it enforces: keep reported spam below 0.10%, and never reach 0.30%. | That is availability, not function. Nothing in these venues measures whether an unsubscribe link works, how long it takes to take effect, or whether the one-click mechanism that Google and Yahoo have required of bulk senders **since 1 February 2024** is actually implemented. The requirement is specific and testable: bulk senders — more than 5,000 messages a day to Gmail addresses — must supply ''List-Unsubscribe'' and ''List-Unsubscribe-Post'', citing RFC 2369 and RFC 8058, and must "process and honor unsubscribe requests within 48 hours".((Google, [[https://support.google.com/mail/answer/81126|"Email sender guidelines"]] and [[https://support.google.com/mail/answer/15263077|"Email subscription guidelines for senders"]], fetched 2026-09-02. Yahoo announced the same requirements first, on 3 October 2023: "we will require senders to support one-click unsubscribe and honor our users requests within two days" — Marcel Becker, [[https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam|"More Secure, Less Spam"]].)) Google also publishes the spam-rate thresholds it enforces: keep reported spam below 0.10%, and never reach 0.30%. And **the consequence of non-compliance changed in November 2025**, which changes what a measurement would observe: Google's own FAQ says "Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic. Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections."((Google, [[https://support.google.com/a/answer/14229414|"Email sender guidelines FAQ"]], fetched 2026-09-02.)) Before that, non-compliance meant the spam folder; now it can mean an SMTP rejection, so a compliance measurement should be looking for bounces as well as for foldering. |
| | |
| | **Microsoft is the asymmetry worth knowing about.** Since 5 May 2025, Outlook.com, Hotmail and Live require domains sending 5,000 or more messages a day to their consumer services to pass SPF, DKIM **and** DMARC, with non-compliant mail routed to Junk and rejection announced for later. It does **not** require one-click unsubscribe or cite RFC 8058 at all. So the three largest consumer mailbox providers do not agree on this mechanism: Google and Yahoo mandate RFC 8058, Microsoft mandates authentication only. Anyone measuring one-click-unsubscribe deployment has to say which providers' senders are in the population, because two of the three create the incentive and the third does not.((Microsoft, "Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders", Microsoft Defender for Office 365 blog, 4399730. **Verified only indirectly.** The announcement URL and Microsoft's own Q&A threads on ''learn.microsoft.com'' that quote it are served behind a block that refuses this host, both to ''curl'' and to a real headless browser (Azure Front Door: "The request is blocked"), so the wording above rests on Microsoft-hosted Q&A pages that quote and link the announcement rather than on the announcement itself, plus the ''550 5.7.515 Access denied'' NDR text those threads reproduce. Checked 2026-09-02. **Read the announcement before you cite this in a paper.**)) |
| |
| <WRAP todo> | <WRAP todo> |
| |
| * **Honeypots are the backbone.** Gupta et al. {[gupta2015_phoneypot]} established the design and its confounder in the same paper: older number blocks receive significantly more calls (t-test, p = 0.005), so a honeypot's numbers have history. Prasad et al. {[prasad2020_calling]} scaled it to 1,481,201 calls with audio and metadata; {[prasad2023_diving]} added weak supervision over transcripts to get 26,791 campaigns from 232,723 calls without hand-labelling everything; {[prasad2025_characterizing]} compared vantage points and found that a 90% audio-similarity threshold identifies campaigns common to several honeypots, which is the first evidence on this page about how much one vantage point misses. | * **Honeypots are the backbone.** Gupta et al. {[gupta2015_phoneypot]} established the design and its confounder in the same paper: older number blocks receive significantly more calls (t-test, p = 0.005), so a honeypot's numbers have history. Prasad et al. {[prasad2020_calling]} scaled it to 1,481,201 calls with audio and metadata; {[prasad2023_diving]} added weak supervision over transcripts to get 26,791 campaigns from 232,723 calls without hand-labelling everything; {[prasad2025_characterizing]} compared vantage points and found that a 90% audio-similarity threshold identifies campaigns common to several honeypots, which is the first evidence on this page about how much one vantage point misses. |
| * **Crowdsourced reports are how you get scale and languages.** Murynets and Piqueras Jover {[murynets2012_crime]} used a carrier reporting service; Li et al. {[li2017_radar]} crowdsourced fake-base-station detection; Tang et al. {[tang2022_clues]} mined tweeted screenshots for 21,918 unique SMS messages in 75 languages, recovering the text with OCR at 90% exact-match accuracy on a 1,000-image sample; Agarwal et al. {[agarwal2024_poster]} built a sector taxonomy from firewall-side data — delivery impersonation was the largest category at 830.2k recipients — and {[agarwal2025_fishing]} pushed the forum approach to five sources — 220,585 posts and 64,284 image attachments, from which an LLM extracted 27,718 unique messages, 19,314 sender IDs and 20,060 URLs across 66 languages. **The screenshot is the data format in this slice**, so budget for OCR or a vision model. | * **Crowdsourced reports are how you get scale and languages.** Murynets and Piqueras Jover {[murynets2012_crime]} used a carrier reporting service; Li et al. {[li2017_radar]} crowdsourced fake-base-station detection; Tang et al. {[tang2022_clues]} mined tweeted screenshots for 21,918 unique SMS messages in 75 languages, recovering the text with OCR at 90% exact-match accuracy on a 1,000-image sample; Agarwal et al. {[agarwal2024_poster]} built a sector taxonomy from firewall-side data — delivery impersonation was the largest category at 830.2k recipients — and {[agarwal2025_fishing]} pushed the forum approach to five sources — 220,585 posts and 64,284 image attachments, from which an LLM extracted 27,718 unique messages, 19,314 sender IDs and 20,060 URLs, in that paper across 66 languages. **The screenshot is the data format in this slice**, so budget for OCR or a vision model. |
| * **Carrier and aggregator vantage points see what nothing else does.** Jiang et al. {[jiang2013_greystar]} found over 34K spam numbers in five months from grey-number traffic with a 1.2-hour median detection time; Huh et al. {[huh2025_preventing]} measured SMS pumping at an aggregator. Both are unreproducible without the partner, and both say so. | * **Carrier and aggregator vantage points see what nothing else does.** Jiang et al. {[jiang2013_greystar]} found over 34K spam numbers in five months from grey-number traffic with a 1.2-hour median detection time; Huh et al. {[huh2025_preventing]} measured SMS pumping at an aggregator. Both are unreproducible without the partner, and both say so. |
| * **The delivery path is itself measurable and leaky.** Bitsikas et al. {[bitsikas2023_freaky]} inferred receiver location from SMS delivery-report timing at up to 96% accuracy across countries; Schnitzler et al. {[schnitzler2023_hope]} did the messenger equivalent with delivery receipts, over 80% for three locations inside one city. Reaves et al. {[reaves2016_sending]} used public SMS gateways as a vantage point onto the whole ecosystem — 386,327 messages over 14 months, including 522 that contained email addresses. Mulliner et al. {[mulliner2011_death]} delivered malformed SMS to real handsets and found faults in feature phones from six manufacturers, two of which could not be restored afterwards; Tu et al. {[tu2016_security]} and Lei et al. {[lei2021_insecurity]} measured the path and the handset; Wang et al. {[wang2026_sipconfusion]} found caller-ID and SMS spoofing through SIP ambiguity in 47 of 54 server–user-agent combinations. | * **The delivery path is itself measurable and leaky.** Bitsikas et al. {[bitsikas2023_freaky]} inferred receiver location from SMS delivery-report timing at up to 96% accuracy across countries; Schnitzler et al. {[schnitzler2023_hope]} did the messenger equivalent with delivery receipts, over 80% for three locations inside one city. Reaves et al. {[reaves2016_sending]} used public SMS gateways as a vantage point onto the whole ecosystem — 386,327 messages over 14 months, including 522 that contained email addresses. Mulliner et al. {[mulliner2011_death]} delivered malformed SMS to real handsets and found faults in feature phones from six manufacturers, two of which could not be restored afterwards; Tu et al. {[tu2016_security]} and Lei et al. {[lei2021_insecurity]} measured the path and the handset; Wang et al. {[wang2026_sipconfusion]} found caller-ID and SMS spoofing through SIP ambiguity in 47 of 54 server–user-agent combinations. |
| * **Injection at the radio layer is a Chinese-market phenomenon with real numbers.** Zhang et al. {[zhang2020_lies]} characterised fake-base-station SMS spam: 279,017 message logs over 97 days, 7,884 campaigns, and illegal businesses accounting for over 75% of the messages. | * **Injection at the radio layer is a Chinese-market phenomenon with real numbers.** Zhang et al. {[zhang2020_lies]} characterised fake-base-station SMS spam: 279,017 message logs over 97 days, 7,884 campaigns, and illegal businesses accounting for over 75% of the messages. |
| * **Messaging apps.** Edu et al. {[edu2022_exploring]} measured third-party chatbots in messaging channels — 8,521 of 15,525 valid chatbots (54.86%) requested administrator permissions and 95.67% had no privacy policy. Kirchner et al. {[kirchner2024_black]} is the honey-message study. Together they are the reason "email tracking" is the wrong frame for the next study in this area. | * **Messaging apps.** Edu et al. {[edu2022_exploring]} measured third-party chatbots in messaging channels — 8,521 of 15,525 valid chatbots (54.86%) requested administrator permissions and 95.67% had no privacy policy. Kirchner et al. {[kirchner2024_black]} is the honey-message study. Together they are the reason "email tracking" is the wrong frame for the next study in this area. |
| * **User-facing work exists and is small.** Sherman et al. {[sherman2020_going]} measured responses to anti-robocall indicators (answered calls fell 43% with an "Avail-Spam" warning); Sharevski and Zettlemoyer {[sharevski2025_blind]} did aural scam warnings with blind participants; Agarwal et al. {[agarwal2025_dropped]} characterised UK "Hi Mum" impersonation scams — 582 mule accounts, over £577k requested in 13 weeks, and a 14-day median lifetime for the originating sender IDs. | * **User-facing work exists and is small.** Sherman et al. {[sherman2020_going]} measured responses to anti-robocall indicators (answered calls fell 43% with an "Avail-Spam" warning); Sharevski et al. {[sharevski2025_blind]} did aural scam warnings with blind participants; Agarwal et al. {[agarwal2025_dropped]} characterised UK "Hi Mum" impersonation scams — 582 mule accounts, over £577k requested in 13 weeks, and a 14-day median lifetime for the originating sender IDs. |
| |
| ===== The Mailbox as an Instrument ===== | ===== The Mailbox as an Instrument ===== |
| ===== Ethics ===== | ===== Ethics ===== |
| |
| This topic has an unusual concentration of ethics problems, and the corpus reflects it: **14 of the 70 on-page papers assess compliance with a law (20.0%), against 402 of 5,859 (6.9%) corpus-wide** — GDPR in 9 of the 14, then the ePrivacy Directive in 2, and one each of the TRACED Act, the CCPA, the Digital Markets Act, the Gramm-Leach-Bliley Act, HIPAA, Chinese law, German competition law, the German UWG and TMG, US federal law, and "the law of the state where the honeypot is operated". Read the relevant papers' ethics sections rather than this list, and see [[Practices:Ethics]] for the general apparatus. The specific problems: | Papers on this topic engage with law about three times as often as the corpus average: **14 of the 70 assess compliance with a law (20.0%), against 402 of 5,859 (6.9%) corpus-wide** — GDPR in 9 of the 14, then the ePrivacy Directive in 2, and one each of the TRACED Act, the CCPA, the Digital Markets Act, the Gramm-Leach-Bliley Act, HIPAA, Chinese law, German competition law, the German UWG and TMG, US federal law, and "the law of the state where the honeypot is operated". That is a fact about legal engagement, not proof that the ethics here are handled well — the reporting figures at the bottom of this list say otherwise. Read the relevant papers' ethics sections rather than this list, and see [[Practices:Ethics]] for the general apparatus. What is specific to this topic: |
| |
| * **You are creating accounts under identities that are not yours** in order to subscribe. Say so, say how many, and say what you did with the accounts afterwards. | * **You are creating accounts under identities that are not yours** in order to subscribe. Say so, say how many, and say what you did with the accounts afterwards. |
| No field in the extraction means "the measured object is a message". ''classification.target'' does have an ''email-message'' value, and it is **noisy in a way an enum disguises**: it fires on 54 papers, of which 12 are outside this page's candidate pool entirely and include //The Matter of Heartbleed//, //The State of the SameSite// and //Traveling the Silk Road//. So the population here is a published candidate pool plus an explicit verdict per paper. | No field in the extraction means "the measured object is a message". ''classification.target'' does have an ''email-message'' value, and it is **noisy in a way an enum disguises**: it fires on 54 papers, of which 12 are outside this page's candidate pool entirely and include //The Matter of Heartbleed//, //The State of the SameSite// and //Traveling the Silk Road//. So the population here is a published candidate pool plus an explicit verdict per paper. |
| |
| The pool is a union of three signals — the title names a message channel; the full text is dense in message-channel vocabulary; the full text names a messaging-app address space ("contact discovery", "address book"). It contains **354** papers, **183** of which carry a hand-written verdict, and **70** of which are on this page. | The pool is a union of three signals — the title names a message channel; the full text is dense in message-channel vocabulary; the full text names a messaging-app address space ("contact discovery", "address book"). It contains **354** papers. **183** carry a hand-written verdict; of those, **125** also carry a written reason, and the rest are the phishing, social-spam and web-pixel rows where the verdict //is// the reason. The other **171** are ''OFF'' by default: **46** matched a named off-topic family rule, and **125** carry only "not individually annotated" — they were screened at title level and nothing further was recorded about them. **70** are on this page. Do not read the 181-paper ''OFF'' row below as 181 individual judgements; it is 10 of them plus 171 title-level screens. |
| |
| ^ Verdict ^ Papers ^ Where it goes ^ | ^ Verdict ^ Papers ^ Where it goes ^ |
| ==== Where the papers are ==== | ==== Where the papers are ==== |
| |
| Of the 70: USENIX Security 19, NDSS 13, PoPETs 11, IEEE S&P 9, IMC 8, CCS 7, TheWebConf 3. **28 ran an automated web crawl** and 26 have a recorded crawl configuration; ''other-online-service'' is the platform for 54 of them and ''web'' for 32. Twelve recruited human participants. | Of the 70: USENIX Security 19, NDSS 13, PoPETs 11, IEEE S&P 9, IMC 8, CCS 7, TheWebConf 3. **29 ran an automated web crawl** and 27 have a recorded crawl configuration; ''other-online-service'' is the platform for 54 of them and ''web'' for 33. Twelve recruited human participants, and ''manual-audit'' is the most common study type at 42 of 70. |
| |
| Per year and slice. **2025 is thin at the edges and 2026 is provisional** — treat the last two columns as a lower bound, not a trend: | Per year and slice. **2025 is thin at the edges and 2026 is provisional** — treat the last two columns as a lower bound, not a trend: |
| | curated-database | 12 | 19.7% | 29.2% | 13.5% | | | curated-database | 12 | 19.7% | 29.2% | 13.5% | |
| | regex-or-signature | 12 | 19.7% | 16.7% | 21.6% | | | regex-or-signature | 12 | 19.7% | 16.7% | 21.6% | |
| | | other | 7 | 11.5% | 12.5% | 10.8% | |
| | unsupervised-ml | 5 | 8.2% | 8.3% | 8.1% | | | unsupervised-ml | 5 | 8.2% | 8.3% | 8.1% | |
| | blocklist | 4 | 6.6% | 8.3% | 5.4% | | | blocklist | 4 | 6.6% | 8.3% | 5.4% | |
| | | dynamic-analysis | 3 | 4.9% | 4.2% | 5.4% | |
| | | graph-analysis | 2 | 3.3% | 0.0% | 5.4% | |
| | | static-analysis | 2 | 3.3% | 0.0% | 5.4% | |
| | llm | 2 | 3.3% | 0.0% | 5.4% | | | llm | 2 | 3.3% | 0.0% | 5.4% | |
| | |
| | All thirteen values the enum takes on this population are listed; nothing is truncated. |
| |
| Two things to take from this. **Hand labelling went up, not down** — 25.0% to 45.9% — which is what you would expect of a topic whose data is increasingly screenshots and transcripts in many languages. And **''llm'' is 2 papers, both 2025**, so anyone claiming LLM classification is the current practice here is claiming it from two data points in the corpus's thinnest years. | Two things to take from this. **Hand labelling went up, not down** — 25.0% to 45.9% — which is what you would expect of a topic whose data is increasingly screenshots and transcripts in many languages. And **''llm'' is 2 papers, both 2025**, so anyone claiming LLM classification is the current practice here is claiming it from two data points in the corpus's thinnest years. |
| ''tools[].name'' is free text and agrees with an independent extraction run on roughly 20% of exact strings, so it is folded into families tagged by the question the instrument answers. Denominator: the 70 on-page papers. | ''tools[].name'' is free text and agrees with an independent extraction run on roughly 20% of exact strings, so it is folded into families tagged by the question the instrument answers. Denominator: the 70 on-page papers. |
| |
| ^ Instrument family ^ Papers ^ Share of 70 ^ Distinct strings ^ | ^ Instrument family ^ Papers ^ Share of 70 ^ Distinct strings ^ What it answers ^ |
| | browser-automation | 18 | 25.7% | 18 | | | browser-automation | 18 | 25.7% | 18 | driving a browser or app | |
| | network-intelligence | 16 | 22.9% | 19 | | | network-intelligence | 16 | 22.9% | 19 | geolocating or attributing an address ([[design:ip_classification]]) | |
| | ml-model | 16 | 22.9% | 32 | | | ml-model | 16 | 22.9% | 32 | a classifier or clustering algorithm | |
| | telephony-rig | 13 | 18.6% | 21 | | | telephony-rig | 13 | 18.6% | 21 | placing, receiving or fingerprinting calls and SMS | |
| | browser | 13 | 18.6% | 11 | | | browser | 13 | 18.6% | 11 | the browser itself | |
| | maliciousness-oracle | 13 | 18.6% | 13 | | | maliciousness-oracle | 13 | 18.6% | 13 | a maliciousness verdict from a vendor | |
| | mail-plumbing | 7 | 10.0% | 16 | | | study-apparatus | 9 | 12.9% | 10 | recruiting participants or analysing their answers | |
| | language-tooling | 7 | 10.0% | 4 | | | mail-plumbing | 7 | 10.0% | 16 | sending, receiving or parsing mail | |
| | spam-blocklist | 6 | 8.6% | 7 | | | language-tooling | 7 | 10.0% | 4 | translating non-English text ([[programming:multilingual_support]]) | |
| | mail-filter | 6 | 8.6% | 5 | | | spam-blocklist | 6 | 8.6% | 7 | a spam or abuse blocklist as ground truth | |
| | mail-endpoint | 5 | 7.1% | 8 | | | mail-filter | 6 | 8.6% | 5 | a spam filter run by the authors as a labeller | |
| | number-parsing | 5 | 7.1% | 5 | | | traffic-capture | 6 | 8.6% | 8 | recording traffic ([[programming:traffic_files]]) | |
| | llm-or-weak-supervision | 5 | 7.1% | 11 | | | mail-endpoint | 5 | 7.1% | 8 | a mailbox, provider or mail-specific detector as the measurement point | |
| | messenger-client | 4 | 5.7% | 6 | | | number-parsing | 5 | 7.1% | 5 | parsing and validating phone numbers | |
| | audio-pipeline | 4 | 5.7% | 7 | | | llm-or-weak-supervision | 5 | 7.1% | 11 | an LLM or a weak-supervision labeller | |
| | | crawler-framework | 4 | 5.7% | 4 | a web-measurement framework ([[programming:crawler]]) | |
| | | tracker-blocklist | 4 | 5.7% | 7 | a tracking blocklist ([[programming:filter_lists]]) | |
| | | audio-pipeline | 4 | 5.7% | 7 | turning call audio into text or fingerprints | |
| | | messenger-client | 4 | 5.7% | 6 | driving a messaging app programmatically | |
| | |
| | All nineteen families the fold produces on this population are listed; nothing is truncated. Only four of them are mail- or message-specific — the rest is the ordinary apparatus of a web or mobile measurement, which is the point: **there is no toolchain for this topic.** |
| | |
| | **Four tools in this whole population are mail- or message-specific**, and they are the most directly reusable thing on this page: the **Email Privacy Tester** (''emailprivacytester.com'', alive as of 2026-09-02 — sends a message to you and reports which tracking techniques your client executed), **EmailHarvester**, the **Honey Messages Framework** from {[kirchner2024_black]}, and **css-inline** (needed because mail clients want inlined CSS, which is also why {[trampert2025_cascading]} works). Everything else in the table is the ordinary apparatus of a web or mobile measurement. Alongside them, the residue contains ''Faker'', ''Fake Name Generator'', ''This person does not exist'', ''2Captcha'' and ''DeCaptcher'' — which is what signing up on fifteen thousand sites actually requires, and worth budgeting for. |
| |
| The fold is not cosmetic. **Spamhaus appears under four spellings** on this small a population (''Spamhaus'', ''Spamhaus blacklist'', ''Spamhaus.org'', ''Spamhaus passive DNS API''), **libphonenumber under four**, and MaxMind under four. Counting exact strings would have put every one of them below the reporting threshold. **159 distinct strings** matched no family and are printed in full on the provenance page rather than dropped; they are almost all one-off infrastructure (''Faker'', ''Fake Name Generator'', ''2Captcha'', ''DeCaptcher'' — which between them tell you something about what subscribing to 12,618 mailing lists {[englehardt2018_email]} actually involves). | The fold is not cosmetic. **Spamhaus appears under four spellings** on this small a population (''Spamhaus'', ''Spamhaus blacklist'', ''Spamhaus.org'', ''Spamhaus passive DNS API''), **libphonenumber under four**, and MaxMind under four. Counting exact strings would have put every one of them below the reporting threshold. **159 distinct strings** matched no family and are printed in full on the provenance page rather than dropped; they are almost all one-off infrastructure (''Faker'', ''Fake Name Generator'', ''2Captcha'', ''DeCaptcher'' — which between them tell you something about what signing up on 15,700 sites {[englehardt2018_email]} actually involves). |
| |
| ==== Where these papers go quiet ==== | ==== Where these papers go quiet ==== |
| Both columns are computed by the same script with the same rule: the denominator is papers for which the field's family //fired//, and a paper whose ''artifacts'' object is ''null'' is excluded rather than counted as silent. [[literature:corpus]] and the dataset's own overview use the full empirical population as the artifact denominator and therefore report **56.5%** where this table reports 59.5%; the two are not comparable, and a base-rate column that is not comparable to the column beside it is worse than none. | Both columns are computed by the same script with the same rule: the denominator is papers for which the field's family //fired//, and a paper whose ''artifacts'' object is ''null'' is excluded rather than counted as silent. [[literature:corpus]] and the dataset's own overview use the full empirical population as the artifact denominator and therefore report **56.5%** where this table reports 59.5%; the two are not comparable, and a base-rate column that is not comparable to the column beside it is worse than none. |
| |
| One row is genuinely worse than the field: **inter-annotator agreement, at 4 of 51 papers that coded data by hand, against 15.4% corpus-wide.** On a topic where the unit of analysis is often a message that a human read and judged — is this marketing or servicing mail, is this scam or legitimate SMS, what sector is this smishing campaign — that is the reporting gap to fix in your own paper. Of the crawling subset, only **13 of 26** with a recorded crawl configuration state a consent action and **7 of 26** state whether the crawl was stateful; both matter here, because a registration form behind a consent banner is a form you may not have filled in. | One row is genuinely worse than the field: **inter-annotator agreement, at 4 of 51 papers that coded data by hand, against 15.4% corpus-wide.** On a topic where the unit of analysis is often a message that a human read and judged — is this marketing or servicing mail, is this scam or legitimate SMS, what sector is this smishing campaign — that is the reporting gap to fix in your own paper. Of the crawling subset, only **14 of 27** with a recorded crawl configuration state a consent action, **7 of 27** state whether the crawl was stateful and **5 of 27** state headless or headful; both of the first two matter here, because a registration form behind a consent banner is a form you may not have filled in. |
| |
| ==== Methodology and limitations of these figures ==== | ==== Methodology and limitations of these figures ==== |
| * **A paper counts once**, never once per tuple. Shares do not sum to 100%. | * **A paper counts once**, never once per tuple. Shares do not sum to 100%. |
| * **Sentinels are never counted as answers.** The zero in the unsubscription row is a measured zero, not a missing value. | * **Sentinels are never counted as answers.** The zero in the unsubscription row is a measured zero, not a missing value. |
| * **Every per-paper figure was checked against the paper, not against the extraction.** 60 figures across 22 papers, all present. That pass earned its keep twice: the smishing paper's figures are typeset with the mathematical-italic //k// rather than an ASCII ''k'', so an obvious needle reported a real figure as missing; and the extraction's summary of Venkatadri et al. {[venkatadri2018_privacy]} reads "18 of 20 visitors inferred", where the paper says "18 of the volunteers who did visit the webpage" out of 20 — correct, but a paraphrase, and this page quotes the paper. | * **Every per-paper figure was checked against the paper, not against the extraction.** 78 figures across 24 papers, all present. That pass earned its keep twice: the smishing paper's figures are typeset with the mathematical-italic //k// rather than an ASCII ''k'', so an obvious needle reported a real figure as missing; and the extraction's summary of Venkatadri et al. {[venkatadri2018_privacy]} reads "18 of 20 visitors inferred", where the paper says "18 of the volunteers who did visit the webpage" out of 20 — correct, but a paraphrase, and this page quotes the paper. |
| * **Quotes.** 400 ''detection'' evidence quotes attach to the 70 papers: 220 located verbatim, 118 after whitespace and punctuation normalisation, 62 below the matching threshold. Below-threshold is **not** "unsupported" — every one sampled by hand was present, spliced by two-column reading order. All 62 are listed on the provenance page. | * **Quotes.** 400 ''detection'' evidence quotes attach to the 70 papers: 220 located verbatim, 118 after whitespace and punctuation normalisation, 62 below the matching threshold. Below-threshold is **not** "unsupported". **Ten** were read by hand and all ten were present, spliced by two-column reading order — the eight in the 40–60% band that the provenance page tabulates, plus the two lowest-coverage ones (23% and 20%) read afterwards because a rule inferred from the middle of a distribution is not a rule about its tail. All 62 are listed on the provenance page. |
| * **Recall.** Four schema-side probes that were //not// used to build the pool were run against it afterwards. They surfaced 73 papers outside it; all were read at title level, the twelve from the ''email-message'' enum were opened, and exactly **one** was a genuine miss — Starov et al. {[starov2016_sure]}, now the oldest paper in the address-as-identifier slice. Read that as the measured cost of a title-and-density pool: about one paper in seventy, in the direction of missing the oldest work in a slice. | * **Recall.** Four schema-side probes that were //not// used to build the pool were run against it afterwards. Between them they produced **72** outside-the-pool mentions, which are **67 distinct papers** (five appear on more than one probe's list, so the four columns double-count). All 67 were read at title level, the twelve from the ''email-message'' enum were opened, and exactly **one** was a genuine miss — Starov et al. {[starov2016_sure]}, now the oldest paper in the address-as-identifier slice. Read that as the measured cost of a title-and-density pool: one miss in 67 papers re-screened, in the direction of missing the oldest work in a slice. |
| * **Venue coverage.** Seven venues. EuroS&P, ACSAC, RAID, AsiaCCS, WPES, CHI and SOUPS are absent, and so is the CEAS/anti-spam literature entirely — for a topic with this much of its history in dedicated anti-spam and telephony venues, every count here is a **lower bound and a weaker one than on most pages of this wiki**. | * **Venue coverage.** Seven venues. EuroS&P, ACSAC, RAID, AsiaCCS, WPES, CHI and SOUPS are absent, and so is the CEAS/anti-spam literature entirely — for a topic with this much of its history in dedicated anti-spam and telephony venues, every count here is a **lower bound and a weaker one than on most pages of this wiki**. |
| * **Stability.** ''classification.method'' agrees with an independent extraction run on 58% of papers and free-text names on about 20% of exact strings, which is why methods are given as rankings and enum fields as percentages. Those figures were measured on the previous, 4,322-paper run and have not been re-measured. | * **Stability.** ''classification.method'' agrees with an independent extraction run on 58% of papers and free-text names on about 20% of exact strings, which is why methods are given as rankings and enum fields as percentages. Those figures were measured on the previous, 4,322-paper run and have not been re-measured. |
| - **The ethics of the address**: whose mail you read, whose number you enumerated, what you did with the accounts afterwards, and which law you assessed yourself against. | - **The ethics of the address**: whose mail you read, whose number you enumerated, what you did with the accounts afterwards, and which law you assessed yourself against. |
| - **For SMS and calls: the number block and its age.** Older blocks receive more traffic {[gupta2015_phoneypot]}, so an unqualified rate is not comparable. | - **For SMS and calls: the number block and its age.** Older blocks receive more traffic {[gupta2015_phoneypot]}, so an unqualified rate is not comparable. |
| - **For crowdsourced message data: the forums, the dates, and the overlap.** Three of the recent smishing and SMS-spam papers draw on partly overlapping public sources and none of them quantifies the overlap. | - **For crowdsourced message data: the sources, the dates, and the overlap.** {[tang2022_clues]} and {[agarwal2025_fishing]} both mine Twitter for reported SMS spam, three years apart, and neither says how much of the other's data it would have seen. Name your sources and their date ranges so the next paper can. |
| |
| ===== Open Questions ===== | ===== Open Questions ===== |
| * **No published measurement of one-click unsubscribe.** Zero papers in these seven venues; a specific, dated, testable requirement in force since 1 February 2024. This is the largest hole on the page. See [[#Unsubscription: A Measured Gap]] before starting, and note that work is under way. | * **No published measurement of one-click unsubscribe.** Zero papers in these seven venues; a specific, dated, testable requirement in force since 1 February 2024. This is the largest hole on the page. See [[#Unsubscription: A Measured Gap]] before starting, and note that work is under way. |
| * **No paper measures a tracking-pixel prevalence per mail client.** Gmail's proxy and Apple's Mail Privacy Protection change what the sender learns, in different ways, and every email-tracking figure in this corpus predates the question. | * **No paper measures a tracking-pixel prevalence per mail client.** Gmail's proxy and Apple's Mail Privacy Protection change what the sender learns, in different ways, and every email-tracking figure in this corpus predates the question. |
| * **No successor to Englehardt et al. {[englehardt2018_email]} at comparable scale.** The 2018 crawl of 12,618 mailing lists is still the reference figure for third-party content in mail, eight years on, and it predates both MPP and the 2024 bulk-sender rules. | * **No successor to Englehardt et al. {[englehardt2018_email]} at comparable scale.** Its 12,618 emails from 902 senders are still the reference figures for third-party content in mail, eight years on, and they predate both Mail Privacy Protection and the 2024 bulk-sender rules. |
| * **The lead-marketing pipeline is unjoined in the extraction.** Who collects the address, who brokers it, and what arrives are three separate literatures here. The IEEE S&P 2026 paper that joins them is missing from this corpus by construction (see [[#What the corpus cannot tell you]]) — read it before you propose the study. | * **The lead-marketing pipeline is unjoined in the extraction.** Who collects the address, who brokers it, and what arrives are three separate literatures here. The IEEE S&P 2026 paper that joins them is missing from this corpus by construction (see [[#What the corpus cannot tell you]]) — read it before you propose the study. |
| * **Feed and forum bias in message corpora has not been re-measured since 2012.** {[pitsillidis2012_taster]} did it for spam feeds. The public smishing forums that four recent papers rely on have never been compared to each other. | * **Two 2026 preprints are about to land on this page's gaps and are not published yet.** Agarwal, Suarez-Tangil and Vasek, "An Overview of 7726 User Reports" (arXiv:2508.05276), works from 1.35 million operator-side SMS reports; Altwlkany et al., "Robocalls: A Worldwide or US-only Problem?" (arXiv:2606.31790), from 8.7 million international call records across 65 countries. Neither is peer-reviewed at a venue as of 2026-09-02, so the zero counts on this page still stand. They are aimed at two things this corpus does not have: the cross-source bias question in the next bullet, and international coverage of robocalls, which nothing in these seven venues addresses at all.((Both checked on arXiv 2026-09-02. Cited as preprints, not as results, and deliberately not used for any figure on this page.)) |
| | * **Source bias in message corpora has not been re-measured since 2012.** {[pitsillidis2012_taster]} did it for spam feeds and found 60% of live domains exclusive to a single feed. Nobody has repeated it on any channel. The two recent papers that mine Twitter for reported SMS spam — {[tang2022_clues]} and {[agarwal2025_fishing]} — are the obvious pair to compare, and neither reports the overlap with the other; nor has anyone compared a crowdsourced source against a carrier-side one ({[murynets2012_crime]}, {[huh2025_preventing]}) on the same period. |
| * **Nobody has measured the messaging-app channel at email's scale.** {[kirchner2024_black]} covers 105 platforms with honey messages; there is no equivalent of the newsletter-subscription crawl for chat, and no prevalence figure for tracking in machine-generated chat messages. | * **Nobody has measured the messaging-app channel at email's scale.** {[kirchner2024_black]} covers 105 platforms with honey messages; there is no equivalent of the newsletter-subscription crawl for chat, and no prevalence figure for tracking in machine-generated chat messages. |
| * **Inter-annotator agreement is essentially unreported in this slice** (4 of 51). Since the field is moving toward LLM-assisted labelling of message content {[hao2025_spammers]} {[agarwal2025_fishing]}, the human baseline it would be validated against does not exist. | * **Inter-annotator agreement is essentially unreported in this slice** (4 of 51). Since the field is moving toward LLM-assisted labelling of message content {[hao2025_spammers]} {[agarwal2025_fishing]}, the human baseline it would be validated against does not exist. |
