Tracking pixels, consent, and the paid inbox
The Introduction cites a report on the French regulator’s tracking-pixel rules — the CNIL’s €325 million fine against Google (September 2025) for advertising inside Gmail without consent, and its proposal that tracking pixels need a consent of their own, separate from the consent to receive the mail. This page takes the article’s problems one at a time and says what SithBit does about each — and, at the end, what it does not.
The problems the article describes
- The pixel itself. A 1×1 transparent image in an HTML mail whose fetch reports your IP address, device, mail client, the time you opened the message and how often you re-open it.
- Who the data feeds. Marketing-automation platforms (open rates), CRM systems (engagement scores), behavioural-profiling databases, and automated follow-ups triggered by an open.
- Bundled consent. Signing up for a newsletter is taken as consent to be tracked; the regulator says the two are separate permissions.
- Withdrawal that has to reach back. Revoking consent must stop the pixel firing even in mail already sent — which a sender cannot technically guarantee once the HTML is in your inbox.
- Ads in the inbox. The provider monetises the mailbox it “gives” you by placing advertising inside it, without asking.
- The user’s only defence is a blocker. Protection is a browser extension the reader installs, working against the mail’s design.
What SithBit does instead
| Article’s problem | SithBit’s answer today |
|---|---|
| The pixel reports opens, IP, device, timing | The webmail reader renders every HTML body inside a sandboxed frame whose Content-Security-Policy is default-src 'none' — no image, style sheet or script is fetched from the network, so a pixel never fires (img-src data: keeps inline images working). See the webmail app. |
| Senders want to know the mail arrived | They already know, without asking your device: a delivered message is a record on the chain, written when your postage is collected. That is a delivery receipt, not an open receipt — the sender learns the message landed, never when or where you read it. |
| Senders want engagement scores | Engagement is something you sell, not something taken: a reply bounty pays you for an answer, and the only signal the sender ever gets is the reply you chose to write. No open rate, no re-open count, no device fingerprint. |
| Bundled consent | The two permissions are two different on-chain objects. Consent to receive mail from someone is the price you set on their frombox; consent to hear from advertisers is a separate, explicit beacon you publish, naming the topics you agreed to — and nothing about ordinary mail changes if you never publish one. |
| Withdrawal must reach back | Closing a beacon removes you from every campaign search immediately and refunds its deposit; raising a sender’s frombox price stops their next message at the chain. Nothing needs to reach back into mail already delivered, because delivered mail carries no live tracker to disable. |
| Ads in the inbox | There are none, because the inbox is not the product. Postage pays for delivery and roughly 90% of it goes to you; the operator earns its share from carrying your mail, not from selling your attention alongside it. |
| Behavioural profiles built from your reading | A beacon exposes only coarse, self-chosen tags; the fuller profile, if you attach one, is encrypted, and an advertiser who wants it has to mail you — paying your price — and ask for the key. |
| The reader’s only defence is a blocker | With Lockbox the body is sealed on the sender’s device and only your key opens it, so no relay or server can read it to build a profile in the first place; the sandboxed reader means you need no blocker to stop the pixel. |
What SithBit does not fix
- Delivery metadata is public. The chain records which wallet mailed which, when, and for how much — permanently. A tracking pixel leaks less to the sender than SithBit publishes to everyone; the difference is that you know exactly what is exposed and it never includes your IP, device, or reading habits. What’s public and private spells it out.
- The extensions render in the host application. The Thunderbird and Outlook plugins add Lockbox and account management; whether remote images load in the message view is the host client’s own setting. Turn remote content off there — both clients default to blocking it.
- Mail relayed out to conventional addresses leaves the protocol at the SMTP boundary and inherits the recipient’s provider, pixels and all.
- Do-not-disturb refuses mail at SMTP time rather than reporting your schedule, and only shows away windows to senders when you opt in — but a refusal is itself a signal that the address is live. See Do not disturb.
Further reading
- Trust assumptions and threat model
- What’s public and private: the field reference
- Campaigns — the advertiser’s side of the same consent model