IEEE Study: 44K Emails Show Pixel Blockers Easily Evaded

Every email privacy guide ends with the same two sentence shrug: "use a tracker blocker, or use Proton." A new IEEE Access paper just measured how far that advice actually goes. The researchers behind "Hard to See, Harder to Block: Exploring the Challenges in Email Tracking Pixels Detection" assembled a dataset of more than 44,000 real world emails, ran every common detection method against it, and signed up to 22 popular commercial tracking services to test how the trackers themselves respond to evasion pressure. The headline finding is uncomfortable: tracker detection is not a solved problem, the gap between detection methods is enormous, and the simplest evasions, like resizing a 1x1 pixel to 2x2, are enough to slip past every detector tested.

Key Takeaways

• "Hard to See, Harder to Block" was accepted into IEEE Access in 2026 and is the largest empirical study of email tracking pixel detection published to date.
• The authors evaluated a corpus of more than 44,000 real world emails using every commonly cited detection heuristic, including dimension based, URL pattern based, blocklist based, and feature based machine learning approaches.
• The proportion of emails flagged as containing tracking pixels swung by more than 25 percentage points depending on which detection method was used. There is no consensus on what counts as a tracker.
• The authors signed up to 22 popular commercial tracking services and confirmed that small changes, like modifying image dimensions, changing URL paths, or obfuscating identifiers, are often sufficient to evade existing detectors entirely.
• Gmail Web, Yahoo Mail, and Outlook Web blocked zero of the 22 services tested out of the box. Proton Mail Web blocked all 22 by default.

What Did the Researchers Actually Measure?

"Hard to See, Harder to Block" is a measurement paper, not a tool paper. The authors did not build a new blocker; they built a benchmark. Their corpus of 44,000 emails covers marketing newsletters, transactional notifications, individual person to person exchanges, and a sample of business email. Each message in the corpus was passed through five families of tracking pixel detection:

• Dimension based heuristics. Flag any <img> tag with width and height under a small threshold (the classic "1x1 transparent gif" rule).
• URL pattern heuristics. Flag image URLs containing tracking specific path segments like /open.gif, /track, or query strings carrying base64 identifiers.
• Blocklist matching. Flag image URLs whose host matches one of the public tracker blocklists like EasyPrivacy, Disconnect, or DuckDuckGo Tracker Radar.
• Feature based machine learning. Train a classifier on URL, MIME, and DOM features and let it decide.
• Behavioral sandboxing. Render the message in an isolated mail client and watch for outgoing requests on open.

The percentage of emails flagged as tracking varied wildly across methods. Dimension based detection caught fewer than half the trackers that blocklist based detection caught. Blocklist based detection missed many of the trackers that behavioral sandboxing caught. None of the methods agreed on the same set of "tracking emails." The headline number from the paper is that the gap between the strictest and loosest detection method exceeded 25 percentage points on the same corpus. There is no objective ground truth on what counts as a tracker until you watch the network.

How Easily Do the Trackers Evade Detection?

The most damaging part of the paper is the active evasion section. The authors signed up to 22 popular commercial tracking services, including the ones bundled with mainstream email marketing platforms and CRMs, and sent themselves emails through each service. They then asked what small changes were enough to slip past the detection methods that did work.

The answer was depressingly easy:

• Changing the image dimensions from 1x1 to anywhere between 2x2 and 5x5 invalidates dimension based detection because the image is no longer "obviously" a pixel. The visible result in a normal email client is identical.
• Changing the URL path from /open.gif to /logo.png or to a randomized hash path invalidates URL pattern detection. The image still loads, the open event still fires, the recipient sees nothing different.
• Rotating tracker host names across many short lived subdomains, sometimes per recipient, defeats blocklist matching by definition. Blocklists update on a schedule; per recipient subdomains do not.
• Encoding the recipient identifier in the URL query string with rotating base prefixes, then changing the prefixes weekly, makes pattern matching brittle.

None of these are sophisticated techniques. Several are already in production at large email marketing services. The paper's framing is direct: existing detection methods do not raise the cost of tracking enough to discourage it.

Which Email Clients Block Trackers by Default?

The paper's client comparison is brutally clear. Of the 22 commercial trackers tested, mainstream webmail providers blocked the following number by default:

• Gmail Web: zero of 22.
• Yahoo Mail: zero of 22.
• Outlook Web: zero of 22.
• Proton Mail Web: 22 of 22.

Gmail's behavior here deserves a separate note. Google does proxy remote images through their googleusercontent.com infrastructure, which obscures the recipient's IP from the tracker server. That is a real privacy improvement against location based fingerprinting. It is not the same as blocking the tracker. The image still loads, the open event still fires, the marketer still gets the read receipt with the timestamp. The Gmail proxy is privacy hygiene, not privacy enforcement.

What This Means for the Average Inbox

If you read your email in Gmail Web, Yahoo Mail, or Outlook Web with no extension installed, you should assume that every marketing email you open today is being tracked, that the tracker knows when you opened it, that the tracker knows roughly where you are, and that the tracker is feeding that information back to the sender in real time. The IEEE paper formalizes what privacy researchers have repeated for years; the value of the formalization is that mainstream email clients can no longer claim that tracking is "rare" or that existing detection is "good enough."

The two viable approaches the paper implicitly endorses are switching to a client that blocks trackers by default (Proton Mail is the only mainstream option with that posture), or installing an extension that does the blocking inside your existing client. For Gmail users who do not want to migrate, Gblock is the latter approach. It runs inside Gmail in the browser, removes tracking pixels from messages before they render, and does so without proxying anything through a third party server. The "Hard to See, Harder to Block" paper is the empirical case for the category; Gblock is one of the implementations.

Why Does Mainstream Detection Stay Bad?

The asymmetry the paper documents is structural. A tracker only needs one detection method to fail; a defender needs every detection method to succeed. The defender publishes their detection rules, in code or in blocklists; the tracker reads those rules and ships a small variation. This is the same asymmetry that has shaped ad blocker, anti virus, and anti phishing arms races for two decades.

What is special about email tracking, and what makes the IEEE result more durable than a typical web tracker measurement, is that the tracker has no DOM to hide in. The pixel must be an <img> tag, the image must load over HTTP, and the image must be served from a remote host. The attack surface is narrow. The paper's conclusion is not that detection is impossible; it is that detection cannot rely on any single heuristic, that it has to combine network behavior with URL structure with rendering context, and that mainstream clients have not made that investment.

For background on how this maps to regulation, the Italy Garante April 2026 ruling required prior consent for open tracking pixels, and the France CNIL recommendation gave email marketers a July deadline to obtain consent. The "Hard to See" paper supplies the technical evidence that opt out alone is meaningless if your client does not block the pixel; consent without enforcement is paperwork.

What Should Privacy Researchers Take From This?

Three things the paper is implicitly asking the research community to do. First, settle on a behavioral ground truth for "this email was tracking me," because the absence of one is why detection methods disagree by 25 percentage points on the same corpus. Second, evaluate detectors against active evasion, not just historical traffic; every detector tested in the paper failed when the tracker shifted strategy. Third, push browser and webmail vendors to bake basic blocking into the client, because extension based blocking only protects users who already knew to install an extension, which is the smallest possible audience.

For practitioners running tracker blocking in production, including everyone who maintains a Gmail extension that strips pixels, the paper's evasion section reads as a research grade list of regressions to watch for. The 1x1 to 2x2 trick is not new, but the paper documents it as still effective. That is the kind of finding a blocker maintainer should be able to ship a fix for within a release cycle, and the IEEE corpus gives them a benchmark to measure against.

Where to Find the Paper

The paper is published in IEEE Access as document 11224376. A copy is also available on ResearchGate. Read it in full if you build, deploy, or audit anything in the tracker blocking space; the 44,000 email corpus is the largest published benchmark for this category, and the evasion findings are reproducible against any current commercial tracker.