<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”

Blog Aesirx

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

Blog Press Release Aesirx

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 CMP

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.

CNIL Hands Fines to Google: Consent Can’t be Ignored

<ul>
<li aria-level="1">Denmark: 81/98 non-compliant (82.7%)</li>
<li aria-level="1">Sweden: 264/288 non-compliant (91.7%)</li>
</ul>
This is the public sector - the benchmark the rest of us are supposed to follow. Instead, cookies, pixels, and beacons fire on first load. Residents don’t get a real choice; their browsers do the choosing for them.
EU ePrivacy Directive Article 5(3) requires consent before storing or accessing information on a user’s device including reading existing identifiers via cookies, localStorage / sessionStorage / IndexedDB or causing device access through pixels/beacons.&nbsp;
The “strictly necessary” exception is narrow (e.g., essential session continuity or load-balancing) and does not cover analytics, advertising, convenience tags or telemetry for CMP invoicing. If you access the device before consent, you’re outside the law.
“A school lunch page loads - and a tracking pixel fires before the allergy notice even appears.”
<h2>How we measured</h2>
During Aug-Sep 2025, we examined the homepages of all 98 DK and 288 SE municipalities. We captured evidence of (1) device access (cookies/localStorage and similar), (2) third-party calls (pixels/beacons), and (3) the order in which these fired relative to any consent interface. Our procedure mirrors the EDPS Website Evidence Collector approach: parameterized, automated collection with reproducible outputs.
<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/public-sector-privacy-hypocrisy-sovereignty-vs-default-telemetry.png" alt="public sector privacy hypocrisy sovereignty vs default telemetry" width="2540" height="1421" />
<h2>What the data shows</h2>
<ul>
<li aria-level="1">Denmark (n=98): 81 non-compliant (68 high risk, 13 medium, 17 low). Aggregate signals observed on homepages: 99 cookies and 359 beacons.</li>
<li aria-level="1">Sweden (n=288): 264 non-compliant (219 high, 45 medium, 23 low). Aggregate signals: 93 cookies and 1,234 beacons.</li>
<li aria-level="1">Pattern: tracking technologies often initialize before consent is collected, or banners only block some technologies while others fire.</li>
</ul>
Now the part that should make everyone uncomfortable:
<h2>Sovereignty we say vs. telemetry we ship</h2>
Every week, boards and councils debate European independence from U.S. Big Tech. We talk about jurisdiction, cloud strategy, “digital self-determination.” Then we go home and let our municipal websites beam resident data straight into those same ecosystems on page load.
That’s not strategy. That’s muscle memory-default scripts, default tags, default vendor kits. It’s a reflex that says “we’ll fix it later” while every visit leaks a little more telemetry to companies we claim we need independence from. When schools, health pages, and citizen portals do this, it isn’t abstract. It’s children’s devices, patients’ devices, elderly citizens’ devices-turned into data sources before they’ve even seen a meaningful choice.
The hypocrisy undermines trust. You can’t credibly call for digital sovereignty on Monday and outsource telemetry by default on Tuesday. If independence matters in policy, it must matter in code.
“Sovereignty isn’t a press release; it’s what your website does in the first 300 milliseconds.”
<h2>Who must act</h2>
<ul>
<li aria-level="1">Denmark&nbsp; -&nbsp; Datatilsynet (DPA): investigate and enforce where necessary; Digitaliseringsstyrelsen (Agency for Digital Government): issue a hands‑on baseline, architectures, and procurement standards municipalities can follow.</li>
<li aria-level="1">Sweden&nbsp; -&nbsp; IMY: supervisory authority ensuring GDPR and related rules are followed; Digg - Myndigheten för digital förvaltning (Agency for Digital Government): issue a hands‑on baseline, architectures, and procurement standards municipalities can follow.</li>
</ul>
“Publish and enforce a block‑by‑default before consent baseline that covers all device access and outbound calls - not just classic cookies.”
<h2>What “good” looks like&nbsp;</h2>
<ol>
<li aria-level="1">Block everything before consent. Cookies, pixels, localStorage, sessionStorage, IndexedDB, fingerprinting, SDKs - nothing fires until the person clearly opts in.</li>
<li aria-level="1">Keep “strictly necessary” narrow. Core session continuity or uptime only; never a backdoor for analytics or ads.</li>
<li aria-level="1">Make the choice real. No nudging, no pre‑ticked boxes, no “banner theater.”</li>
<li aria-level="1">Prove it. Maintain auditable logs showing initialization order and that nothing fired pre‑consent.</li>
<li aria-level="1">Procure for compliance by design. Reward suppliers who demonstrate pre‑consent blocking across tags/scripts and provide evidence.</li>
</ol>
<h2>Why this matters beyond homepages</h2>
If municipalities can’t keep first‑load tracking under control on the simplest public touchpoint, how will we credibly govern AI procurement, health data, education platforms, and cross‑border cloud? Trust dies from small cuts: one pixel here, one SDK there - all before consent. Multiply by millions of sessions.
Denmark and Sweden can lead here. We already lead on digital government. But leadership isn’t what you pledge at conferences; it’s what your homepage does when a resident arrives. Right now, 4 in 5 Danish municipal sites and 9 in 10 Swedish ones fail that basic test. If we truly believe in European independence from Big Tech and foreign clouds, we should start where trust begins: the first visit to a public website.
Digitaliseringsstyrelsen, IMY, municipalities: publish and enforce a national baseline - block-by-default before consent for all device access and outbound calls.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Public Sector Privacy Hypocrisy: Sovereignty vs. Default Telemetry

4 in 5 Danish and 9 in 10 Swedish municipal sites load trackers before consent. Public sector sites should lead by example, not bypass privacy rules.

Public Sector Privacy Hypocrisy: Sovereignty vs. Telemetry

Cookiebot just raised the Small Premium plan from €15 to €30 per month for 1 domain and reduced limits for subpages and page views. If your bill doubled while your allowance shrank, it is time to switch.
AesirX CMP is first-party, blocks all tracking before consent, and takes minutes to set up. Our standard price is $9 USD per month for one domain with a 14-day free trial. Right now, we also offer a limited AppSumo Lifetime Deal from $69 USD.
<a href="https://appsumo.com/products/aesirx/?utm_source=partner-link&amp;utm_medium=referral&amp;utm_campaign=partner-246752" target="_blank" rel="noreferrer noopener" class="fw-semibold py-13px px-4 lh-sm text-white btn btn-success" tabindex="0" role="button">Get AesirX CMP now</a>
Example result from a recent WordPress site:&nbsp; installed at noon, live and fully configured less than 5 minutes later, blocked 21 non-essential trackers before consent on a 30k page site - saving $1,000+ per year.&nbsp;
<h2>The 5 WordPress reasons to switch to AesirX CMP&nbsp;</h2>
<h3>1. Privacy built into your site</h3>
No third party consent pixels or billing telemetry on your visitors’ devices before consent. Built to respect <a href="https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf">ePrivacy Directive 5(3)</a> from the first request.
<h3>2. It blocks all tracking, not just cookies</h3>
Full coverage for cookies and beacons, including pixels, telemetry, and fingerprinting. Nothing loads until explicit, informed consent. This is real technical enforcement. Not theatre.
<h3>3. AI Privacy Advisor handles the hard parts</h3>
AI scans your site pre and post consent, identifies what actually tracks, categorizes it, and proposes a one-click block list. It also drafts your cookie declaration, privacy policy, and consent text based on what it finds. You approve and publish.
<h3>4. Made for WordPress, easy setup</h3>
One-click install from WP Admin. One-click configuration to apply AI recommendations. Consent logs and documents live in WordPress. No external dashboard to manage.
<h3>5. Predictable pricing that you control</h3>
Standard price is $9 USD per month for one domain with a 14-day trial. Prefer to be done with monthly bills. The AppSumo Lifetime Deal is from $69 USD is a single purchase, and we are running it only once.
<h2>What changed at Cookiebot in 2025</h2>
<ul>
<li aria-level="1">Small Premium moved from €15 to €30 per month for 1 domain.</li>
<li aria-level="1">Lower limits for subpages and page views per month.</li>
<li aria-level="1">Higher risk of auto re-tiering when your site grows.</li>
</ul>
If your WordPress site sits near a threshold, a new category, a blog sprint, or user-generated content can trigger a higher tier. That is budgeting pain you do not need.
<h2>Compliance that holds up when it counts</h2>
Many CMPs add their own pixels or tracking to handle billing and reporting. That is not technically required for your service – it is simply vendor convenience. AesirX follows strict opt-in rules. We pause everything non-essential before consent. We also hold Google Tag Manager entirely until explicit consent is given by the visitor. Some setups with Consent Mode 2.0 allow signals before consent. That approach doesn’t meet strict opt-in requirements for many EU implementations. AesirX prevents pre-consent leakage by design and keeps all consent decisions on your own domain.
For the full legal reasoning and why GTM must wait for consent, read The Legal Fiction Of Technical Necessity, CMPs, And GTM: <a href="https://aesirx.io/blog/aesirx/the-legal-fiction-of-technical-necessity-cmps-and-gtm">https://aesirx.io/blog/aesirx/the-legal-fiction-of-technical-necessity-cmps-and-gtm</a>
<h2>AesirX CMP vs Cookiebot</h2>
<div class="table-responsive">
<table class="table table-bordered fs-6">
<tbody>
<tr>
<td style="text-align: center;">
Capability
</td>
<td style="text-align: center;">
AesirX CMP 
</td>
<td style="text-align: center;">
Cookiebot 
</td>
</tr>
<tr>
<td>Small plan cost</td>
<td>$9 USD per month for 1 domain.</td>
<td>€30 per month Small Premium for 1 domain.</td>
</tr>
<tr>
<td>Pricing predictability</td>
<td>High. First-party. No telemetry quotas.</td>
<td>Lower. Counts and limits create surprise jumps.</td>
</tr>
<tr>
<td>Subpage and page view limits</td>
<td>None for blocking and logging.</td>
<td>Reduced limits on Small Premium.</td>
</tr>
<tr>
<td>Auto re-tiering</td>
<td>No</td>
<td>Yes when thresholds are crossed.</td>
</tr>
<tr>
<td>First-party architecture</td>
<td>Yes</td>
<td>Third-party hosted service.</td>
</tr>
<tr>
<td>Blocks cookies and beacons</td>
<td>Yes on the first page load.</td>
<td>Varies by configuration and limits.</td>
</tr>
<tr>
<td>1Click AI blocking</td>
<td>Yes via AI Privacy Advisor.</td>
<td>Manual categorization common on custom setups.</td>
</tr>
<tr>
<td>Policy generation</td>
<td>Draft cookie declaration, privacy policy, consent text.</td>
<td>Templates for cookie declaration.</td>
</tr>
<tr>
<td>WordPress setup</td>
<td>One-click install in WP Admin.</td>
<td>Script or plugin with manual tuning.</td>
</tr>
<tr>
<td>Languages</td>
<td>Uses languages already installed on your WP site.</td>
<td>Multi language via vendor settings.</td>
</tr>
<tr>
<td>Banner styling</td>
<td>CSS styling supported if needed.</td>
<td>Template driven styling.</td>
</tr>
<tr>
<td>Lifetime available</td>
<td>Yes. One-time from $69 USD.</td>
<td>No</td>
</tr>
</tbody>
</table>
</div>
&nbsp;*Prices/limits as of Aug 2025
Get AesirX CMP - 14-day free trial or <a href="https://appsumo.com/products/aesirx/?utm_source=partner-link&amp;utm_medium=referral&amp;utm_campaign=partner-246752" target="_blank" rel="noopener">lifetime deal on AppSumo</a>&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/AesirX_Consent_Management_Platform.jpg" alt="AesirX Consent Management Platform" width="1201" height="631" />
<h2>5 minute migration for WordPress</h2>
<ol>
<li aria-level="1">Install WP plugin</li>
<li aria-level="1">Run AI Privacy Advisor scan</li>
<li aria-level="1">Apply 1-Click Auto Blocking</li>
<li aria-level="1">Publish drafted cookie declaration and privacy texts</li>
<li aria-level="1">Verify key pages and go live</li>
</ol>
Notes
<ul>
<ul>
<li aria-level="1">Consent Banner is fully customizable in CSS.</li>
<li aria-level="1">Languages follow the languages already installed on your WordPress site.</li>
<li aria-level="1">Download the WP Plugin here:<a href="https://github.com/aesirxio/wordpress-consent-plugin/releases/download/2.0.0/plg_aesirx_consent.zip." target="_blank" rel="noreferrer noopener" class="fw-semibold ms-3 py-10px px-4 fs-7 lh-sm text-white btn btn-success text-success" tabindex="0" role="button">AesirX CMP WordPress Plugin</a></li>
</ul>
</ul>
<h2>Bonus capability for regulated content</h2>
Need to gate content or products by age or country. Enable privacy preserving verification that proves attributes without exposing identities. Use it when regulation requires checks. Keep it off when you do not need it.
Example result from a recent WooCommerce site: A Danish alcohol e-commerce platform needed age verification to comply with Danish laws, the competitors wanted monthly subscriptions and payment of DKK 0,50 to 0,90 per verification and introduced both “phone home” and linkability issues so the usage could be tracked and monitored by 3rd party suppliers and ID credential issuer, AesirX CMP offers free Age Verification with privacy protection - savings $5000+ per year.&nbsp;
<h2>First-party consent for WordPress: Built to Fit with AesirX</h2>
<ul>
<li aria-level="1">One-click install.</li>
<li aria-level="1">One-click configuration with <a href="https://aesirx.io/privacy-advisor-ai" target="_blank" rel="noopener">AI Privacy Advisor</a>.</li>
<li aria-level="1">Full support for all tracking technologies including cookies and beacons.</li>
<li aria-level="1">First-party by design with audit ready consent logs and exports.</li>
<li aria-level="1">Content and disclosures managed inside WordPress.</li>
<li aria-level="1">Often faster pages because non-essential scripts never load before consent.</li>
<li aria-level="1">Pricing that does not jump when you publish more pages.</li>
</ul>
<h2>Quick maths</h2>
<ul>
<li aria-level="1">Cookiebot Small Premium at €30 per month vs AesirX Lifetime at $69 USD Break even in 2 months. Note: AppSumo lifetime purchases can be canceled at any time [AppSumo refund terms apply].</li>
<li aria-level="1">Prefer monthly? AesirX is $9 USD per month, per domain with a free 14-day trial. On-going savings of €20+ per month.</li>
</ul>
<h2>Cookiebot alternative for WordPress: FAQs</h2>
<h3>1. Will AesirX really stop everything before consent</h3>
Yes. Non-essential cookies and non-essential beacons are blocked on the first page load. Only essentials you whitelist will run before consent.
<h3>2. Do I need to be technical to set this up</h3>
No. Install the plugin, run AI Privacy Advisor, click to apply the rules, and publish the drafted texts. No code required.
<h3>3. What exactly gets blocked before consent</h3>
All non-essential cookies and all non-essential beacons including pixels, telemetry, and fingerprinting. Essentials you explicitly whitelist can run.
<h3>4. How does this differ from Consent Mode 2.0 and GTM</h3>
AesirX holds GTM until explicit consent. After consent, allowed tags run. This avoids pre consent signals and aligns with strict opt-in obligations in the EU.
<h3>5. Will this slow down my site</h3>
AesirX is first-party and lightweight. Blocking non-essential trackers before consent often improves performance because unwanted scripts never load.
Claim the <a href="https://appsumo.com/products/aesirx/?utm_source=partner-link&amp;utm_medium=referral&amp;utm_campaign=partner-246752" target="_blank" rel="noopener">Lifetime Deal from $69 USD</a> or <a href="https://appsumo.com/products/aesirx/?utm_source=partner-link&amp;utm_medium=referral&amp;utm_campaign=partner-246752" target="_blank" rel="noopener">start a 14-day trial</a>

Why WordPress Sites Are Leaving Cookiebot In 2025 And Choosing AesirX CMP

WordPress sites are leaving Cookiebot as prices rise. Switch to AesirX CMP offering first-party consent, $9 plans, or a lifetime deal from $69.

Cookiebot Alternative for WordPress | AesirX CMP

Will AesirX really stop everything before consent?

Do I need to be technical to set this up?

What exactly gets blocked before consent?

How does this differ from Consent Mode 2.0 and GTM?

Will this slow down my site?

Cookiebot Alternative for WordPress First-Party AesirX CMP

TL;DR: Skip “chat control” (mass client-side scanning). Protect minors by gating surfaces of risk with verified ID: non-interactive ZK (local verify), issuer-silent, unlinkable, E2E intact – with court-ordered, event-specific unmasking when real harm is alleged.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Missed Part III?
Read: <a href="https://aesirx.io/blog/aesirx/contextual-uniqueness-private-proofs" target="_blank" rel="noopener">Part III – Contextual Uniqueness: Turning Private Proofs into Operational Trust</a>
</div>
Europe’s urgency to protect minors online is real - and correct. Denmark’s EU Council presidency has put youth safety at the top of the agenda: stronger age verification on platforms, tougher action against CSAM, even exploring a social-media ban for under-15s. The instinct is understandable. But one proposal keeps reappearing under different names – scanning everyone’s private messages on every device, all the time. That approach is often framed as “chat control.” It promises protection; in practice it builds a surveillance substrate we will never fully dismantle.
We need something better – something that makes abuse riskier and rarer without normalizing suspicion of every citizen. We already have it: verified ID with due-process accountability, delivered with non-interactive zero-knowledge proofs and context-scoped pseudonyms (CuK + Shield of Privacy). It is safety without mass scanning.
Note: CuK is currently under development in partnership between AesirX and Concordium.
<h2>What we’re being asked to trade and why we shouldn’t</h2>
Scanning all chats on all devices sounds simple. It isn’t. To work at all, client-side scanning has to pierce end-to-end encryption or pre-screen messages before they’re encrypted. It accumulates false positives that drown investigators and devastate families. It invites function creep: today CSAM, tomorrow “extremism,” the next day anything a government finds uncomfortable. It is the classic overbroad measure: collect everything now, promise restraint later.
And crucially, it doesn’t address the most common entry points of harm: the places where grooming begins, where minors are reachable at scale, where pseudonymous abusers can operate with no consequences. That is where a verified-ID model changes the maths.&nbsp;
We keep end-to-end encryption intact. We don’t scan content. We gate discovery, first contact, amplification, and payouts with private, issuer-silent attribute proofs. Private messages stay private; accountability triggers only when a court targets a specific event.
<h2>The better foundation: proofs, not profiles – accountable by due process</h2>
From Part I, we shifted the question from “Who are you?” to “Is this specific condition true?” – 13+, in-country, one human (not a bot). From Part II, we made that work at web scale with non-interactive ZK: verification happens locally, issuers are not called back, and proofs are unlinkable across sites. From Part III, we turned privacy into operations: CuK gives the site a context-scoped pseudonym that’s useful only in that setting, while Shield of Privacy keeps UX fast and issuer-silent. When serious harm occurs, identity can be revealed only under a lawful, court-supervised process – no backdoors.
That architecture delivers what broad scanning never can: privacy by default, accountability when needed, and a credible deterrent for would-be abusers.
Policy baseline
<ol>
<li aria-level="1">Local, issuer-silent verification with zero-knowledge proofs</li>
<li aria-level="1">Pairwise, context-scoped CuK pseudonyms per site, action, time window</li>
<li aria-level="1">Scheduled revocation via anonymous lists or accumulators, no per-user callbacks</li>
<li aria-level="1">Optional hash-only, event-scoped anchors for due-process accountability</li>
<li aria-level="1">We do not scan devices or weaken end-to-end encryption</li>
<li aria-level="1">We do not store profiles, cross-site identifiers, or raw proofs</li>
</ol>
<h2>How verified ID reduces abuse in the places that matter</h2>
Abuse usually doesn’t spring from a single private message; it starts where bad actors find and select minors. The verified-ID model hardens those surfaces:
<ul>
<li aria-level="1">Discovery surfaces become age-bounded. Youth spaces are truly for youth; adult-only areas are sealed. An adult cannot enter a minors-only forum under a fresh throwaway account; the gate demands an attribute the abuser cannot privately satisfy.</li>
<li aria-level="1">Contact surfaces gain a human-only switch. Mass sockpuppetry and automated outreach fall away when each pseudonym must map to one human.</li>
<li aria-level="1">Risky actions require verified status. New listings, mass DMs, and payout triggers are gated by proofs. It’s not just “prove 18+”; it's to prove eligibility before you can reach many minors or move money.</li>
<li aria-level="1">Accountability raises costs. Under due process, a specific event can be unmasked. Bad actors know their actions are private until they harm – and then traceable. That alone removes the lowest-effort predators and repeat offenders.</li>
</ul>
This is targeted friction: it protects minors where the harm originates while leaving ordinary, lawful private chats unscanned and encrypted.
<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/what-the-lawful-path-actually-looks-like.jpg" alt="what the lawful path actually looks like" width="1885" height="1061" />
<h2>What the lawful path actually looks like</h2>
The fear is that “accountability” becomes a euphemism for backdoors. In our model, it doesn’t. Day-to-day, people are pseudonymous and private. A site verifies a YES/NO answer and logs only a verdict + timestamp.&nbsp;
If there is credible evidence of abuse, authorities can seek a court order tied to a specific event, for example:
<ul>
<li aria-level="1">“The 13+ proof used to initiate contact at time T on domain D.” Using the hash-only fingerprint anchored on Concordium, the verifier supplies its presentation record for that event.&nbsp;</li>
<li aria-level="1">The identity issuer confirms that a valid credential exists; designated privacy guardians complete an N-of-M disclosure under court supervision.&nbsp;</li>
</ul>
There is no issuer usage log to query, no generalized switch to flip – only a narrow, auditable unmasking for that one incident.
Compare that with chat control: everyone pre-screened, all the time, with inevitable drift in scope. One is constitutional guardrails; the other is perpetual pre-investigation.
<h2>Why this aligns with Denmark’s goals</h2>
Denmark’s presidency priorities – age verification across platforms, real action on CSAM, and curbing youth harm – are exactly what a verified-ID model advances:
<ul>
<li aria-level="1">Age verification, done right. Proofs of 13+ or 18+ without identity exposure or issuer telemetry.</li>
<li aria-level="1">CSAM prevention at the front door. Reduce the chance that adults reach minors in the first place; make high-reach actions provably human and age-appropriate.</li>
<li aria-level="1">Lawful enforcement, not indiscriminate scanning. When a police report exists, courts can unmask a specific event. That’s accountability with guardrails.</li>
<li aria-level="1">No blanket ban required. A verified-ID web can enforce minor-only and adult-only spaces, and can region-limit content – without hauling everyone’s private messages into government-mandated scanners.</li>
</ul>
This is a safety model that scales and respects rights.
<h2>What platforms actually implement (and what they stop collecting)</h2>
A platform operator turns this on at the surfaces with the highest harm-to-reach ratio: sign-ups, first DM, listing creation, payment initiation. The code asks a narrow question via AesirX CMP; the wallet returns a non-interactive proof; the site verifies locally and receives a CuK that is meaningful only here and now. No identity is stored. No issuer is called. If operators need an audit breadcrumb for due process, they anchor a hash-only fingerprint – never a dossier.
What disappears from the data exhaust: bulk identity uploads, third-party beacons in consent/verify, cross-site identifiers, and the temptation to build shadow profiles “just in case.” What appears in the abuse pipeline: fewer opportunities to reach minors at scale, and higher-quality leads tied to specific events when things go wrong.
<h2>A policy blueprint Denmark and the EU can adopt</h2>
A workable regulation can be written in plain language:
<ul>
<li aria-level="1">Prohibit generalized scanning of private communications.</li>
<li aria-level="1">Require attribute-based verification (age, eligibility, human-only) for high-risk online actions affecting minors.</li>
<li aria-level="1">Mandate issuer-silent verification (no callbacks at proof time) and unlinkability across relying parties.</li>
<li aria-level="1">Allow due-process unmasking of specific events with court orders and independent oversight (transparency reports, N-of-M governance).</li>
<li aria-level="1">Demand first-party execution of consent and verification – no third-party trackers in the flow.</li>
<li aria-level="1">Encourage privacy-preserving status checks (anonymous lists/accumulators) and hash-only audit anchors.</li>
</ul>
This gives law enforcement precision and platforms clarity, while citizens keep the privacy the EU Charter promises.&nbsp;
Measure it: track drops in minor-targeted first-contact attempts, spam, chargebacks, and moderator hours; track improvements in law-enforcement lead quality tied to event-specific anchors.
<h2>Necessity and proportionality</h2>
This model asks only what a specific action requires, proves it locally, and exposes no identity by default. Processing is minimal: a verdict and timestamp, scheduled status checks, and an optional hash-only anchor for that event. End-to-end encryption remains intact. When serious harm is alleged, identity disclosure is limited to the named event under a court order, with published court-signer lists and N-of-M guardians. There is no bulk telemetry and no reuse across services. Effectiveness is measured by drops in first-contact attempts and abuse, with transparent reporting and routine key rotation.
<h2>The choice in front of us</h2>
We can build a Europe where minors are measurably safer online and private speech remains private. Or we can normalize a scanner on every device and hope it’s never misused. Verified ID with due-process accountability – proofs, not profiles; private by default, unmaskable by court order – meets Denmark’s goals without crossing the line.
If you run a platform: start where harm hits hardest – first contact and first amplification. Gate those actions with attribute proofs. Log verdicts, not identities. If you write policy: require issuer-silent verification and narrow unmasking – and make generalized scanning out of bounds. If you’re a parent: ask platforms one question – Do you verify attributes privately, or do you scan my child’s messages?
The way forward is clear: safety without mass surveillance. That’s how we protect children and keep the web human, even as automated traffic rises.
<a href="https://www.linkedin.com/in/ronnikc/" target="_blank" rel="noopener">Ronni K. Gothard Christiansen</a> Technical Privacy Engineer &amp; CEO, <a href="http://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Verified ID with AesirX CMP offers child safety without mass chat scanning: proofs not profiles, E2E intact, lawful unmasking only when courts require.

Safety Without Mass Scanning: A Verified-ID Path the EU

Part IV – Safety Without Mass Scanning: A Verified-ID Path for Denmark and the EU

Protect minors without mass scanning: verified ID using ZK proofs, E2E encryption intact, private by default, court-ordered unmasking for specific events.

Safety Without Mass Scanning: The EU’s Verified ID Approach

TL;DR: CuK + Shield of Privacy make non-interactive ZK proofs usable at scale - local verify, issuer-silent, and pairwise-unlinkable with an auditable breadcrumb when lawfully required.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Missed Part II?
Read: <a href="https://aesirx.io/blog/aesirx/zk-proofs-for-a-human-only-privacy-first-web" target="_blank" rel="noopener">Part II – ZK Proofs for a Human-Only, Privacy-First Web</a>
</div>
<a href="https://aesirx.io/blog/aesirx/the-web-after-bots-and-ai-how-we-keep-it-human" target="_blank" rel="noopener">In Part I, we made the case for a different web:</a> one where communities and markets ask for proofs, not profiles – “18+?”, “in-country?”, “one human?” – and get a cryptographic YES/NO instead of a dossier. <a href="https://aesirx.io/blog/aesirx/zk-proofs-for-a-human-only-privacy-first-web" target="_blank" rel="noopener">In Part II, we showed the backbone that makes this real at web scale</a>: non-interactive zero-knowledge proofs (NIZK) so verification is local, issuer-silent, and unlinkable by design&nbsp;with accountability using Concordium's Idp-based model.
This final part answers the question every operator asks when the cryptography fades and the dashboards appear: How do we run that privacy promise day-to-day – fast for good users, auditable when it matters, and impossible to bend into tracking?&nbsp;
The answer is Contextual Uniqueness – implemented in AesirX as a tiny, disposable pseudonym called the Contextual Uniqueness Key (CuK) and a lightweight client component, the Shield of Privacy (SoP). CuK gives a site just enough to recognize this proof in this context, while refusing to be useful anywhere else.&nbsp;Shield of Privacy (SoP) is the lightweight client component that derives and manages CuKs in the browser, entirely client-side.
Note: CuK is currently under development in partnership with Concordium.
<h2>What “context” really means (and why it matters)</h2>
When we say context, we mean a precise tuple – (relying party, action, time window, policy scope). A forum gating DMs is a different context from a marketplace gating listings; a Danish content release is a different context from a US one.
CuK is derived on the user’s device from inputs that reflect that context. Conceptual derivation:
Context tuple for CuK derivation
<ul>
<li aria-level="1">RP origin salt (pairwise, origin-bound)</li>
<li aria-level="1">Action/purpose (e.g., “create_account”, “post_dm”)</li>
<li aria-level="1">Time-window nonce (limits replay)</li>
<li aria-level="1">Policy fingerprint (optional, binds local policy)</li>
</ul>
CuK = H( proof_hash ∥ rp_salt ∥ action ∥ window_nonce [ ∥ jurisdiction/policy ] )
<ul>
<li aria-level="1">proof_hash: the outcome of the NIZK (“18+”, “in DK”), not identity.</li>
<li aria-level="1">rp_salt: a value bound to the relying party (e.g., canonical eTLD+1), so two sites never see the same pseudonym.</li>
<li aria-level="1">action: the gated surface (sign-up, DM unlock, listing, payout).</li>
<li aria-level="1">window_nonce: a fresh value for temporal uniqueness and replay resistance.</li>
<li aria-level="1">jurisdiction/policy (optional): to isolate legally distinct flows.</li>
</ul>
Because CuK includes rp_salt and action, colluding sites can’t line up their logs and learn anything about a person. Because it includes a fresh window_nonce,&nbsp;from minutes to hours, configurable by policy, replaying an old event won’t work. And because it’s all hashed client-side, nothing personal leaves the device.&nbsp;
Verification runs locally, issuers remain silent, credentials stay in the wallet, CuK is context-scoped, and any on-chain anchoring is hash-only.
<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/contextual-uniqueness-key-cuk-verification-diagram.png" alt="contextual uniqueness key cuk verification diagram" width="1999" height="1206" />
Contextual Uniqueness Key (CuK) – Verification (Diagram 1)
<h2>The CuK lifecycle: from proof to practice</h2>
First arrival. The page asks a narrow question. The wallet generates a non-interactive proof locally. SoP derives CuK from the proof outcome and the current context, the site verifies the proof without contacting an issuer, authorizes the action, and logs a verdict with a timestamp – not an identity.
Optional anchoring. For auditability, the verifier can anchor a fingerprint of the event – hash(proof_hash ∥ CuK ∥ domain ∥ timestamp) – to Concordium. This creates an immutable breadcrumb that refers to an event, not a person: no raw proof, no PII, nothing reusable across properties.
<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/contextual-uniqueness-key-cuk-reuse-diagram.png" alt="contextual uniqueness key cuk reuse diagram" width="1834" height="1318" />
Contextual Uniqueness Key (CuK) – Reuse (Diagram 2)
Return visits. If the user comes back to the same site within a valid window, SoP can recognize an encrypted, origin-bound pseudonym in the browser and validate it client-side for instant entry. If nothing valid is present, the wallet flow runs again. Either way, there’s no issuer telemetry on normal use.
Change over time. People move countries and have birthdays. A fresh wallet proof simply leads to a new CuK; past pseudonyms don’t resurrect. If the gate is jurisdictional, the policy parameter is part of the derivation so each legal surface remains isolated.
<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/contextual-uniqueness-key-cuk-cross-site-use-diagram.png" alt="contextual uniqueness key cuk cross site use diagram" width="1999" height="1083" />
Contextual Uniqueness Key (CuK) – Cross-Site Use (Diagram 3)
<h2>Re-use without re-identification (opt-in, client-only)</h2>
Sometimes people want to skip the wallet step on other AesirX-enabled sites. Re-use is possible only on the user’s terms and it still refuses to become a universal handle.
When a user opts in, SoP creates a small encrypted token tied to the browser’s origin/keystore. On a new site, SoP computes:
CuK_new = H( token ∥ new_rp_salt ∥ action ∥ new_window_nonce )
The second site sees a valid, domain-scoped pseudonym that cannot be matched to the first. Clear storage or decline reuse and the system falls back to a fresh wallet proof. Convenience never eclipses unlinkability.
<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/contextual-uniqueness-key-cuk-reveal-by-court-supervision-diagram.png" alt="contextual uniqueness key cuk reveal by court supervision diagram" width="1999" height="832" />
Contextual Uniqueness Key (CuK) – Reveal by Court Supervision (Diagram 4)
<h2>Auditability without surveillance (the due-process path)</h2>
Privacy by default survives because accountability is narrow and lawful. Court orders and disclosure governance vary by jurisdiction; the model describes the intended due-process pattern. If a serious incident demands it, law enforcement targets a specific event – “the 18+ proof used on example.com at 15:03 UTC.” Using the anchored fingerprint, the verifier supplies its presentation record (challenge, response/commitment, time, domain). The issuer confirms credential validity, not a usage history.&nbsp;Designated privacy guardians, independent of issuer and verifier, complete an N-of-M disclosure under court supervision in the IdP-based model on <a href="https://www.concordium.com/solution/id-verification#protocol" target="_blank" rel="noopener">Concordium</a>. There’s no issuer usage logging, no corporate backdoor – only a precise unmasking for that one event.
<h2>Threat model and how the design holds</h2>
<ul>
<li aria-level="1">Colluding sites. Pairwise salts ensure CuKs are different across relying parties; anchors carry only hashed fingerprints. Collusion yields nothing linkable.</li>
<li aria-level="1">Issuer observability. Verification is local; issuers aren’t pinged at proof time. Revocation is checked via anonymous status lists or cryptographic accumulators that the client fetches on a fixed schedule; there are no per-user callbacks to the IdP, so the flow remains issuer-silent.</li>
<li aria-level="1">Replay &amp; theft. Window nonces and proof freshness make replays fail; reuse tokens are encrypted, origin-bound, and short-lived.</li>
<li aria-level="1">Script abuse. Consent and verification are first-party; CSP and origin binding keep third-party beacons out of the loop.</li>
<li aria-level="1">Data minimization. Verifier logs store verdict + timestamp, not identity; Anchors never contain raw proofs or PII; they are hash-only and scoped to a single event.</li>
</ul>
The net result: useful to an operator, useless to a surveillance graph.
<h2>Operating at the edge (performance that users feel)</h2>
Because proofs are non-interactive, verification can run at the CDN/edge with cached public parameters. P95 latencies remain low even on mid-range phones and bad connections. Status lists cache well; anchors are tiny. You get safety that feels instant and doesn’t leak.
<h2>Where teams go wrong (and how not to)</h2>
<ul>
<li aria-level="1">Reusing global IDs. If your app tries to “help itself” by storing a user identifier, you’ve undone unlinkability. Treat CuK as disposable, context-scoped truth.</li>
<li aria-level="1">Issuer callbacks in production. If verification calls back to an issuer, you’ve built a locator beacon. Keep verify local; refresh status anonymously on a schedule.</li>
<li aria-level="1">Logging more than verdicts. If you store proofs or PII, you’ll inherit breach and compliance risk with no benefit. Log the decision and the time – nothing else.</li>
<li aria-level="1">Third-party scripts in consent/verify. Run it first-party or you’ll leak the very moments privacy law cares about most.</li>
<li>Salt management hygiene. Rotate rp_salt when changing domains/tenants.</li>
</ul>
<h2>How Part I, II, and III fit together</h2>
<ul>
<li aria-level="1"><a href="https://aesirx.io/blog/aesirx/the-web-after-bots-and-ai-how-we-keep-it-human">Part I set the stakes and the operating model</a>: verify the attribute, not the person.</li>
<li aria-level="1"><a href="https://aesirx.io/blog/aesirx/zk-proofs-for-a-human-only-privacy-first-web" target="_blank" rel="noopener">Part II supplied the engine:</a> NIZK for local, issuer-silent, unlinkable proofs.</li>
<li aria-level="1"><a href="https://aesirx.io/blog/aesirx/contextual-uniqueness-private-proofs" target="_blank" rel="noopener">Part III makes it run operationally</a>: CuK + SoP give each proof a context-scoped pseudonym for UX, rate-limits, and audits – without handing anyone a cross-site handle.</li>
</ul>
That’s the trilogy: why, how, and how it stays honest at scale&nbsp;- part IV will explain how we can avoid chat control by ID verification.
<h2>Age verification without surveillance</h2>
Ask the narrow question: 18+. The answer is produced locally in the IdP wallet as a zero-knowledge proof, and the flow remains issuer-silent. The browser, not the site, derives an origin-bound CuK for this action and time window. The site verifies locally, authorizes or denies, and discards the proof. No names, no addresses, no account numbers move. Anchors never contain raw proofs or PII; they are hash-only and per-event. Revocation relies on anonymous status lists or accumulators fetched on a schedule, never per-user callbacks. If real harm occurs, due-process unmasking is available: a court order, N-of-M privacy guardians, and a simple issuance confirmation by the IdP, with no usage logs.
Start where abuse hurts most: sign-ups, DM unlocks, listings, payouts. Measure pass rate, false positives, chargebacks, first-contact attempts, moderator hours, and law-enforcement lead quality tied to event-specific anchors. You reduce spam and fraud not by harvesting more data, but by asking only what policy requires.
The bots will keep rising. Surveillance will not save the web. Private verification that ships can. Keep people private and communities safe, and keep the web human.
<a href="https://www.linkedin.com/in/ronnikc/" target="_blank" rel="noopener">Ronni K. Gothard Christiansen</a> Technical Privacy Engineer &amp; CEO, <a href="http://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Ready for Part IV?
Read: <a href="https://aesirx.io/blog/aesirx/safety-without-mass-scanning-a-verified-id-path-the-eu" target="_blank" rel="noopener">Part IV – Safety Without Mass Scanning: A Verified-ID Path for Denmark and the EU</a>
</div>

AesirX explores Contextual Uniqueness: how zero-knowledge proofs and privacy keys build trust online without surveillance or tracking.

Contextual Uniqueness: Private Proofs

Part III – Contextual Uniqueness: Turning Private Proofs into Operational Trust

Contextual Uniqueness shows how zero-knowledge proofs can deliver trust online: private, auditable, and unlinkable by design.

Contextual Uniqueness for Privacy & Trust

Why Non-Interactive ZK Is the Right Backbone (and How It Works in Practice)
TL;DR: We use non-interactive ZK so sites get a private YES/NO - no issuer call-backs, no cross-site linkability.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Missed Part I?
Read: <a href="https://aesirx.io/blog/aesirx/the-web-after-bots-and-ai-how-we-keep-it-human" target="_blank" rel="noopener">Part I - The Web After Bots and AI: How We Keep It Human - Without Surveillance</a>
</div>
If a website only needs to know whether a visitor is 18+, in a given country, or one human behind a pseudonym, why should it see that person’s name, address, or a trail of where they’ve been?
The right answer is: it shouldn’t. That’s the promise of zero-knowledge proofs (ZK)&nbsp;- a way for a user’s wallet to prove a fact is true while revealing nothing else. The site receives a cryptographic yes/no, the user keeps their identity to themselves, and the issuer who created the credential isn’t pinged in the background every time it’s used.
This is the cryptographic foundation beneath the “verify the attribute, not the person” pattern we introduced in the main article. Today we’ll go deeper: what kinds of ZK exist, why non-interactive proofs are the right fit for the web, what actually prevents “phone-home” and cross-site linkability, and how all of this shows up in real products like <a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">AesirX CMP</a> with <a href="https://www.concordium.com/" target="_blank" rel="noopener">Concordium ID</a>.
<h2>A quick mental model: what ZK actually buys you</h2>
Think of verification as a question with a single, narrow answer. A site asks, “Is this user over 18?” A wallet replies with a proof – not with a document – and the site verifies that proof locally. If the proof checks out, the site learns only that the statement is true. It does not learn the user’s name, date of birth, credential number, or where that credential came from. Properly designed, the proof also doesn’t tip off the issuer that it was used. That’s the difference between compliance theater (“send me your ID”) and privacy engineering (“prove the exact property I need, nothing more”).
<h2>Interactive vs. non-interactive ZK: the distinction that changes everything</h2>
There are two broad ways to deliver these proofs:
<ul>
<li aria-level="1">Interactive proofs involve a back-and-forth with the verifier – a kind of cryptographic Q&amp;A. They’re useful in some protocols but imply a live session between the parties.</li>
<li aria-level="1">Non-interactive proofs (often abbreviated NIZK) are a single, self-contained message that the verifier can check on its own. No conversational round-trips are required.</li>
</ul>
For web-scale verification (especially on mobile), non-interactive proofs are the better fit. They make the experience fast and resilient: a site (or an edge worker/CDN) can verify a proof without contacting anyone else. This is the practical root of no phone-home. If verification doesn’t require a callback to the issuer, there’s no covert telemetry trail each time a user proves something about themselves.
This is exactly the model we implement: Concordium ID issues credentials the user holds in a wallet; AesirX CMP requests non-interactive proofs of specific attributes; and the site verifies those proofs locally. The outcome is a binary verdict the application can act on, plus a timestamp for auditability without harvesting identity or notifying the issuer.
<h2>“No phone-home” and unlinkability are architectural, not just cryptographic</h2>
It’s tempting to believe ZK alone guarantees privacy. In reality, the whole design must cooperate:
<ol>
<li aria-level="1">Verification happens locally. The verifier checks a proof against public parameters; no hidden calls are made to the issuer during verification. If you must refresh revocation or status, you fetch anonymous status lists or accumulators on a schedule – not per user.</li>
<li aria-level="1">Proofs are pairwise and context-scoped. A well-designed wallet generates proofs that are unique to each site or relying party. Even if two sites collude, they can’t correlate the same person across properties simply by comparing proofs.</li>
<li aria-level="1">Everything runs first-party. Consent and verification sit on your own domain, not behind third-party scripts or pixels. Users, auditors, and regulators can see what’s happening, and there’s no silent data exhaust.</li>
</ol>
With those rules in place, non-interactive ZK becomes the engine of private outcomes: fast checks, no issuer beacons, and unlinkability by construction.
If you’re wondering what this looks like in a production stack, here’s how Concordium implements the private YES/NO we’ve been talking about.
<h2>How Concordium’s ZK Works (and why it fits a private, human-only web)</h2>
Concordium’s identity layer is built so that a site can ask a narrow question - “13+?”, “18+?”, “resident in Denmark?” - and receive a cryptographic YES/NO without seeing the credential itself and without quietly pinging the issuer. The wallet holds the credential; the site receives a non-interactive zero-knowledge proof (NIZK) that can be verified locally. That “non-interactive” part is what enables no phone-home and fast, cacheable flows at web scale.
In practice, Concordium supports two proof patterns you’ll actually use in products:
<ul>
<li aria-level="1">Range proofs for things like age (e.g., “date of birth implies ≥ 13” or “≥ 18”).</li>
<li aria-level="1">Membership / non-membership proofs for policy checks (e.g., “country ∈ {DK, SE, NO, FI, IS}” or “not on a restricted list”).</li>
</ul>
Under the hood, these are constructed from well-known building blocks – commitments (e.g., Pedersen commitments) and sigma-protocol style proofs – with Bulletproofs used for efficient range and set proofs. The whole thing is made non-interactive via the Fiat–Shamir transform, so the verifier doesn’t need a live back-and-forth to check the proof. Result: quick verifies on the server or at the edge, and no issuer telemetry at proof time.
What the flow looks like: your backend states the question and challenge; the dApp asks the wallet; the wallet returns a presentation that contains the proof; your backend verifies it and applies your policy. The credential never leaves the wallet. What you log is a verdict with a timestamp – useful for audits and rate-limits, useless for profiling.
Why this preserves privacy in practice: verification is local (no callbacks to issuers), proofs are pairwise and context-scoped (unlinkable across relying parties), and revocation is handled via privacy-preserving status lists/accumulators fetched generically rather than per-user lookups. You get up-to-date checks without turning verification into a locator beacon.
Finally, Concordium couples privacy with due-process accountability. Day-to-day use is pseudonymous and private; in cases of credible fraud or harm, identity disclosure is possible only through a lawful, narrowly governed procedure. That governance lives beside the mathematics and keeps the system legitimate for communities, platforms, and policymakers.
“Concordium’s NIZK stack proves the fact, not the person - local verification, no phone-home, unlinkable by design - and backs it with a lawful path to accountability.”
With Concordium’s practical pattern in mind, let’s zoom back out to the broader toolkit – SNARKs, STARKs, and selective-disclosure schemes – and how to choose what fits your UX and governance.
<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/1_ZK_Proofs_That_Keep_The_Web_Human.jpg" alt="1 ZK Proofs That Keep The Web Human" width="1885" height="1061" />
<h2>SNARKs, STARKs, and selective disclosure: choosing a flavor without the hype</h2>
Once you choose the non-interactive route, you’ll encounter a zoo of acronyms. Here’s how to think about them without getting lost.
zk-SNARKs produce very small proofs that verify quickly – great for phones and for running verification at the edge. Many SNARK systems use a “trusted setup” or a universal setup, which needs to be handled with care: who ran it, how keys were managed, and how you rotate if needed. In return, you get tiny proofs and snappy UX.
zk-STARKs avoid trusted setup entirely and rely on transparent, hash-based assumptions that are often cited as stronger against prospective quantum attacks (with larger proofs as the trade-off). The trade-off is larger proofs and more bandwidth. For some applications, that’s perfectly acceptable; for others (low-end mobile on bad networks), you’ll want to measure carefully.
There are also selective-disclosure schemes such as BBS+ signatures and Bulletproofs. These are especially good when your credential contains many fields, but the site only needs to see that one property holds, say, “age ≥ 18” or “country = DK.” They typically sit between SNARKs and STARKs in proof size and performance. Many real systems combine these approaches: credentials that support selective disclosure, paired with a SNARK/STARK-style proof system where it makes sense.
The point isn’t to join a cryptography tribe; it’s to choose the tool that meets your UX and governance constraints. On the UX side, measure proof generation time on a mid-range Android phone, bandwidth on a bad connection, and verification latency at the edge. On the governance side, decide whether you prefer transparent, setup-free systems or whether a well-run universal setup is acceptable for the gains you get in proof size and speed. The technology lets you fine-tune those dials; your product and regulatory context decide where to set them.&nbsp;
In short: pick the scheme your users’ phones can handle, and the governance your risk team can defend.
<h2>Revocation without surveillance: the quiet make-or-break</h2>
A common pitfall in otherwise private designs is revocation – the need to invalidate a credential that’s expired or has been withdrawn. If the verifier has to ask the issuer, “Is this user still valid?” you’ve rebuilt a tracking system. The privacy-preserving pattern is to distribute status lists or cryptographic accumulators that can be fetched anonymously and cached. Verifiers learn the current status in general, not the status of a specific person, and users aren’t located at the moment of verification. Combined with short proof validity windows, you get up-to-date checks without pinging anyone about a specific user at a specific time.
<h2>How it feels in a real product</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/revocation-without-surveillance-the-quiet-make-or-break.jpg" alt="revocation without surveillance the quiet make or break" width="1885" height="1068" />
Imagine a teen joining a study forum that’s strictly 13+. The forum prompts, “Prove 13+.” The wallet constructs a non-interactive proof from a credential the teen already holds. The forum verifies the proof instantly – no calls to the issuer – and admits the user under a pseudonym. The forum logs only that a valid “13+” proof was presented at a particular time. No name. No school. No dossier. If someone later causes real harm, there is a separate, court-supervised process to unmask the pseudonym; that’s governance, not the default behavior.
Now transpose that flow onto marketplaces, messaging surfaces, and payment triggers. You gate the riskiest actions – new listings, bulk DMs, payouts – behind attribute proofs. You keep regular participation effortless. Spam and scams fall, moderator load declines, and you never built a surveillance stack to get there.
This is precisely how AesirX CMP integrates with Concordium ID. We request the narrow proof the context requires (age, country, or “one human”), verify it locally, and store a verdict – not an identity. Because the proofs are non-interactive and context-scoped, neither the issuer nor other sites learn anything from their use.&nbsp;
Local verify, issuer-silent, pairwise-unlinkable - by design.
<h2>Accountability that respects rights</h2>
Privacy by default does not mean abuser-proof. The architecture keeps users pseudonymous day-to-day, but if there’s credible evidence of fraud, harassment, or predatory behavior, a lawful, narrowly defined process exists to unmask the real-world identity behind a pseudonym. That unmasking is gated by due process – court supervision – not by moderator discretion or corporate backdoors. It’s the balance that convinces policymakers and communities to support privacy-preserving verification: power for good actors, consequences for bad ones.
<h2>What to test when you pilot</h2>
When you run your first pilot, measure the things that matter in practice rather than debating cryptography in the abstract. Watch proof generation time on mid-tier phones; watch verification latency at the edge; watch bandwidth impact the first time versus subsequent, cached visits. Track the operational deltas after you gate a surface: spam attempts, fake accounts, chargebacks, and moderator hours. If those numbers improve without collecting identity, you’ve proven the model in your environment.
<h2>Why we chose non-interactive ZK for AesirX CMP + Concordium ID</h2>
Our use cases – age, country, and “one human” checks at web scale – demand proofs that are fast, cacheable, and verifiable without contacting the issuer. That’s what non-interactive ZK delivers. We combine it with pairwise pseudonyms for unlinkability, status-list-based revocation for privacy, and first-party execution so consent and verification never leak to third parties. The result is simple: sites get a yes/no answer and an audit timestamp; users keep their privacy; issuers aren’t silently notified when credentials are used.
Most importantly, the pattern is deployable today. If you operate a community or a marketplace, start with one high-abuse surface – sign-ups, DMs, listings, or payments – gate it with attribute proofs, and store verdicts rather than identities. Expand after you see the drop in spam and fraud. You’ll reclaim your product from bots and bad actors without turning your users into data points.&nbsp;
<h2>Private by Default, Accountable by Due Process</h2>
Zero-knowledge proofs are the mathematics that let you prove a fact without exposing a person. Non-interactive proofs make that promise practical for the web: fast, private, and verifiable without phone-home. But the maths isn’t the whole story. Privacy comes from the complete design – pairwise, context-scoped proofs; revocation that doesn’t track; first-party execution; and a clear, narrow path for due-process unmasking when things go wrong.
That is the architecture we’ve chosen with AesirX CMP and Concordium ID. It’s how you keep communities safe, markets honest, and youth spaces truly youth-only, and keep the web human, even as automated traffic rises.&nbsp;
Ready to pilot? Gate one surface this week with <a href="https://aesirx.io/blog/press-release/aesirx-cmp-for-wordpress-v2-0-0-delivers-regulation-ready-age-and-country-verification-without-surveillance" target="_blank" rel="noopener">AesirX CMP v2.0.0</a>. You’ll feel the difference fast, and you won’t have to compromise on privacy to get there. <a href="https://www.linkedin.com/in/ronnikc/" target="_blank" rel="noopener">Ronni K. Gothard Christiansen</a> Technical Privacy Engineer &amp; CEO, <a href="http://aesirx.io">AesirX.io</a>
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Ready for Part III?
Read: <a href="https://aesirx.io/blog/aesirx/contextual-uniqueness-private-proofs" target="_blank" rel="noopener">Part III – Contextual Uniqueness: Turning Private Proofs into Operational Trust</a>
</div>

 Non-interactive ZK proofs give sites a private yes/no without tracking, callbacks, or linkability, keeping the web human and privacy-first.

ZK Proofs for a Human-Only, Privacy-First Web

Part II – ZK Proofs for a Human-Only, Privacy-First Web

Why non-interactive ZK (NIZK) is the right backbone for private verification - everything runs first-party, no linkability, no surveillance

ZK Proofs for a Safer, Human-Only Web

TL;DR: Verify attributes with ZK (age/country/human) for a private YES/NO – issuer-silent, unlinkable, and accountable by court order when real harm occurs.
There’s a quiet but decisive shift online: more traffic now looks like software than people – and it’s getting harder to tell the difference.
AI agents don’t sleep. They post, buy, resell, and impersonate at machine speed. If we do nothing, the default “user” won’t be a person – it’ll be software.&nbsp;
That’s the moment we’re in, and it demands a better foundation for trust.
This isn’t a call for more surveillance. It’s a call for better proof. Communities, markets, and families don’t need your identity dossier to stay safe; they need a narrow proof that answers a specific question – and nothing more.
<h2>From suspicion to proof: the trust recession we can fix</h2>
As bots multiply, everyday participation gets taxed by suspicion. Moderators burn out. Parents hesitate to let teens join communities. Marketplaces drown in fraud and chargebacks. We add roadblocks – CAPTCHAs, scans, biometric checks – and still watch determined actors slip through. We pay with our time and, worse, with our privacy.
The fix is not to expose more of ourselves. The fix is to verify only what a context requires: age, country, or “one human, not a bot.” That’s it.
<h2>Prove the attribute, not the person</h2>
Consider what spaces actually need:
<ul>
<li aria-level="1">A teen forum needs to know a member is 13+, not their legal name.</li>
<li aria-level="1">A local group needs to know a participant is in Denmark, not their street address.</li>
<li aria-level="1">A marketplace needs to know a seller is a real human and eligible, not their passport number.</li>
</ul>
This is attribute verification – precise, minimal, and respectful. With zero-knowledge proofs (ZKPs), a user’s wallet proves a property (18+, in DK, human) without revealing the credential itself, <a href="https://aesirx.io/blog/aesirx/the-hidden-surveillance-layer-in-age-verification" target="_blank" rel="noopener">without “phone-home” pings to issuers</a>, and without creating a trail that can be linked across sites.
When you change the question from “Who are you?” to “Is this specific condition true?”, the entire risk surface changes – for the better.
<h2>Privacy by default, accountability by due process</h2>
Privacy cannot be a shield for abuse, and accountability cannot be a pretext for tracking everyone. The right architecture balances both:
<ul>
<li aria-level="1">Private by default. Users act under stable pseudonyms and disclose only the attribute a context requires. Sites store verdicts (true/false + timestamp), not identity.</li>
<li aria-level="1">Accountable by due process. If serious fraud or harm occurs, there’s a lawful path to unmask a bad actor – by court order, not by moderator whim or hidden backdoors.</li>
</ul>
That’s how you protect people and communities without normalizing surveillance.
<h2>What this looks like for real people – starting with youth</h2>
Denmark points to a practical path: teens (13+) can hold a national eID. <a href="https://aesirx.io/blog/aesirx/privacy-without-surveillance-age-verification-done-right-with-zero-knowledge-proofs" target="_blank" rel="noopener">Connected to a privacy-first wallet</a>, this makes age-appropriate youth communities feasible, keeping adults out without exposing a teen’s name, school, or browsing history to the site operator. Families get confidence; moderators get leverage; kids get spaces that are truly designed for them. A 14-year-old can join a study forum that’s truly for teens – no names exposed, no dossiers created.
<h2>Then extend it – markets, messaging, and the “human-only” switch</h2>
<ul>
<li aria-level="1">Marketplaces: Gate listings behind a one-time proof that sellers are human and eligible. Fraud drops without anyone uploading passports to unknown servers.</li>
<li aria-level="1">Communities: Offer “human-only” rooms for sensitive topics. Sockpuppetry and dogpiling collapse when each pseudonym must map to one human.</li>
<li aria-level="1">Region-specific access: Release content to the right jurisdictions without harvesting addresses or building an audience-tracking map.</li>
<li aria-level="1">Moderation: Gate the highest-risk actions (bulk messaging, payments, new listings) with proofs, while allowing ordinary participation to remain effortless.</li>
</ul>
The outcomes are tangible: less spam, fewer scams, faster moderation, and no new data troves to breach or broker.
<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-difference-between-compliance-theater-and-real-privacy-engineering.jpg" alt="the difference between compliance theater and real privacy engineering" width="1885" height="1061" />
<h2>How it works&nbsp;</h2>
<ol>
<li aria-level="1">Wallet, not upload. Credentials live in the user’s wallet. Sites see only a derived proof.</li>
<li aria-level="1">Question, not dossier. Sites ask a narrow question (“18+?”, “in DK?”). The answer is a cryptographically verifiable yes/no.</li>
<li aria-level="1">No phone-home. Issuers aren’t silently notified each time a proof is presented.</li>
<li aria-level="1">Unlinkable proofs, auditable actions. A proof shown to Site A can’t be correlated with Site B, and sites log only that a valid proof gated a specific action – useful for audits, useless for profiling.</li>
</ol>
That’s the difference between “compliance theater” and real privacy engineering.
<h2>Why now, before AI agents set the norm</h2>
The next wave of bots will be more coordinated, conversational, and convincing. If we wait, we’ll normalize heavy-handed measures that harm civil liberties and still fail against sophisticated automation. The humane alternative exists today: human-centric verification that scales – which is why we’ve moved from principle to practice.&nbsp;
<h2>Shipping reality: WordPress and beyond</h2>
Last week, we released <a href="https://aesirx.io/blog/aesirx/aesirx-cmp-for-wordpress-v2-0-0-delivers-regulation-ready-age-and-country-verification-without-surveillance">AesirX CMP v2.0.0 for WordPress</a>, bringing ZKP-based Age and Country Verification to site owners with a few clicks. It runs first-party (no third-party beacons during consent or verification) and answers only the question a context requires. Because WordPress powers a massive share of the web, placing these tools in everyday builders’ hands accelerates a safer, more private default.
If you run a community, marketplace, publication, or membership product, you can pilot attribute proofs exactly where abuse hurts you most – sign-ups, messaging, listings, and payments – without turning users into data points.
<h2>Principles that should be non-negotiable</h2>
<ul>
<li aria-level="1">Minimum necessary: verify only what’s required, nothing else.</li>
<li aria-level="1">No phone-home: issuers don’t get a ping for each proof.</li>
<li aria-level="1">Unlinkable by default: prevent cross-site correlation.</li>
<li aria-level="1">Due-process accountability: unmasking only under a lawful order.</li>
<li aria-level="1">First-party by design: consent and verification must not leak to third parties.</li>
<li aria-level="1">Document the path: publish a narrow, auditable unmasking policy.</li>
</ul>
Write these into your product requirements. Hold vendors, and yourselves, to them.
<h2>The web we should choose</h2>
We can build a web where:
<ul>
<li aria-level="1">Children join communities that are truly for them.</li>
<li aria-level="1">Buyers and sellers transact with confidence.</li>
<li aria-level="1">Moderators have teeth without building panopticons.</li>
<li aria-level="1">Creators reach the right regions without harvesting personal data.</li>
<li aria-level="1">AI agents serve humans, not impersonate them.</li>
</ul>
The way forward is simple to state and essential to preserve: prove what’s relevant, protect what’s private, and keep a lawful path for accountability. Do that, and we keep the internet human – without turning it into a surveillance system.
If you lead a product or community: start with one surface where abuse is costly. Gate that action with an attribute proof. Log verdicts, not identities. Measure the drop in spam, fraud, and moderation load. Then expand.
If you’re a policymaker: mandate safety and privacy-preserving verification, not blanket identity exposure.
If you’re a parent: ask platforms one question: Do you verify attributes privately, or do you track my child to keep them “safe”?
We don’t have to accept a bot-dominated, surveillance-heavy internet as the price of participation. We can choose better – and keep the web human, even as the bots rise.
<a href="https://www.linkedin.com/in/ronnikc/" target="_blank" rel="noopener">Ronni K. Gothard Christiansen</a> Technical Privacy Engineer &amp; CEO, <a href="http://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Ready for Part II?
Read: <a href="https://aesirx.io/blog/aesirx/zk-proofs-for-a-human-only-privacy-first-web" target="_blank" rel="noopener">Part II - ZK Proofs for a Human-Only, Privacy-First Web</a>
</div>

How ZKPs and privacy-first ID verification can protect communities and markets, keeping the web human in the age of bots and AI.

The Web After Bots and AI: How We Keep It Human

Part I - The Web After Bots and AI: How We Keep It Human - Without Surveillance

ZKPs and minimal ID verification offer a way to keep the internet human – proving attributes without surveillance in a bot-heavy web.

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

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

Public Sector Privacy Hypocrisy: Sovereignty vs. Default Telemetry

Why WordPress Sites Are Leaving Cookiebot In 2025 And Choosing AesirX CMP

Part IV – Safety Without Mass Scanning: A Verified-ID Path for Denmark and the EU

Part III – Contextual Uniqueness: Turning Private Proofs into Operational Trust

Part II – ZK Proofs for a Human-Only, Privacy-First Web

Part I - The Web After Bots and AI: How We Keep It Human - Without Surveillance

Referral Link

Share On Social Media

Revenue

NoData

Commission

No Data