<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR
<ul>
<li>Goal: Respect over retargeting. Default to data minimization - collect only what’s needed to serve the visitor.</li>
<li>What’s new:&nbsp;<a href="https://aesirx.io/blog/press-release/aesirx-cmp-for-wordpress-v2-0-2-stop-the-phone-home-permanently" target="_blank" rel="noopener">“Permanent Block” in AesirX CMP v2.0.2</a> lets you stop non-essential third-party collection forever.</li>
<li>Why it matters: Fewer silent “phone-home” calls, less profiling, simpler audits, lower vendor risk.</li>
<li>How to use: In Privacy Shield, set non-essential plugins or domains/paths (e.g., telemetry, old pixels) to Block permanently, then verify with privacyscanner.aesirx.io.</li>
</ul>
Promise: If it isn’t essential to serve your visitor, it never loads.
</div>
There’s a quiet moment that happens on most websites long before a person clicks “Accept.”
A script phones home.
A pixel wakes up.
A background request ships a tiny slice of your visitor - where they came from, what device they’re on, often enough to stitch a profile together somewhere far away.
That’s not respect. It’s not necessary. And starting today, it’s not inevitable.
With AesirX CMP for WordPress v2.0.2, we’re introducing “<a href="https://aesirx.io/blog/press-release/aesirx-cmp-for-wordpress-v2-0-2-stop-the-phone-home-permanently" target="_blank" rel="noopener">Permanent Block</a>” - a simple control with a clear ethic: if a third party isn’t essential to serving your visitor, it never loads. Not “until consent.” Not “once they click the big green button.” Never.
<h2>The problem isn’t just consent. It’s excess.</h2>
Consent banners were meant to restore agency. But banners alone can’t fix a culture of collect first, justify later. Too many extensions still export data by default: telemetry “for product improvement,” convenience SDKs that quietly create identifiers, embeds that pull in trackers the moment the page renders.
The ethic we believe in is simpler - and older than any framework: collect less. Gather only what’s needed to provide the thing a person asked for. Keep it close. Make “no unnecessary third parties” your default, not your exception.
“Permanent Block” operationalizes that ethic in your stack. It’s a switch that says, “This integration is not essential, and it does not get to take anything from my users.”
<h2>What “Permanent Block” actually does</h2>
Inside Privacy Shield, every listed plugin and every Domain/Path rule now has two behaviors:
<ul>
<li aria-level="1">Block until consent (default): Don’t load until the user opts into that category.</li>
<li aria-level="1">Block permanently (new): Never load - regardless of consent choices elsewhere.</li>
</ul>
<a href="https://github.com/aesirxio/wordpress-consent-plugin/releases/tag/2.0.2" target="_blank" rel="noopener">Choose Permanent and AesirX CMP</a> prevents that target from running at all. We intercept script tags, iframes, pixels, beacons, and network requests aimed at the domains/paths you specify. The result is straightforward: if you mark it permanent, <a href="https://aesirx.io/blog/press-release/aesirx-cmp-for-wordpress-v2-0-2-stop-the-phone-home-permanently" target="_blank" rel="noopener">no data leaves the browser for that destination</a>.
This isn’t about breaking your site; it’s about drawing a line around what’s truly required. Your store should run; your content should load; your security and accessibility should work. But exporters that aren’t essential? They’re out.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/choose-permanent-block-per-domain-path-new.png" alt="choose permanent block per domain path new" width="1884" height="902" />
Choose “Permanent Block” per&nbsp; domain/path
<h2>When should you block permanently?</h2>
Use “Permanent Block” when a third party:
<ul>
<li aria-level="1">Exports data that isn’t required to deliver what the user requested (e.g., telemetry collectors or “improve our service” beacons).</li>
<li aria-level="1">Duplicates a capability you already provide on your own systems (so there’s no reason to send data away for it).</li>
<li aria-level="1">Introduces disproportionate risk through cross-site tracking, profiling, or opaque processing chains.</li>
<li aria-level="1">Arrives as a side effect of a convenience feature (for example, certain embeds that set identifiers by default).</li>
</ul>
A few common candidates:
<ul>
<li aria-level="1">Telemetry baked into utilities that don’t need to measure your audience to do their job.</li>
<li aria-level="1">Old pixels and helper libraries left behind after a tooling change.</li>
<li aria-level="1">Media or social embeds that load trackers immediately when a page renders.</li>
</ul>
None of these are required to show a page, run a checkout, protect a login, or fulfill an order. If they don’t serve your visitor’s immediate purpose, mark them permanent and move on.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
<h3>Example: Jetpack “phone-home” and how to stop it</h3>
Jetpack (by Automattic) is bundled by default on WordPress.com-hosted sites, and it’s also widely deployed on self-hosted WordPress (the plugin directory lists 5M+ active installs; including WordPress.com sites, the overall footprint is commonly estimated well into the tens of millions, often cited as 15M+). It provides a lot of features - but several modules also call back to Automattic servers for stats and telemetry.
<h3>What typically leaves the browser</h3>
When Jetpack’s statistics/telemetry features are active, your visitor’s browser can contact endpoints like:
<ul>
<li aria-level="1">stats.wp.com - site stats beacons</li>
<li aria-level="1">pixel.wp.com - tracking pixel requests</li>
<li aria-level="1">public-api.wordpress.com - service/telemetry API calls</li>
<li aria-level="1">(Occasionally) s0.wp.com / i*.wp.com - asset/CDN pulls, depending on modules</li>
</ul>
These requests can occur early in the page lifecycle and may set or transmit identifiers that aren’t strictly necessary to serve the page your visitor asked for.
<h3>How to stop it with “Permanent Block” (1 minute)</h3>
<ol>
<li aria-level="1">WP Admin → AesirX CMP → Consent Shield → Domain/Path Blocking</li>
<li aria-level="1">Add rules for the Jetpack endpoints you don’t need (start with the stats/telemetry pair):
<ul>
<li aria-level="2">stats.wp.com → Block permanently</li>
<li aria-level="2">pixel.wp.com → Block permanently</li>
<li aria-level="2">(Optional, module-dependent) public-api.wordpress.com → Block permanently</li>
</ul>
</li>
<li aria-level="1">Save and reload a page - those calls won’t fire, even after any consent action.</li>
</ol>
Tip: If you rely on specific Jetpack modules (e.g., backups, image CDN), leave those endpoints unblocked or disable only the stats/telemetry domains. “Permanent Block” is granular - use it to silence what’s unnecessary while keeping genuinely required functionality.
<h3>Before vs. After</h3>
<ul>
<li aria-level="1">Before: first pageview → background calls to stats.wp.com / pixel.wp.com transmit event data and identifiers.</li>
<li aria-level="1">After (Permanent): those endpoints never load; no stats/telemetry beacons leave the browser. Your core site, checkout, and login continue to work; your visitors aren’t exported by default.</li>
</ul>
This is data minimization in action: keep what’s essential, drop the rest.
<h3>Verify it with the AesirX Privacy Scanner (free)</h3>
Don’t guess - measure. Before and after you enable Permanent Block, run a quick scan to confirm exactly which third-party calls are leaving the browser.
<ol>
<li aria-level="1">Go to <a href="https://privacyscanner.aesirx.io">Privacy Scanner</a>.</li>
<li aria-level="1">Enter your URL and run a baseline scan (before changes).</li>
<li aria-level="1">In WP Admin → AesirX CMP → Consent Shield, set the Jetpack endpoints (e.g., stats.wp.com, pixel.wp.com) to Block permanently and Save.</li>
<li aria-level="1">Run a post-change scan and compare.</li>
</ol>
What to look for
<ul>
<li aria-level="1">Jetpack telemetry endpoints (e.g., stats.wp.com, pixel.wp.com) should no longer appear in the network findings.</li>
<li aria-level="1">No third-party trackers should fire before consent.</li>
<li aria-level="1">Cookie/Storage findings should show only what’s essential.</li>
</ul>
Tip: Export the scan report and attach it to your internal privacy records. It’s a simple, date-stamped proof of data minimization and enforcement.
</div>
<h2>What this means for your visitors (and for you)</h2>
<h4>For your visitors and customers</h4>
<ul>
<li aria-level="1">Fewer silent connections to companies they don’t know.</li>
<li aria-level="1">Less background profiling and cross-site stitching.</li>
<li aria-level="1">A clearer promise: we only run what helps you right now.</li>
</ul>
<h4>For your organization</h4>
<ul>
<li aria-level="1">Less vendor risk and fewer “unknown unknowns.”</li>
<li aria-level="1">A tighter, easier-to-explain privacy posture.</li>
<li aria-level="1">Cleaner audits: you can show not just what runs, but what doesn’t.</li>
</ul>
The hidden win is cultural. When a team chooses “Permanent Block” for non-essential exports, it nudges every future decision toward respect by default. It’s easier to ask “Is this necessary?” when your tooling makes “No” both possible and normal.
<h2>Turn it on (takes less than a minute)</h2>
<ol>
<li aria-level="1">WordPress Admin → AesirX CMP → <a href="https://aesirx.io/documentation/cmp/how-to/how-to-use-aesirx-consent-management-platform-main-features-guide#title-1" target="_blank" rel="noopener">Consent Shield</a>.</li>
<li aria-level="1">Add a Domain/Path rule (e.g., a telemetry or pixel endpoint).</li>
<li aria-level="1">Check the box “Permanent&nbsp;Block”.</li>
<li aria-level="1">Save. That target won’t run - before or after any consent choice.</li>
</ol>
Tip: Start with the obvious exporters. If you’re unsure whether an integration is essential, treat it like a guest in your users’ house - if it can’t clearly justify why it’s there, it doesn’t come in.
<h2>Why we built it this way</h2>
We could have made yet another toggle in a sea of toggles. Instead, we built a principled stop - a mode that can’t be overruled by a broad “Accept All.” That matters because many sites still initialize stacks too early or in too many places. A permanent rule is simple to reason about and easy to verify: if it’s on the list, it stays off.
And because “Permanent Block” sits in the same Privacy Shield you already use, you get granular control: per plugin, per domain, per path. You decide what’s essential. You decide what never runs.
<h2>A note on responsibility (and restraint)</h2>
“Permanent Block” is powerful. With a couple of clicks, you can silence whole categories of third-party collection. Use that power thoughtfully:
<ul>
<li aria-level="1">Keep what is technically required for security, core functionality, and user-requested features.</li>
<li aria-level="1">Remove what is comfortable but unnecessary - especially anything that ships people’s data off your site without a clear, immediate benefit to them.</li>
<li aria-level="1">Review periodically. As your stack evolves, so should your block list.</li>
</ul>
Respect is not just a feeling; it’s a set of decisions, repeated consistently, visible in the code your site actually runs.
<h2>The web we want</h2>
People shouldn’t have to trade their dignity for a pageview or a purchase. They shouldn’t have to navigate dark patterns to keep their information from becoming someone else’s product roadmap. They shouldn’t be followed simply because a developer forgot to uncheck a box.
“Permanent Block” is our contribution to a saner web: one where websites serve their visitors first, and where “no unnecessary third parties” is a default, not a dream.
If that’s the web you want too, update to AesirX CMP for WordPress v2.0.2, open Privacy Shield, and start marking the noisy stuff Permanent. Your visitors will feel the difference - even if they never know why. And that’s the point.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
<h2>FAQ</h2>
1. Will this break my checkout/login? No. “Permanent Block” is for non-essential third parties (telemetry, pixels, noncritical SDKs). Core, user-requested features (checkout, login, security, accessibility) should remain enabled. Best practice:
<ul>
<li aria-level="1">Test on a staging site first.</li>
<li aria-level="1">Block only the specific domains/paths you don’t need.</li>
<li aria-level="1">Run a quick flow check (login → cart → checkout) after changes.</li>
</ul>
2. What’s the difference vs “Block until consent”?
<ul>
<li aria-level="1">Block until consent: The script/endpoint is paused until the user opts in; if they consent, it can load.</li>
<li aria-level="1">Block permanently: The script/endpoint never loads - even if a user clicks “Accept All.” Use this for exporters that aren’t essential to the service the user asked for.</li>
</ul>
3. How do I review what to block? Use a simple three-step review loop:
<ol>
<li aria-level="1">Inventory: List active third-party scripts and endpoints (plugins, embeds, pixels).</li>
<li aria-level="1">Necessity test: If it doesn’t directly deliver what the user requested, mark it Permanent.</li>
<li aria-level="1">Verify: Scan before/after enabling “Permanent Block” with <a href="https://privacyscanner.aesirx.io" target="_blank" rel="noopener" style="background-color: inherit; font-family: inherit; font-size: 1rem;">AesirX Privacy Scanner</a>. Export reports for records.</li>
</ol>
Tip: Start with obvious exporters (e.g., stats/telemetry endpoints from bundled plugins). Keep technically required services and first-party functionality unblocked.
</div>

Respect Over Retargeting: How “Permanent Block” Ends Unnecessary Third-Party Collection

Blog Aesirx

AesirX CMP v2.0.2 adds Permanent Block - stop non-essential third-party collection for good. Data minimization, respect by default, one-minute setup.

Permanent Data Block Stops Third-Party Tracking and Collection

1. Will this break my checkout/login?

2. What’s the difference vs “Block until consent”?

3. How do I review what to block?

Does this apply to sites outside the EU?

Block Until Consent? Good.
Block Forever? Sometimes Better.
Extensions shouldn’t phone home by default. v2.0.2 lets you say “no” - for good.
Most of us install plugins to solve problems. Fewer of us expect them to quietly call back to third-party servers - counting every page view, fingerprinting devices, or dropping pixels that don’t serve our users. That’s the “phone-home” problem.
The law is clear about the before part: no access to a user’s device without prior, informed consent (ePrivacy Directive 5(3)). But the spirit goes further: collect less. Favor the first-party path. Keep only what you need.
That’s why today we’re releasing Permanent Block. It’s a tiny control with a big message: if a third-party isn’t essential - and if sending data off-site isn’t in your users’ interests - you can stop it completely. Not “until consent.” Not “maybe later.” Completely.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Missed our last update?
Read: <a href="https://aesirx.io/blog/press-release/aesirx-cmp-for-wordpress-v2-0-1-new-cryptox-wallet" target="_blank" rel="noopener">AesirX CMP for WordPress v2.0.1: New CryptoX Wallet on iOS and Android for Age and Country Verification</a>
</div>
<h2>What’s New in CMP v2.0.2?</h2>
<h3>Permanent Block in Privacy Shield</h3>
Until now, Consent Shield let you block third-party scripts “until consent.” That remains the default. But sometimes, “never” is the right answer. Permanent Block allows you to mark specific plugins, domains, or path rules so they will never load – even if a user clicks “Accept All.”
<h3>How it works:</h3>
<ul>
<li aria-level="1">In Consent Shield, select a plugin or add a domain/path rule.</li>
<li aria-level="1">Choose Block permanently.</li>
<li aria-level="1">Save your setting. From that moment, the target never loads.</li>
<li aria-level="1">Optional: Run a post-consent scan to confirm no data leaks remain.</li>
</ul>
It’s simpe, deliberate, and logged with clear UI badges, confirmation dialogs, and admin audit entries so policy changes are visible.
<h3>Why It Matters:</h3>
<ul>
<li aria-level="1">Data minimization by design If a third-party isn’t essential, you can keep your users’ data where it belongs: with you. This aligns directly with GDPR principles and ePrivacy Directive 5(3).</li>
<li aria-level="1">First-party strategy Rely less on external vendors, reduce cross-border transfer risks, and strengthen your data independence.</li>
<li aria-level="1">Real enforcement, not theatre Too many sites still initialize third-party stacks before consent. Permanent Block, combined with pre- and post-scans, prevents these silent leaks and keeps you audit-ready.</li>
</ul>
<h3>Use it For:</h3>
<ul>
<li aria-level="1">Telemetry scripts bundled into otherwise useful plugins.</li>
<li aria-level="1">Analytics beacons you’ve replaced with first-party analytics.</li>
<li aria-level="1">Embeds that set identifiers by default.</li>
</ul>
Pair it with our Privacy AI Advisor configuration with pre/post scanning and <a href="https://aesirx.io/solutions/analytics" target="_blank" rel="noopener">first-party Analytics</a> to run a site that respects people, reduces risk, and still learns what matters. That’s the web we’re building: privacy-first, first-party by default.
<h2>How to Get AesirX CMP for WordPress</h2>
<a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">Get AesirX CMP for WordPress</a> (14-day trial) and start marking the noisy stuff Permanent. Your users - and your future audits - will thank you.
➡ Download here: <a href="https://github.com/aesirxio/wordpress-consent-plugin/releases/tag/2.0.2" target="_blank" rel="noopener">AesirX CMP for WordPress – GitHub Releases</a>
Explore our ecosystem at: <a href="https://www.aesirx.io" target="_blank" rel="noopener">https://www.aesirx.io</a>

AesirX CMP for WordPress v2.0.2: Stop the Phone-Home. Permanently.

Blog Press Release Aesirx

Stop plugins from phoning home. AesirX CMP v2.0.2 for WordPress adds Permanent Block to keep data first-party, minimize risk, and enforce GDPR.

AesirX CMP for WordPress v2.0.2

If it’s not okay offline, it’s not okay online. Most sites track before consent, breaking trust. Learn why first-party control is the ethical default.

If It’s Not Okay Offline, It’s Not Okay Online

Scans show most sites track before consent, risking compliance and trust. See why true consent and first-party control are the only sustainable path.

If It’s Not Right Offline, It’s Not Right Online

<h2>Abstract</h2>
Zero-knowledge proofs (ZKPs) and consent are often portrayed as antagonists: one promises unlinkability, the other demands non-repudiation. In practice, they are complementary. Consent is about binding a decision to a specific event in a specific context, not about doxxing a person forever. ZKPs are about proving the right fact without exposing the rest. When we combine context-bound consent, local verification, and hash-only evidence, we get a system that is private by default yet accountable on demand - with precise auditability and no surveillance creep.
Author’s note: This article reflects work with AesirX and Concordium on privacy-preserving technologies (PETs) for practical regulatory compliance - from consent to ID verification. ‘Consent receipt’ maps conceptually to <a href="https://www.iso.org/standard/80392.html" target="_blank" rel="noopener">ISO/IEC 27560 (Consent Record)</a>: evidence that a data subject (via a holder key) agreed to a specific policy under a specific context and timestamp - without publishing identity attributes. Predicate proofs are commonly conveyed as W3C Verifiable Credentials or SD-JWT; the model is compatible with either while insisting on local verification and context binding. References to EUDI and mDL are illustrative; the design is wallet-agnostic and vendor-neutral.
TL;DR: Consent proofs should be event-scoped and verified locally. Keep only hash-anchored receipts; open one named event under due process - nothing ambient.
<h2>Consent Is an Event, Not an Identity</h2>
Most systems confuse the notion of consent with perpetual identification. A privacy-preserving stack treats consent as a decision attached to one concrete interaction, captured as: who controlled the key, what policy was accepted, where the interaction occurred, and when. The “who” is cryptographic control of a holder key. The “what/where/when” are folded into a context that names the relying party, the requested action, the policy in force, and a bounded time window.
This reframing matters. Once consent is event-scoped, the requirement becomes non-repudiation of that event, not lifelong tracking of that person. The subtlety is that non-repudiation attaches to the event and the key, while privacy applies to the person beyond the event.
<h2>Proving the Right Thing, Locally</h2>
ZKPs shine when the verifier only needs a predicate (e.g., “over 18,” “EU resident,” “same holder as before within this site”). Instead of calling an issuer on every request - or copying raw attributes - the verifier checks a proof locally. There is no routine “phone-home” to the issuer, which eliminates an otherwise constant, correlating exhaust trail.
Local verification moves consent from full disclosure to minimal proof. That is the essence of data minimization and makes the subsequent evidence we keep about consent much smaller and much safer.
<h2>Evidence Without Exposure: The Consent Receipt</h2>
Non-repudiation doesn’t require identity sprawl; it requires evidence tied to context. The right evidence is a consent (and/or verification) receipt that binds:
<ul>
<li aria-level="1">the holder’s key (not their PII),</li>
<li aria-level="1">the context (relying-party origin scope, action, bounded time window, and policy reference),</li>
<li aria-level="1">and a timestamp.</li>
</ul>
The receipt can live off-chain (signed and stored first-party) or be anchored by a hash-only receipt on a ledger. Either way, it proves that this key agreed to this policy under this context at this time - while revealing nothing else. Crucially, receipts are context-scoped, so they don’t create a global identifier or a reusable token.
This aligns with ISO/IEC 27560 Consent Record: evidence of agreement to a specific policy in a specific context, without identity attributes in the record.
“Receipts are context-scoped and hash-only: they prove that a consented, valid event occurred without publishing proofs or personal data.”
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/evidence-without-exposure-the-consent-receipt.png" alt="evidence without exposure the consent receipt" width="1999" height="857" />
Figure 1. AesirX Event-Scoped Consent Pattern (2025) Event-scoped consent with zero-knowledge - Event-scoped consent with zero-knowledge: verify locally, log a first-party receipt, anchor a hash-only, and - under due process - open a single named event via Native or Escrow. No issuer phone-home. No ambient tracing (© AesirX 2025 · aesirx.io).
<h2>Operational Unlinkability as a Control Surface</h2>
Unlinkability is not a declaration; it’s a discipline. The discipline here is to ensure that each interaction uses fresh, context-derived key material. A private, on-device base is established once; for each event, the device derives a contextual key that depends on:
<ul>
<li aria-level="1">the verifier’s normalized origin scope (so “who” you’re interacting with is unambiguous but not over-broad),</li>
<li aria-level="1">the action (what is being asked),</li>
<li aria-level="1">and the time window (when it’s valid).</li>
</ul>
Because the event key is unique to that origin/action/window, the verifier cannot use it to follow the holder elsewhere, and holders cannot be silently correlated across relying parties. At the same time, the verifier gets a stable, short-lived handle (per-event key) to complete the current task and record a verdict + timestamp - nothing more.
<h2>Hash-Only Anchors, Never Raw Data</h2>
Many systems put too much on a chain - attributes, identifiers, even entire proofs. That is unnecessary and risky. A privacy-preserving design writes only hash-level anchors for auditability:
<ul>
<li aria-level="1">a context anchor for the event (a commitment to origin/action/time window and policy),</li>
<li aria-level="1">and, optionally, a verification receipt that says “a valid check happened here,” again as a small, hash-only record.</li>
</ul>
These anchors give auditors and courts immutability and ordering without revealing personally identifying information or proofs. They also make it possible to prove existence (“this event happened”) and bind follow-up artifacts (like governed disclosures) to the exact event that was originally agreed.
<h2>Due-Process Accountability, Event by Event</h2>
The hard question is: what happens if the law later requires us to identify the actor for a specific incident? We answer by making accountability event-scoped and governed, never ambient.
<h4>There are two clean lanes:</h4>
<ul>
<li aria-level="1">Native lane (when the identity provider already has a lawful, auditable map from credential to subject): if a court names a specific event by its context anchor, the provider can open that event only, issue a signed decision receipt, and nothing else leaks.</li>
<li aria-level="1">Escrow lane (when the provider does not hold a native map): at verification time, a sealed, per-event escrow is created off-chain with just enough origin information to contact the authoritative issuer or reconstruct identity under warrant. The ledger records only a hash of that escrow, bound to the event’s context anchor. Later, a court-named event triggers a threshold, governed decryption of the matching escrow. The hash on the ledger prevents substitution; the quorum prevents unilateral disclosure.&nbsp;</li>
</ul>
Either lane yields targeted accountability without constructing a shadow identity graph. Routine operation remains silent and unlinkable; only the named event is opened, and only with a formally valid order.
For the Escrow lane, the sealed, per-event escrow contains only what is necessary to contact the authoritative issuer or to reconstruct identity for that event - nothing more - and is retention-bounded by default (e.g., 90 days) unless a legal hold applies. The ledger stores only a hash commitment to prevent substitution.
“Per-event escrow (when used) is minimal and retention-bounded; the ledger holds only a hash commitment that prevents substitution.”
<h2>Scenario - Age-gating a social feature</h2>
A social platform gates access to 18+ spaces. The page declares the policy; the user’s wallet proves ‘over 18’ locally. The site records a YES decision and anchors a hash-only receipt bound to the context (origin, action, window, policy). Months later, moderation investigates a specific post time: a court names that context anchor, and custodians open that event only under due process. Routine use remained unlinkable; the exception was governed and auditable.
<h2>Crossing Domains Without Crossing Privacy Boundaries</h2>
Digital life is multi-platform. Relying parties in other systems may want assurance that a particular context was satisfied - without importing identity data. The answer is a short-lived attestation that says “the predicate for this exact context anchor evaluated to yes,” signed by a key whose lifecycle and rotation are visible on a public registry.
Recipients verify the signature, the audience, the expiry, and the binding to the referenced context anchor or receipt. They never receive identity attributes, and they never gain a token that can be replayed across contexts. In short: outcome portability without data portability.
<h2>Governance: The Human Layer That Makes It Work</h2>
Cryptography enables, but governance legitimizes:
<ul>
<li aria-level="1">Context discipline prevents over-broad scopes and keeps receipts meaningful.</li>
<li aria-level="1">Issuer-silence during routine use removes a primary source of correlation.</li>
<li aria-level="1">Retention and rotation policies ensure that any per-event escrow, when used, remains minimal, time-bounded, and tamper-evident.</li>
<li aria-level="1">Decision receipts make due-process actions auditable, linking the human/legal decision to cryptographic evidence.</li>
</ul>
The model operationalizes necessity and proportionality: routine interactions disclose only the predicate needed to fulfill a purpose, while accountability is reserved for named events. Hash-only anchors provide auditability and ordering without exposing personal data or proofs.
This is where privacy engineering meets <a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">compliance</a>. The system is designed so that the legally right thing is also the path of least resistance operationally.
“When lawfully required, only the named event is opened under a governed (due-process) lane using a quorum of custodians; there is no ambient re-identification.”
<h2>Threats, Tamed by Design&nbsp;</h2>
<ul>
<li aria-level="1">Replay &amp; Look-alikes: Single-use, time-bounded contexts tied to a normalized origin scope prevent replays and phishing-by-confusion.</li>
<li aria-level="1">Silent Correlation: Local verification and context-derived event keys starve trackers; there’s no routine issuer callback and no long-lived handles.</li>
<li aria-level="1">Evidence Integrity: Hash-only anchors and signed receipts provide tamper-evident trails without exposing payloads.</li>
<li aria-level="1">Governed Disclosure: Event-scoped, threshold-controlled openings ensure that “exception handling” does not morph into surveillance.</li>
</ul>
<h2>What Good Consent Feels Like&nbsp;</h2>
A user visits a relying party that needs an age gate. The page states the policy clearly; the wallet proves the predicate privately on the device; the site logs “yes, at this time, under this policy” - and moves on. No new account, no dossier, no background radiation of issuer pings. Months later, an incident tied to a specific posting time is investigated: the court names the exact context anchor, and the governed lane reveals that event only. The routine remains private; the exception is accountable.
This is the equilibrium the field has sought for a decade: selective disclosure at the moment of use, contextual evidence for consent, and event-scoped accountability when the real world demands it.
<h2>Policy Alignment Without Gymnastics</h2>
By separating predicate proof from identity exposure, it operationalizes necessity and proportionality. By using context-bound, hash-only receipts, you create stronger evidence than the logs most systems keep today - while holding less personal data. And by structuring accountability as named-event disclosure under governance, you meet legitimate investigative needs without building a surveillance platform.
<h2>Conclusion</h2>
ZKPs and consent do not cancel each other out; they snap together. The key is to treat consent as event evidence bound to context and key control, and to treat ZK as a way to prove exactly what is necessary - nothing more. With local verification, contextual keys, and hash-only anchoring, privacy becomes the default state. With governed, event-scoped disclosure, accountability remains available when the law requires it. That balance - privacy by default, accountability on demand - isn’t a compromise. It’s how modern cryptography finally makes good on the original promise of the web.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Discover how consent and zero-knowledge proofs work together to give users privacy, verifiable trust, and compliance without exposing identity.

The Correlation and Value of Consent and Zero-Knowledge Proofs

Explore how zero-knowledge proofs and consent combine to protect privacy, deliver verifiable receipts, and meet compliance with minimal data.

Consent & Zero-Knowledge Proofs: Key Insights

Agencies already using AesirX now have something they’ve never had before – a single page that shows every client, every license, and every commission.
The new <a href="https://aesirx.io/dashboard">Customer Overview</a> centralizes license control, client accounts, and product usage across the <a href="https://aesirx.io/partner/alliance-for-compliance-partner" target="_blank" rel="noopener">AesirX ecosystem</a>, designed specifically for agency and partner workflows.
By separating active licenses from pending requests, it provides both a compliance-ready record and a clear sales pipeline view, with built-in commission tracking to highlight the financial value of managing customers through AesirX.
Explore the Customer Overview in the portal and see how it transforms client management into a scalable, privacy-first workflow.
<h2>Navigation in the AesirX Customer Portal</h2>
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
How to Log In
1. Go to <a href="https://aesirx.io/dashboard" target="_blank" rel="noopener">https://aesirx.io/dashboard</a>.
2. Click Log In on the lefthand menu.
3. Select your login method: Email and Password, Social Media, or Web3 Wallets. and follow the prompts until you are logged in.
4. You’ll land on the Dashboard page where you can see a snapshot of your account.
</div>
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/navigation-in-the-aesirx-customer-portal.png" alt="navigation in the aesirx customer portal" width="942" height="550" />
The Customer Overview is part of a much larger system: the <a href="https://aesirx.io/dashboard" target="_blank" rel="noopener">AesirX Customer Portal</a>, designed as the central hub for agencies and partners. From here, every function that matters to client management, compliance, and community engagement is accessible in one environment – it’s the place where agencies control licenses, monitor privacy, and track their revenue streams.
At the heart of the portal is the left-hand navigation sidebar, which organizes the ecosystem into clear sections. Privacy Scanner includes tools like the Real-Time Scanner, Privacy Monitoring, and Bulk Scanner, giving users immediate access to compliance checks.&nbsp;
Community Programs such as Share2Earn, <a href="https://aesirx.io/affiliate2earn" target="_blank" rel="noopener">Affiliate2Earn</a>, and Contribute2Earn are also integrated, reflecting how AesirX connects you with customers and wider business opportunities.
Within the Service Management structure, the Customer Overview is the dedicated management page for agencies. While Licenses and Subscriptions are designed for individual users managing their own accounts, Customer Overview gives agencies a consolidated view across all of their clients. It’s where account control, license visibility, and commission tracking come together, allowing agencies to manage relationships and revenue in one place.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Read More:
<a href="https://aesirx.io/blog/aesirx/cookiebot-alternative-for-wordpress-first-party-aesirx-cmp" target="_blank" rel="noopener">Why WordPress Sites Are Leaving Cookiebot In 2025 And Choosing AesirX CMP</a>
</div>
<h2>How to Issue New Licenses</h2>
Agencies can assign licenses directly to existing AesirX clients. Once payment is confirmed, the license is automatically linked to the user’s account, keeping records consistent for compliance, renewals, and commission tracking. This eliminates the need for manual updates or third-party systems and ensures every license is tied back to the right customer.
The process is handled through a simple modal with the following fields:&nbsp;
<ul>
<li aria-level="1">Username – enter the existing AesirX client’s username.</li>
<li aria-level="1">Solution – select which AesirX product (CMP, Analytics, First-Party Server, etc.).</li>
<li aria-level="1">Plan – choose the subscription tier (Starter, Team, Growth, Enterprise).</li>
<li aria-level="1">Billing Cycle – set monthly or annual billing.</li>
<li aria-level="1">Email – confirm the client’s registered email address.</li>
<li aria-level="1">Domain – add the primary domain linked to the license.</li>
<li aria-level="1">Issue New License – click the button to complete the process.</li>
</ul>
Once issued, the license becomes part of the agency’s centralized view in Customer Overview.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/license-added-to-agencys-customer-overview.png" alt="license added to agencys customer overview" width="942" height="550" />
<h2>How to Create New Customers</h2>
For new business, agencies can onboard clients by creating an account and issuing a license in one step. This feature is particularly useful for agencies expanding their portfolio or working with clients who don’t yet have an AesirX profile.
The modal mirrors the license process, with the following fields:
<ul>
<li aria-level="1">Username – create a new client account by entering their username.</li>
<li aria-level="1">Solution – select the product they need.</li>
<li aria-level="1">Plan – assign the correct subscription tier.</li>
<li aria-level="1">Billing Cycle – choose monthly or annual billing.</li>
<li aria-level="1">Email – enter the client’s contact email.</li>
<li aria-level="1">Domain – add the domain the license will be tied to.</li>
<li aria-level="1">Create New Customer – click the button to complete the process.</li>
</ul>
By combining account creation with license assignment, onboarding becomes faster and more accurate, removing bottlenecks that often slow down client activation.
Together, these features turn Customer Overview into a full management hub—not only showing agencies what they have today, but giving them the tools to grow their client base directly within the AesirX ecosystem.
<h2>The Overview Tab: Active Clients and Licenses</h2>
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/the-overview-tab-active-clients-and-licenses.png" alt="the overview tab active clients and licenses" width="942" height="350" />
The Overview Tab is where agencies see every active customer and the licenses tied to them. It is designed to provide transparency, making it easy to monitor usage, renewals, and revenue in one place.
The table lists:
<ul>
<li aria-level="1">User ID – the unique identifier for each client.</li>
<li aria-level="1">Domain – the primary domain linked to the license.</li>
<li aria-level="1">Remaining Domain(s) – any unused domains still available under the license.</li>
<li aria-level="1">Solution – the AesirX product in use (CMP, Analytics, First-Party Server, etc.).</li>
<li aria-level="1">License – the key associated with the product.</li>
<li aria-level="1">Plan – the subscription tier the client is on.</li>
<li aria-level="1">Days Left – the remaining time on the license, including expired entries.</li>
<li aria-level="1">Commission – agency earnings tied to that license, shown in USD.</li>
</ul>
This structure gives agencies a real-time compliance record while also tracking revenue. By seeing license usage and expiry dates alongside commissions, agencies can forecast renewals, spot inactive accounts, and prioritize where to focus attention.
<h2>The Requested Licenses Tab: Pipeline and Pending Revenue</h2>
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/the-requested-licenses-tab-pipeline-and-pending-revenue.png" alt="the requested licenses tab pipeline and pending revenue" width="942" height="550" />
The Requested Licenses tab captures every license request that is awaiting payment. Once payment is received, the request automatically moves into the Overview tab, keeping live accounts and pending deals clearly separated.
The table lists:
<ul>
<li aria-level="1">User ID – the client making the request.</li>
<li aria-level="1">Domain – the primary domain for the license.</li>
<li aria-level="1">Solution – the AesirX product requested.</li>
<li aria-level="1">Billed Cycle – how the plan is billed (monthly, annually, etc.).</li>
<li aria-level="1">Plan – the subscription tier.</li>
<li aria-level="1">Commission – the agency’s expected earnings in USD.</li>
<li aria-level="1">Status – the current stage of the request (awaiting, accepted).</li>
<li aria-level="1">Action – quick access to edit license details when needed.</li>
</ul>
This tab gives agencies a structured sales pipeline view, showing which clients are close to activation, what revenue is coming, and where intervention may be needed if a request stalls. It reduces confusion between unpaid and active clients, ensuring agencies keep visibility of both current and future business.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/agency-benefits.png" alt="agency benefits" width="942" height="550" />
<ul>
<li aria-level="1">Centralized control – manage all clients and products from one screen.</li>
<li aria-level="1">Flexible filtering – zero in on the accounts or solutions you need.</li>
<li aria-level="1">Scalability – add customers, issue licenses, and manage growth at scale.</li>
<li aria-level="1">Transparency – see license usage, expiration dates, and commissions in real time.</li>
<li aria-level="1">Faster onboarding – activate clients without delays or manual tracking.</li>
<li aria-level="1">Revenue tracking – clear view of agency commissions built into the dashboard.</li>
<li aria-level="1">Compliance readiness – link to Privacy Scanner tools for an integrated workflow.</li>
</ul>
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Grow Your Business with Privacy-First Solutions
Add a recurring revenue stream to your agency by offering high-demand, privacy-first solutions
<ul>
<li aria-level="1">Earn 30% commission on sales of product licenses.</li>
<li aria-level="1">Receive priority access to support and resources.</li>
</ul>
<a href="https://aesirx.io/partner" target="_blank" rel="noreferrer noopener" class="fw-semibold py-13px px-4 lh-sm text-white btn btn-success" tabindex="0" role="button">Become a Partner</a></div>

AesirX Customer Overview: The Agency Dashboard for Privacy-First Client Management

How to Customer-Portal

Learn how to issue licenses, onboard new clients, and track revenue with AesirX Customer Overview, the agency hub for privacy-first management.

AesirX Customer Overview: The Agency Dashboard

Vietnam’s draft PDPL Decree brings stricter consent, tracking, and cross-border data rules from 2026. Learn key changes vs GDPR/ ePrivacy in plain terms.

Vietnam’s PDPL - Key Changes in the Draft Implementing Decree

Vietnam’s PDPL - Key Changes in the Draft Implementing Decree (Consultation, Sept 2025)

 Vietnam’s draft PDPL Decree (2026) changes how websites, apps, and vendors handle consent, sensitive data, and cross-border transfers vs GDPR rules.

<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR: Article 5(3) of the ePrivacy Directive is the EU’s only safeguard that requires consent before tracking begins. The answer isn’t handing control to big third-party consent hubs, which only create new cross-site tracking risks. Instead, the way forward is simple: keep consent first-party, respect signals like GPC, and build toward wallet and zero-knowledge proof solutions that give people real privacy without extra hassle.
</div>
On 16 September 2025, the Commission launched a <a href="https://digital-strategy.ec.europa.eu/en/news/commission-collects-feedback-simplify-rules-data-cybersecurity-and-artificial-intelligence-upcoming" target="_blank" rel="noopener">call for evidence</a> for its Digital Omnibus, aiming to streamline digital legislation while maintaining high standards of fairness and safety; the consultation runs to 14 October 2025.
This article outlines what the Digital Omnibus should do about cookies - preserve 5(3), ban centralized consent telemetry, and standardize enforcement tests.
<h2>The rule that works where GDPR can’t</h2>
The ePrivacy Directive Article 5(3) governs the moment of access - before any data is captured or classified. That scope is wider than “cookies”: it includes scripts, SDKs, pixels, localStorage, and fingerprinting techniques that fire on first paint. By contrast, the GDPR engages after data becomes personal, at which point telemetry may already have been emitted. That timing gap is why 5(3) matters today more than ever.&nbsp;
In modern stacks, tag managers and telemetry frameworks still bootstrap early, then ask for consent later.&nbsp; Where cookie-consent-as-a-service, invoicing telemetry, pixel trackers, or Google Tag Manager cause any access to or storage of information on a user’s device prior to valid consent, they are non-compliant under ePrivacy Directive Article 5(3). The tools themselves aren’t unlawful per se; but any design that causes pre-consent device access is. That isn’t a technical constraint - it’s a business choice. Keeping 5(3) strong ensures the default becomes “defer by design,” not “collect now, rationalize later.”
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Read more:
<a href="https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en" target="_blank" rel="noopener">EDPB Guidelines 2/2023 on ePrivacy Directive 5(3)</a>
</div>
<h2>The map of Europe: alignment is not the problem</h2>
With Estonia as the only outlier that hasn’t expressly transposed 5(3), every EU Member State has implemented the device-access consent rule in national law. The UK and Norway run equivalent regimes. Enforcement is split (communications regulators vs. DPAs, sometimes both), but the legal baseline is surprisingly aligned. See below enforcement matrix for ePrivacy Directive Article 5(3) - Transposition &amp; enforcers (EU-27 + UK + NO), status as of 16 Sep 2025.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/The_map_of_Europe_alignment_is_not_the_problem.png" alt="The map of Europe alignment is not the problem" width="1969" height="1230" />
<h2>The gap is enforcement, not law</h2>
Alignment on paper hasn’t translated to behavior online. Europe’s legal baseline is remarkably aligned; behavior is not. Our July scan of <a href="https://www.linkedin.com/pulse/what-36000-danish-business-websites-just-revealed-why-christiansen-e1bec/" target="_blank" rel="noopener">36,500 Danish sites</a> found that a majority still load Google Tag Manager before consent. Across hundreds of thousands of scans in EU countries, the UK and Norway, nearly three-quarters of sites remain non-compliant. Even public-sector sites underperform: <a href="https://www.linkedin.com/pulse/public-sector-privacy-hypocrisy-sovereignty-vs-christiansen-biecc/" target="_blank" rel="noopener">82% in Denmark and 91% in Sweden fired beacons pre-consent</a>. Agencies and vendors know the rules; they’re gambling on the odds. Until early-load frameworks are treated as clear 5(3) violations - with repeatable tests and predictable penalties - non-compliance will remain the growth strategy.
Method: <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">AesirX Privacy Scanner</a> (based on EDPS Inspection Tool) + HAR Network analysis; country scans July–Sept 2025; details on request.
“Consent fatigue isn’t caused by 5(3). It’s caused by solutions that don’t implement 5(3) properly.”
<h2>The wrong fix: centralized consent hubs</h2>
Centralized “cookie management” sounds efficient but re-creates surveillance patterns. Any solution that calls a third-party hub on page load reveals when and where a person is browsing. At scale, those “consent pings” become a cross-site dossier - even if labeled anonymous. It also clashes with wallet and trust-framework principles, which rely on issuer-silent, unlinkable proofs.&nbsp;
Why “Central cookie management” can easily become surveillance by design:
<ul>
<li aria-level="1">Phone-home consent pings reveal when and where a person visits.</li>
<li aria-level="1">Cross-site linkability grows as one operator handles consent for millions of properties.</li>
</ul>
We must not fix banner fatigue by centralizing the consent layer.
<h2>The right fix: decentralized, first-party consent</h2>
This is proven and deployable. In our first-party CMP work and ongoing development, the pattern that preserves rights while simplifying UX is:
First-party by default
<ul>
<li aria-level="1">Evaluate and store consent on the site’s own origin.</li>
<li aria-level="1">No third-party calls before consent. No GTM bootstrap. No remote CMP telemetry.</li>
</ul>
User-controlled automation
<ul>
<li aria-level="1">Respect GPC and similar signals as a valid default refusal unless the user actively overrides.</li>
<li aria-level="1">Let people pre-set granular preferences using a digital wallet (by purpose/vendor/category). On opt-in, sign a local proof-of-consent.</li>
</ul>
Zero-knowledge compliance
<ul>
<li aria-level="1">Prove “user consented to Purpose X at Time T” without revealing identity, browsing history, or wallet metadata.</li>
<li aria-level="1">Keep flows issuer-silent so no external party learns where a proof is presented.</li>
</ul>
Audit without tracking
<ul>
<li aria-level="1">Issue unlinkable consent receipts bound to domain, purpose, and a time window.</li>
<li aria-level="1">Support revocation and expiry locally; allow verifiers to check validity without global IDs.</li>
</ul>
First-party consent and analytics help reduce legal risk and mitigate signal loss without surveillance. The net effect: fewer banners, faster pages, and valid proofs for auditors - without any “phone home”.
The Omnibus can close this gap without centralizing consent by codifying the practices that already work.
<h2>What the Digital Omnibus should adopt for cookies</h2>
<ul>
<li aria-level="1">No device access before consent - full stop Tag managers and telemetry frameworks count as device access. Default to defer by design.</li>
<li aria-level="1">Ban centralized consent telemetry Prohibit remote CMP calls and identifier issuance before valid consent. Require consent checks to run first-party or on the user’s device.</li>
<li aria-level="1">Make signals work for people Recognize GPC and equivalent as a refusal baseline unless the user affirmatively overrides. Allow wallet pre-sets to auto-apply user-chosen consents.</li>
<li aria-level="1">Embrace privacy-enhancing tech Accept zero-knowledge proof-of-consent and issuer-silent flows as compliant evidence. Publish a reference profile for unlinkable receipts.</li>
<li aria-level="1">Align enforcement Create a joint playbook for communications regulators and DPAs: repeatable script audits, network-trace tests, transparent remediation paths, and minimum penalties for systematic pre-consent loading.</li>
<li aria-level="1">Lead by example Mandate strict compliance for public-sector websites first, then cascade to critical private services.</li>
</ul>
<h2>Early learnings and what we’re measuring</h2>
Our approach doesn’t change the legal baseline: first-party analytics, google tag manager, telemetry from cookie banners and any non-essential tags still require consent under 5(3), except in narrow, country-specific measurement exemptions. The value comes from how consent is handled - not from sidestepping it.
<ul>
<li aria-level="1">Defer-by-default: All non-essential scripts and frameworks are held until a valid signal exists. This eliminates early-load violations and reduces network noise before a decision.</li>
<li aria-level="1">Respect signals, reduce repetition: When a user has a pre-set refusal (e.g., via Global Privacy Control) the site can avoid re-prompting or show a single, lightweight prompt with everything off by default. That doesn’t remove the need for consent; it reduces repetitive nagging when the user already said “no.”</li>
<li aria-level="1">Wallet pre-sets for opt-in, never for override: If a user proactively configures granular opt-ins in a digital wallet, those choices can be presented and signed on the site. Wallet pre-sets never override a user’s refusal signal by default; they express the user’s intent when the user chooses to proceed; users must actively opt in on-site.</li>
<li aria-level="1">Operational gains: Deferring third-party bootstraps improves initial render performance; keeping proofs/receipts local streamlines audits and shortens incident investigations - without creating centralized telemetry.</li>
</ul>
This is work in progress and will be documented openly; proposals here are intended to guide the Omnibus, not to pre-judge its outcome.
<h2>Turning Rules into Results</h2>
<ul>
<li aria-level="1">Policymakers and regulators: lock in first-party, decentralized consent; ban centralized consent telemetry; publish a common testing and enforcement playbook.</li>
<li aria-level="1">Industry: stop loading anything pre-consent. Move consent, analytics, and tags first-party. Respect GPC.</li>
<li aria-level="1">Wallets and civic-tech: ship user-friendly pre-sets and ZK consent proofs normal people can actually use.</li>
<li aria-level="1">Readers: check the attached matrix to see who enforces 5(3) in your market - then check your own site’s first paint.</li>
</ul>
Simplification should mean fewer prompts and clearer choices - not a new surveillance layer. Keep ePrivacy Directive 5(3) strong, keep consent local, and give people tools that automate privacy without giving up their privacy.
The consultation runs to 14 October 2025 so if you care about privacy and your right to decide who can collect and use your behavioral data, now is the time to make your opinion known.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="http://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
<h2>Answering the Commission’s guiding questions</h2>
The Commission has published a <a href="https://www.linkedin.com/posts/luisalbertomontezuma_cookies-activity-7373879796461723649-pD2I" target="_blank" rel="noopener">one-page set of guiding questions</a> for the Digital Omnibus consultation. I’m answering those questions directly below. That said, several prompts appear narrowly framed around “cookies” and seem to presuppose outcomes that lean toward centralization. My responses reflect a different premise: we can reduce consent fatigue without creating new surveillance layers.
Crucially, Article 5(3) covers all device access on terminal equipment - not only “cookies,” but scripts, SDKs, pixels, beacons, localStorage, fingerprinting, tag managers, and telemetry frameworks. Where the 1-pager speaks in cookie terms, I address the full scope of tracking technologies to avoid loopholes and ensure any changes protect users before collection begins.
<h3>1. How do you currently comply with Article 5(3) and GDPR, and where are the challenges?&nbsp;</h3>
We run defer-by-design: no non-essential device access (including tag managers and telemetry) until a valid signal exists; then we record consent with unlinkable, first-party receipts. GDPR obligations (lawful basis, transparency, rights handling) apply downstream to any personal data; 5(3) governs the upfront device access. The main challenge is inconsistent enforcement that rewards early-load designs over compliant ones.
<h3>2. What proportion of websites use cookies for advertising? Which could be acceptable without consent (e.g., statistics)?</h3>
Advertising and audience-building commonly rely on device access; under 5(3) they require prior consent, irrespective of whether data is personal at capture time. “Statistics” can be exempt only where narrowly defined in national law (limited, aggregate, privacy-preserving measurement). Broad “low-impact” carve-outs risk becoming a de facto tracking loophole. The safer route is to recognize refusal signals and streamline consent when users genuinely opt in.
<h3>3. What’s the right balance between transparency/choice and avoiding consent fatigue?</h3>
Stop re-asking when the user already refused. Treat Global Privacy Control as a standing “no” unless the user overrides on-site; when a user wants to opt in, let them pre-set granular choices in a local wallet and sign on-site. This reduces prompts without central telemetry or cross-site linkability.
<h3>4. Are there use cases where only non-personal data is processed?</h3>
Yes - but 5(3) applies to device access, not just personal data. If a script, SDK, or local storage is touched, consent is required unless strictly necessary for the service. Treating “non-personal” as a blanket exemption would re-open the door to covert profiling pipelines; enforcement should check device access first, classification of data second.
<h3>5. When is a legal person a “user,” and how is consent given?</h3>
In B2B contexts (corporate devices/browsers), the organisation can define defaults and governance, but the terminal equipment is still “user” under 5(3). Consent should be recorded on the first-party origin with non-linkable receipts; enterprise wallets or device-level signals can express the organisation’s preference - again, without central call-outs.
<h3>6. Could simplifying consent encourage privacy-enhancing tech?</h3>
Yes - if simplification bans centralized consent telemetry and validates privacy-preserving proofs. Recognizing zero-knowledge proof-of-consent and issuer-silent wallet flows would let sites prove compliance without creating cross-site dossiers. That’s simplification without surveillance.
<h3>7. Non-personal on-device use cases (compute, agents, transfers)?</h3>
Encourage on-device analytics and PETs that don’t export raw events; where device access is strictly necessary and no identifiers leave the device, Member States can define narrow, testable exemptions. But the default remains: no access before consent.

The EU’s Digital Omnibus should uphold Article 5(3): stop pre-consent tracking, block central consent hubs, and enforce rules consistently.

Simplify Without Surveillance: What the EU Must Do About Cookies

Simplify Without Surveillance: What the EU’s Digital Omnibus Must Do About “Cookies”

The EU’s Digital Omnibus must keep Article 5(3) strong: no tracking before consent, ban central consent telemetry, and set clear enforcement tests.

Visitors can show they meet age or location rules without giving away personal details
The v2.0.1 release of AesirX Consent Management Platform adds CryptoX Wallet as a privacy-preserving identity provider for age and country verification using zero-knowledge proofs.&nbsp;
Controllers can enforce eligibility policies (e.g., “18+” and “allow listed countries”) without ever storing personal attributes - only a yes/ no result with a proof reference.
This strengthens compliance for age-restricted content and geo-sensitive services while keeping your site fully first-party and consent-centric.
<h2>What’s New in CMP v2.0.1?</h2>
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/cryptox-wallet-support-age-and-country.jpg" alt="cryptox wallet support age and country" width="942" height="530" />
<h3>CryptoX Wallet Support (Age and Country)</h3>
<ul>
<li aria-level="1">New CryptoX adapter alongside existing wallet options.</li>
<li aria-level="1">Verifies age ≥ threshold and country in allow/deny list via ZKP.</li>
<li aria-level="1">Stores only: verification result (true/false), proof hash, timestamp. No PII persisted.</li>
</ul>
<h3>Policy-Driven Eligibility Engine</h3>
<ul>
<li aria-level="1">Configure age thresholds and country rules per site, per flow, or per surface (e.g., consent gate, download gate).</li>
<li aria-level="1">Fail-closed behavior: if verification cannot complete, protected actions remain blocked until policy is satisfied.</li>
</ul>
<h3>Unified UX Across Surfaces</h3>
<ul>
<li aria-level="1">“Verify with CryptoX” option appears where verification is required (consent flows, content gates, checkout gates).</li>
<li aria-level="1">Graceful fallback guidance when a user doesn’t have the wallet yet.</li>
</ul>
<h3>Admin Controls and Logging</h3>
<ul>
<li aria-level="1">New settings for enabling CryptoX, setting thresholds, and managing country lists.</li>
<li aria-level="1">Audit-friendly verification event logs (pseudonymous, no raw attributes).</li>
</ul>
<h2>8 New Languages - Now Supporting 48 in Total</h2>
&nbsp;<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/8-new-languages-now-supporting-48-in-total.jpg" alt="8 new languages now supporting 48 in total" width="942" height="530" />
Global support expands again with 8 newly added languages, carefully chosen to cover underserved regions and compliance-heavy markets. These languages were not previously supported in the 40-language set.
<h4>Languages Added in v2.0.0:</h4>
<ol>
<li aria-level="1">Bosnian (BS)</li>
<li aria-level="1">Armenian (HY)</li>
<li aria-level="1">Kannada (KN)</li>
<li aria-level="1">Swahili (SW)</li>
<li aria-level="1">Nepali (NE)</li>
<li aria-level="1">Macedonian (MK)</li>
<li aria-level="1">Urdu (UR)</li>
<li aria-level="1">Sinhala (SI)</li>
</ol>
Why it matters: Providing clear, local-language consent notices is not only best practice - it’s a legal requirement in many jurisdictions. AesirX CMP now enables websites to present their consent dialogs and privacy policies in 48 languages, dramatically increasing compliance reach across Africa, Asia, and the Balkans.
<h2>Summary: v2.0.1 Highlights</h2>
<div class="table-responsive">
<table class="table table-bordered">
<tbody>
<tr class="bg-primary-stroke-2">
<td style="text-align: center;">&nbsp;&nbsp;Feature</td>
<td style="text-align: center;">Benefit</td>
</tr>
<tr>
<td>
CryptoX Wallet (ZKP)
</td>
<td>
Prove eligibility without exposing PII
</td>
</tr>
<tr>
<td>Age &amp; Country Policies</td>
<td>Simple, robust enforcement per flow</td>
</tr>
<tr>
<td>Admin Controls and Logs</td>
<td>
Clear oversight with minimal data
</td>
</tr>
<tr>
<td>8 New languages</td>
<td>
Wider compliance reach across regions
</td>
</tr>
</tbody>
</table>
</div>
<h2>Get AesirX CMP for WordPress</h2>
<div class="align-items-center justify-content-center d-flex flex-wrap gap-3 mb-4"><a href="https://github.com/aesirxio/wordpress-consent-plugin/releases/tag/2.0.1" target="_blank" rel="noreferrer noopener" class="fw-semibold py-13px px-4 lh-sm text-white btn btn-success" tabindex="0" role="button">Start 14-Day Trail </a> <a href="https://github.com/aesirxio/wordpress-consent-plugin/releases" target="_blank" rel="noreferrer noopener" class="fw-semibold py-13px px-4 lh-sm btn btn-outline-success" tabindex="0" role="button">Download on GitHub</a></div>
Want a full privacy compliance suite? Explore our ecosystem:
CMP + First-Party Analytics
Visit:&nbsp;<a href="http://www.aesirx.io" target="_blank" rel="noopener">www.aesirx.io</a>
<a href="https://github.com/aesirxio/wordpress-consent-plugin/releases/tag/2.0.1" target="_blank" rel="noopener">AesirX CMP v2.0.1 </a>empowers controllers to enforce age and country rules with zero-knowledge privacy, keeping user trust - and your compliance posture - front and center.

AesirX CMP for WordPress v2.0.1: New CryptoX Wallet on iOS and Android for Age and Country Verification

AesirX CMP for WordPress v2.0.1 adds new CryptoX Wallet, letting visitors prove age or location privately with zero-knowledge proofs and no data exposure.


AesirX CMP for WordPress v2.0.1: New CryptoX Wallet

Identifiability is relative; consent is not
TL;DR: Pseudonymization reduces risk, but it never replaces consent. If a recipient can reasonably re-identify, treat it as personal data; if not, prove why and keep it that way.
The most helpful way to read the recent ruling (<a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62023CJ0413" target="_blank" rel="noopener">CJEU, Case C-413/23 P</a>) is this: the same dataset can be personal for one recipient and non-personal for another only when the second recipient is objectively unable to re-identify anyone. That means no lawful or practical route to keys, lookups, or auxiliary data, and controls that make re-identification unreasonable in time, cost, and effort. The assessment is recipient-specific, but it is not subjective. You do not lower the threshold because a recipient is non-technical. You ask what this recipient, as an organization, can reasonably do or obtain. If they can get keys, purchase or query linking datasets, or ask the sender to perform joins, then the data is personal for them. Only when those routes are blocked in law and in practice does the same dataset cease to be personal in that recipient’s hands. This is a narrow, factual conclusion - not a license to relax duties at collection, and it does not excuse weak governance or vague promises.
The decision clarified three things that matter in day-to-day operations. First, opinions in submissions are personal data because they relate to the author. Second, pseudonymized data is not automatically personal for everyone; the answer depends on the recipient’s real capability to re-identify. Third, transparency is judged at collection from the controller’s perspective. What you say to people up front still anchors everything that follows.
“If a consultancy receives coded comments without any keys or lookups and cannot lawfully or practically cross-link them, those comments may be non-personal for that consultancy while remaining personal for the sender.”
Mini example: same dataset, different outcomes
<ul>
<li aria-level="1">Personal for the recipient: You share survey feedback where the “respondent ID” is a stable hash of the email. An external analytics vendor can join that hash against its own customer emails (or ask you for a keyed join), so re-identification is reasonable. Treat it as personal data for that vendor. </li>
<li aria-level="1">Not personal for the recipient (while safeguards hold): You send the same feedback to an independent consultancy as coded comments with no keys or lookups, and contracts/tech controls prevent joins. Re-identification isn’t reasonable for that consultancy, so the dataset may be non-personal in their hands. Keep it that way with separation, logging, rotation, and release-testing.</li>
</ul>
<h2>The consent point that many still miss</h2>
Consent cannot be retrofitted. If you want to use data for a purpose, and especially if you want to share it, you need to earn that permission at the moment of collection. You also need to keep the promise. That means four practical things.
<ol>
<li aria-level="1">Tell people clearly what you will use their data for and who will receive it. Name the recipients where possible; do not hide behind generic categories.</li>
<li aria-level="1">Separate consents for distinct purposes. Analysis is not the same as marketing. Onward sharing with a specific partner is not the same as internal use.</li>
<li aria-level="1">Make withdrawal real. If someone changes their mind, stop the processing that was based on consent and stop new disclosures based on that consent.</li>
<li aria-level="1">Version what you said. Keep a record of the exact wording and the choices at the time you collected the data. You cannot prove compliance without this.</li>
</ol>
Pseudonymization does not neutralize a weak consent story. If the sender is relying on consent for the original collection, the sender must get that consent right at the start. If the sender later shares the data in a form that is no longer personal for the recipient, the sender’s original transparency and purpose limitation still apply.
“If you collected for ‘internal analysis’ only, you cannot rely on later pseudonymization to justify sharing with an external analytics partner. Get separate, granular consent or change your lawful basis.”
With that baseline clear, here’s how to build what you promised at collection - without weakening your pseudonymization claims.
<h2>Why identifiability is a technical test</h2>
Law frames identifiability; engineering decides it. That is why the ruling is practical. The only meaningful question is whether this recipient, with the safeguards and auxiliary data they can access, can reasonably re-identify the person. If yes, treat it as personal data and apply the full regime. If no, then for that recipient and that specific processing operation, you may be outside personal data. That status lasts only while those facts remain the same.
Two realities make sloppy pseudonymization unsafe. First, AI-assisted linkage has made correlation cheap. Second, stable hashed identifiers create a trail. The moment one record ties back to a person, the rest of the hashed trail becomes linkable. Hashing is useful, but it does not make data anonymous. If you want anonymity, build for anonymity.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/Why_identifiability_is_a_technical_test.jpg" alt="Why identifiability is a technical test" width="942" height="530" />
<h2>The engineering patterns that actually work</h2>
The following patterns help, together with their limits. Use them as design choices, not as marketing labels.
When the recipient will still be in personal data
<ul>
<li aria-level="1">Tokenization with a lookup table kept by the sender. Treat tokens as personal inside your organization. Share only where the recipient’s role justifies access to the token stream.</li>
<li aria-level="1">HMAC or keyed hashing for de-duplication or joins. Useful for workflow. Still personal, and the key space is part of your risk model.</li>
<li aria-level="1">Pseudonymized telemetry for product analytics. Rotate identifiers, reduce precision, and set hard retention caps. Assume personal unless you can prove non-identifiability for that recipient.</li>
</ul>
When the recipient may be outside personal data
<ul>
<li aria-level="1">Tokenization with hard key separation and a contractual and technical prohibition on lifting safeguards. Prove that the recipient cannot access keys, lookup tables or auxiliary data that would make re-identification reasonable.</li>
<li aria-level="1">Aggregation with k-anonymity family targets. Design groups large enough to prevent singling-out. Re-evaluate when data refreshes.</li>
<li aria-level="1">Differential privacy for published statistics. Excellent for counts and rates. Do not try to publish row-level data under the same claim.</li>
<li aria-level="1">Synthetic data for development and demos. Validate against membership inference and linkage tests. Treat failures as a trigger to fall back to personal data handling.</li>
</ul>
Controls that turn claims into facts
<ul>
<li aria-level="1">Separate trust zones. Store keys, lookup tables and raw identifiers in a different environment with separate administrators.</li>
<li aria-level="1">Least privilege and logging. Prove that the recipient cannot escalate to lift safeguards. Keep tamper-evident audit trails.</li>
<li aria-level="1">Rotation and minimization. Rotate salts and identifiers, drop fields, and reduce temporal and spatial precision where it does not harm the purpose.</li>
<li aria-level="1">Testing as part of release. Run linkage and singling-out tests before each share or publication. Treat identifiability as a regression risk that can reappear.</li>
<li aria-level="1">Crypto agility. Plan for parameter updates and post-quantum options. Do not build yourself into a corner.</li>
<li aria-level="1">Supplier due diligence. Assess the recipient’s actual data estate and incentives. The test is what they can do, not what you hope they will not do.</li>
</ul>
<h2>DSARs, onward sharing, and record-keeping</h2>
The sender’s transparency duties bite at collection. If you will send data to a partner for analysis, say so. If the partner cannot identify people and will not receive keys or auxiliary data, say that too, but do not skip the disclosure. The partner’s obligations then depend on whether the partner can identify the person. If the partner can, it is personal data and they must act like it. If the partner cannot, document why not and maintain that state of affairs with technical and contractual controls.
DSAR quick case: A free-text comment (“My manager Anna…”) is the author’s personal data. You redact third-party names where necessary, but you don’t reject the request just because the text was pseudonymized.
For subject access requests, treat opinions and free-text comments as personal data of the author. Apply redaction and balancing where other people’s rights are involved. Do not use pseudonymization as a reason to ignore the request. Use it to scope what you can disclose safely.
Having grounded DSARs in the recipient test, let’s reconcile the two authorities shaping identifiability in 2025 - EDPB guidance and the CJEU’s SRB/Deloitte judgment.
<h2>EDPB vs. CJEU on Pseudonymization: Two Ways to Say the Same Thing</h2>
They are largely aligned. Both use a recipient-specific, “means reasonably likely” test. The EDPB <a href="https://www.edpb.europa.eu/system/files/2025-01/edpb_guidelines_202501_pseudonymisation_en.pdf" target="_blank" rel="noopener">Guidelines 01/2025 on Pseudonymization</a> gives the structure (a pseudonymization domain where attribution must be prevented). The CJEU applies the same logic to say the same dataset can be non-personal for a recipient who cannot reasonably re-identify - without relaxing the sender’s duties at collection or ignoring foreseeable onward recipients.
<h4>What the EDPB actually says</h4>
<ul>
<li aria-level="1">Context matters. Ask whether attribution is reasonably likely in the concrete scenario, not in the abstract.</li>
<li aria-level="1">Pseudonymization domain. Define who/what is inside the domain (people, systems, controls) and make sure linking is blocked in that domain.</li>
<li aria-level="1">Before transmission. Map the recipient’s practical means to re-identify and put contract + technical controls between them and any keys/lookups.</li>
</ul>
<h4>What the CJEU actually held (SRB/Deloitte)</h4>
<ul>
<li aria-level="1">No blanket rule. Pseudonymized data are not automatically personal “for everyone.” Assess identifiability from the recipient’s perspective and their reasonably likely means (including joins/lookups).</li>
<li aria-level="1">Controller duties remain. At collection, if you can attribute, you are in personal data and must meet the full regime (transparency, purpose, lawful basis, naming recipients).</li>
<li aria-level="1">Facts drive outcomes. If a recipient cannot lawfully or practically access keys or linking datasets, the same data may be non-personal in their hands - while staying personal for you.</li>
</ul>
<h2>So… aligned or divergent?</h2>
Aligned in substance. The EDPB’s “domain + reasonably likely means” framework dovetails with the CJEU’s recipient-specific test. The perceived conflict comes from old shorthand (“pseudonymized data remain personal data”) being read universally. Both insist on documented, contextual analysis - not absolutism.
<h4>In practice (why this matters right here)</h4>
<ul>
<li aria-level="1">Document the recipient test. For each share, record what the recipient could realistically use to re-identify and why that route is blocked in law and in practice.</li>
<li aria-level="1">Condition any “non-personal for recipient” claim. State the preconditions (no keys/lookups, no feasible joins, controls in place) and when you’ll re-check.</li>
<li aria-level="1">Keep collection promises intact. Your notices/consents reflect your capability to attribute and must name recipients - even if some recipients cannot re-identify.</li>
</ul>
With the concepts aligned, the implementation stays the same - jump to “Consent anchored design” for how to ship it.
<h2>Why consent is required at collection (GDPR + ePrivacy 5(3))</h2>
At the moment of collection, GDPR requires lawfulness, fairness and transparency (Art. 5(1)(a)), and a lawful basis such as consent for specified purposes (Art. 6(1)). Where consent is relied on, it must meet the GDPR definition - freely given, specific, informed and unambiguous - and be as easy to withdraw as to give (Arts. 4(11), 7(3)). Separately, the ePrivacy Directive Art. 5(3) requires prior consent before storing or accessing information on a user’s device (e.g., cookies, local storage, SDKs) unless it is strictly necessary for the service requested. In practice: if a tag/SDK writes or reads on the device (and isn’t strictly necessary), you need explicit consent before it runs; and if you rely on consent for processing, you must earn it at collection and be able to prove it later.
With the legal baseline clear, here’s the consent build pattern that meets GDPR and ePrivacy in practice.
<h2>Consent anchored design</h2>
Here’s the build pattern behind that consent promise.
<ul>
<li aria-level="1">Layered notice. A clear summary in the first layer that names the purposes and recipients, with a deeper layer for detail.</li>
<li aria-level="1">Granular choices. A checkbox for each materially different purpose. No forced bundling into one consent.</li>
<li aria-level="1">Named recipients. If you know who you will use, say so. If you truly do not, define the classes narrowly and commit to publishing a live list.</li>
<li aria-level="1">Durable records. Store the exact text and options shown at the time of collection and the user’s choice. Keep a consent ledger with timestamps and scope.</li>
<li aria-level="1">Revocation that works. Make it one click to withdraw. Stop new processing that depends on consent. Communicate withdrawals to downstream processors.</li>
<li aria-level="1">Purpose limitation in code. Bind data flows to purpose tags and block uses that are not explicitly consented. Treat this as a deployment gate, not a policy.</li>
</ul>
<h2>From theory to execution</h2>
If you send data
<ol>
<li aria-level="1">Rewrite your collection wording to reflect actual purposes and actual recipients. Do it in plain language.</li>
<li aria-level="1">For each recipient, write a short identifiability assessment that a security engineer can sign and a lawyer can understand. Keep it with the data map.</li>
<li aria-level="1">Decide where pseudonymization is good enough and where you need true anonymization or aggregation. Build the missing controls.</li>
<li aria-level="1">Do a tabletop exercise on withdrawal. Prove that you can stop a consent-based flow end-to-end.</li>
<li aria-level="1">Remove the words anonymous and anonymized wherever they are not strictly true. Replace them with the pattern you actually use.</li>
</ol>
If you receive data
<ol>
<li aria-level="1">Declare whether you can identify people with the data and resources you have. If the answer is yes, comply as a controller or processor as appropriate.</li>
<li aria-level="1">If the answer is no, lock in that answer with technical controls and contracts that prevent you from lifting safeguards.</li>
<li aria-level="1">Refuse data you do not need. It is easier to prove non-identifiability when you do not collect extra fields in the first place.</li>
</ol>
<h2>Consent requirements are fixed at collection, identifiability is relative</h2>
Pseudonymization can reduce risk. It does not replace consent, purpose limitation or transparency. Identifiability is relative and changes as capabilities and datasets evolve. Build for both truths at once. If you want the freedom to share, you have to win it at collection with honest wording and real choices, and then protect it with engineering that would stand up in a courtroom and in a code review.
Win consent at collection; defend non-identifiability with evidence.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="http://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

CJEU: Pseudonymisation reduces risk but cannot replace consent. Data use must be explained clearly and consent gained when first collected.

Pseudonymization after SRB and Deloitte

Court confirms data can be personal for one party but not another. Duties like consent and transparency apply from the moment of collection.

On 3 September 2025, the French regulator CNIL issued two of its largest fines to date: €325 million against Google and €150 million against Shein. Both cases have one thing in common: user consent was ignored.&nbsp;
Google was fined €325 million for inserting ads between Gmail emails without prior consent and for cookie choices during account creation that didn’t meet valid consent standards. CNIL also ordered the company to correct these practices within six months, with a penalty of €100,000 per day applying thereafter if it fails to comply.
Shein’s case was different but equally clear. <a href="https://www.cnil.fr/en/cookies-placed-without-consent-shein-fined-150-million-euros-cnil" target="_blank" rel="noopener">The retailer was fined €150 million</a> for placing cookies on arrival, continuing after ‘reject all,’ and providing incomplete information.
The <a href="https://www.cnil.fr/en" target="_blank" rel="noopener">Commission nationale de l’informatique et des libertés (CNIL)</a> is France’s independent data protection authority, responsible for enforcing the GDPR and the ePrivacy Directive. CNIL reported that more than <a href="https://www.cnil.fr/en/cookies-and-advertisements-inserted-between-emails-google-fined-325-million-euros-cnil" target="_blank" rel="noopener">74 million accounts in France were affected, and 53 million users saw Gmail ads in their inbox tabs</a>. Its rulings underline one principle: consent cannot be a surface exercise – a banner alone does not equal compliance. It must be enforced as a technical requirement.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/cnil-fines-google-eur325m-and-shein-eur150m-for-cookie-consent-violations-and-misleading-gmail-ads-in-france.jpg" alt="cnil fines google eur325m and shein eur150m for cookie consent violations and misleading gmail ads in france" width="942" height="530" />
<h2>When consent fails, compliance fails</h2>
Under <a href="https://gdpr-info.eu/issues/consent/" target="_blank" rel="noopener">GDPR</a> and the <a href="https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf" target="_blank" rel="noopener">ePrivacy Directive (Article 5(3))</a>, no tracking should take place until a user has given explicit, informed agreement. That means banners alone are not enough. The technical setup behind them must guarantee that “reject” means no tracking at all, and that consent can be withdrawn at any time.
CNIL’s latest decisions make clear that shortcuts will not be tolerated. When regulators investigate, they are looking not just at how a banner looks on screen, but at whether scripts, cookies, and pixels are blocked until the visitor has agreed.
<h2>The problem of “consent theatre”</h2>
These fines also highlight a wider issue across the web: consent theatre. This is when websites present users with a choice, but still allow trackers to fire in the background or make it harder to refuse than to accept. Shein’s cookies placed on arrival (and after refusal) and Google’s advertising inside Gmail are both examples of practices that look legitimate on the surface but fail the test of real compliance.
For regulators, this gap between appearance and enforcement undermines the entire idea of informed consent. For businesses, it creates a legal and reputational risk that is now measured in hundreds of millions of euros.
<h2>CMPs under scrutiny</h2>
With €475 million in fines handed down in a single day, CNIL has made its position clear. Consent must be enforced, not performed. Businesses that fail to recognise this are taking risks that can no longer be ignored, exposing themselves to escalating penalties and loss of user trust.
The lesson is simple: a compliant Consent Management Platform (CMP) with privacy-first enforcement built in is essential. Check your consent setup carefully, because if your CMP isn’t technically blocking trackers until consent, it isn’t protecting you.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/cnil-imposes-eur475m-fines-highlighting-risks-of-non-compliant-consent-management-platforms-cmps.jpg" alt="cnil imposes eur475m fines highlighting risks of non compliant consent management platforms cmps" width="942" height="530" />
<h2>How AesirX Consent Management Platform helps you stay compliant&nbsp;</h2>
AesirX CMP was built to address the exact compliance gaps exposed by CNIL’s rulings. Here’s how it works in practice: It blocks every non-essential tracker until consent is given, records each decision in verifiable logs, and keeps those records under the site owner’s control as first-party data.&nbsp;
This design avoids pre-consent leakage and provides the audit trail regulators expect. It means compliance is not just a banner but a working system that respects user choice at every stage.
The features below show how AesirX CMP delivers the enforcement regulators demand in practice:
<div class="table-responsive">
<table class="table table-bordered">
<tbody>
<tr class="bg-primary-stroke-2">
<td style="text-align: center;">&nbsp;&nbsp;Feature</td>
<td style="text-align: center;">Benefit</td>
</tr>
<tr>
<td>
AesirX CMP
</td>
<td>
<a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">Blocks everything non-essential until consent is given.</a>
</td>
</tr>
<tr>
<td>AI Privacy Advisor</td>
<td>Scans before and after consent, detects all unauthorized tracking, and blocks it from the first page load.</td>
</tr>
<tr>
<td> 1-Click AI Auto-Blocking</td>
<td>
Apply blocking rules in one click with AI setup to block non-essential tracking for GDPR/ ePD 5(3).
</td>
</tr>
<tr>
<td> Audit-Ready Logs</td>
<td>
Log every consent, rejection, and withdrawal with timestamps, export reports, and optional anchor records on blockchain for tamper-resistant verification.
</td>
</tr>
<tr>
<td> Region-Based Rules</td>
<td>
Adapt consent logic by region, time zone, browser language, or GPC signals; choose opt-in, opt-out, or hybrid models.
</td>
</tr>
<tr>
<td> Cookie Declaration &amp; Privacy Policy Generator</td>
<td>
Generate editable templates based on actual scan data to match your live site setup.
</td>
</tr>
<tr>
<td> Category-Based Tracking Control</td>
<td>
Let users consent to specific (and clear) categories such as Analytics, Advertising, Functional, or Custom so you meet granular consent requirements under privacy laws.
</td>
</tr>
<tr>
<td> ID Verification</td>
<td>
Verify a user's age or country using ZKPs and digital wallets without revealing personal data or creating a tracking trail.
</td>
</tr>
<tr>
<td>Customizable Consent Banners</td>
<td>
Edit banners in 40+ languages, choose from templates, and tailor text to your site's tone and UX.
</td>
</tr>
</tbody>
</table>
</div>
These safeguards highlight the difference between banners that look compliant and systems that actually enforce it.
<h2>How to get AesirX CMP for WordPress</h2>
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/aesirx-cmp-lifetime-deal-exclusive-to-appsumo.jpg" alt="aesirx cmp lifetime deal exclusive to appsumo" width="1300" height="740" />
AesirX CMP: Lifetime deal exclusive to AppSumo
Most CMPs on the market charge $50–$100 per month based on site traffic – over €1,200 per year for a single domain, often without delivering full compliance. AesirX offers a different choice: with the current AppSumo Lifetime Deal, WordPress site owners pay once from just $69 for 1 domain (saving up to 79%) and own the CMP forever, with no recurring bills, no visitor limits, and all future updates included.
It’s a permanent, regulation-ready consent management solution that you own outright, built to keep your site compliant without draining your budget.
<a href="https://appsumo.com/products/aesirx?utm_source=partner-link&amp;utm_medium=referral&amp;utm_campaign=partner-246752" target="_blank" rel="noopener">Get the Lifetime Deal on AppSumo</a>

France’s CNIL fined Google €325M and Shein €150M for consent breaches. Learn what changed and how to ensure your CMP enforces valid user consent.

CNIL fines spotlight Google: consent must be enforced, not optional

CNIL Hands Record Fines to Google (€325m) and Shein (€150m): User Consent Cannot be Ignored

Blog Consent Management Platform

France’s CNIL fines Google €325m and Shein €150m over consent violations. Here’s what changed – and how to make your CMP truly enforce consent.

AesirX Affiliate2Earn Program

How It Works

Share Your Link

Referral Signs Up

You Get Rewards

Affiliate Commission Rates

Share2Earn Solutions and Services

Consent Management Platform

Analytics

First-Party Server

Privacy Scanner

Privacy Review

Privacy Monitoring

E-Commerce Scanner

First-Party Product Suite

Alliance for Compliance

Share2Earn Content

Respect Over Retargeting: How “Permanent Block” Ends Unnecessary Third-Party Collection

AesirX CMP for WordPress v2.0.2: Stop the Phone-Home. Permanently.

If It’s Not Okay Offline, It’s Not Okay Online

The Correlation and Value of Consent and Zero-Knowledge Proofs

AesirX Customer Overview: The Agency Dashboard for Privacy-First Client Management

Vietnam’s PDPL - Key Changes in the Draft Implementing Decree (Consultation, Sept 2025)

Simplify Without Surveillance: What the EU’s Digital Omnibus Must Do About “Cookies”

AesirX CMP for WordPress v2.0.1: New CryptoX Wallet on iOS and Android for Age and Country Verification

Pseudonymization after SRB and Deloitte

CNIL Hands Record Fines to Google (€325m) and Shein (€150m): User Consent Cannot be Ignored

Referral Link

Share On Social Media

Revenue

NoData

Commission

No Data