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>
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.
<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.
<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>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>
</div>

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

Blog Aesirx

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>

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 Consent Management Platform introduces zero-knowledge proof (ZKP) ID verification to its Consent Management Platform, allowing websites to verify age and location without exposing personal data or creating a tracking trail.
NEW YORK, AUGUST 15, 2025 – <a href="https://github.com/aesirxio/wordpress-consent-plugin/releases/tag/2.0.0" target="_blank" rel="noopener">AesirX has released version 2.0.0</a> of its Consent Management Platform (CMP), introducing Age and Country Verification that prevents the surveillance risks common in traditional ID checks. Powered by zero-knowledge proofs (ZKPs) on the Concordium blockchain, the system confirms a user’s age or country without revealing personal details or leaving a permanent record that could be linked across sites.
From online safety laws in the UK and France to location-based content restrictions worldwide, more websites are being required to verify visitor age or country. This affects a wide range of sectors – from alcohol sales and online gambling to adult content platforms, financial services, and any other service where lawful access depends on the user’s age or jurisdiction.
Most existing solutions connect to centralized identity systems that “phone home” to the credential issuer each time a verification occurs – creating a silent log of when, where, and why someone verified their identity. Over time, these logs can be combined into behavioral profiles, allowing cross-site tracking without consent.
AesirX CMP 2.0.0 takes a different approach. Verification is handled locally through ZKPs, returning only a “yes” or “no” result. Neither the website nor the credential issuer sees or stores any other information, eliminating the possibility of cross-site tracking or profiling.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Missed our last update?
Read: <a href="https://aesirx.io/blog/press-release/press-release-aesirx-cmp-launch-appsumo-lifetime-deal" target="_blank" rel="noopener">AesirX Launch Lifetime CMP Deal on AppSumo – Privacy Compliance With 1-Click AI Auto-Blocking</a>
</div>
<h2>What’s New in CMP v2.0.0?</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_ID_Verification-1.jpg" alt="AesirX CMP ID Verification 1" width="952" height="505" />
<h3>ID Verification&nbsp;</h3>
The new ID Verification feature confirms user identity attributes without revealing personal data or creating a tracking trail. Using ZKPs and wallet-based credentials, it returns only a binary result, ensuring privacy while meeting regulatory demands.
How it works:
<ul>
<li aria-level="1">Works with supported digital wallets, including Concordium ID and Google Wallet (with additional methods planned).</li>
<li aria-level="1">Uses ZKPs to confirm attributes such as age or country without exposing personal details.</li>
<li aria-level="1">Creates a one-time-use pseudonym for each session and domain, preventing cross-site linkability.</li>
<li aria-level="1">Offers simple onboarding for users without a wallet via Concordium ID creation using a passport or driver’s license, with verification still performed via ZKPs.</li>
</ul>
Why it matters:
<ul>
<li aria-level="1">Removes the “phone home” problem found in most centralised ID systems.</li>
<li aria-level="1">Meets legal requirements without making the site owner a data controller.</li>
<li aria-level="1">Protects against profiling by keeping verification events unlinkable.</li>
<li>Aligns with <a href="https://gdprhub.eu/Article_25_GDPR" target="_blank" rel="noopener">GDPR Article 25 “Privacy by Design,</a>” a principle regulators actively encourage when evaluating compliance tools.</li>
<li>Also supports compliance with jurisdiction-specific rules such as the EU Audiovisual Media Services Directive (AVMSD) and US COPPA, where age and location-based access controls are mandated.</li>
</ul>
Note: Full unlinkability and zero-verification traceability is only currently achieved when using Concordium ID. Support for other digital wallets is live in v2.0.0 but may involve limited verification callbacks while CuK support is being finalized.
AesirX Creator, <a href="https://www.linkedin.com/in/ronnikc/" target="_blank" rel="noopener">Ronni K Gothard Christiansen</a>, says:
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
“Most verification systems trade compliance for surveillance. We’ve built ID Verification to prove only what’s needed, and nothing more, giving site owners a compliance tool they can trust and users a process that protects their privacy by design.”
</div>
<h3>Age and Country Verification</h3>
<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/aesirx-cmp-age-and-country-verification.jpg" alt="aesirx cmp age and country verification" width="600" height="249" />
Built for industries where age or location determines access, this feature enables websites to meet strict legal requirements without storing or sharing sensitive personal data.
How it works:
<ul>
<li aria-level="1">Configurable to enable Age Verification, Country Verification, or both.</li>
<li aria-level="1">Set minimum and maximum age limits for access control.</li>
<li aria-level="1">Define allowed or disallowed countries to meet jurisdictional rules.</li>
<li aria-level="1">Uses the same ZKP approach as ID Verification for secure attribute proof.</li>
</ul>
Why it matters:
<ul>
<li aria-level="1">Supports compliance for regulated sectors such as alcohol sales, online gambling, adult content, and financial services.</li>
<li aria-level="1">Avoids surveillance-heavy systems that log when and where a user verifies their identity.</li>
<li aria-level="1">Meets access control obligations while keeping user verification private and unlinkable.</li>
</ul>
<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_Website_banner_message_-_an_example_of_the_possible_options.jpg" alt="AesirX CMP Website banner message an example of the possible options" width="800" height="578" />
AesirX CMP: Website banner message - an example of the possible options
<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_Choosing_a_wallet_2.jpg" alt="AesirX CMP Choosing a wallet 2" width="800" height="710" />
AesirX CMP: Choosing a wallet
<h2>Use Case: Age-Gated Access Without Surveillance or Per-Use Fees</h2>
<h4>Client&nbsp;</h4>
A European online wine retailer.
<h4>Challenge&nbsp;</h4>
To comply with age-verification laws, the retailer previously used a national ID system (e.g., MitID in Denmark), but every verification cost between €0.07 and €0.13, and each check “phoned home” to the issuer, creating centralized logs that linked user activity across services and raised GDPR compliance concerns.
<h4>Solution with AesirX CMP 2.0.0</h4>
By switching to <a href="https://www.concordium.com/">Concordium ID and ZKP</a> verification:
<ul>
<li aria-level="1">Age is confirmed via privacy-preserving zero-knowledge proofs.</li>
<li aria-level="1">No personal data or logs are shared with third parties.</li>
<li aria-level="1">Verification happens locally - with zero per-use costs.</li>
<li aria-level="1">Each session uses a unique pseudonym, ensuring unlinkability.</li>
</ul>
<h4>The result?&nbsp;</h4>
Regulation-compliant access control that avoids surveillance while delivering significant cost savings, especially for high-volume traffic sites.
While this use case focuses on age-gated retail, the same approach applies to sectors like online gambling, adult content, financial services, and any site where jurisdiction or age determines legal access.
<h2>What AesirX CMP Delivers</h2>
Version 2.0.0 builds on AesirX CMP’s existing compliance tools to provide complete, privacy-first consent management.
<div class="table-responsive fs-6">
<table class="table table-bordered">
<tbody>
<tr>
<td style="text-align: center;">
Feature
</td>
<td style="text-align: center;">
Value
</td>
</tr>
<tr>
<td>ID Verification New in v2.0.0!</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>AI Privacy Advisor RELEASED in v1.9.0</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 RELEASED in v1.9.0</td>
<td>Apply blocking rules in one click with AI setup to block non-essential tracking for GDPR/<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">ePD 5(3)</a>.</td>
</tr>
<tr>
<td>Cookie Declaration &amp; Privacy Policy Generator RELEASED in v1.9.0</td>
<td>Generate editable templates based on actual scan data to match your live site setup.</td>
</tr>
<tr>
<td>Audit-Ready Logs RELEASED in v1.8.0 &amp; v1.5.0</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 RELEASED in v1.7.0, v1.6.0 &amp; v1.4.0</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>Category-Based Tracking Control RELEASED in v1.3.0</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>Customizable Consent Banners RELEASED</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>
<h2>How to Get AesirX CMP for WordPress</h2>
<h3>Lifetime Deal on AppSumo – Own Your CMP for $69, Not $1,200/Year</h3>
<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/lifetime-deal-on-appsumo-own-your-cmp-for-69-not-1200-year.jpg" alt="lifetime deal on appsumo own your cmp for 69 not 1200 year" width="1300" height="740" />
AesirX CMP: Lifetime deal exclusive to AppSumo
Many CMP providers now charge $50–$100 per month based on site traffic, meaning website owners can pay over $1,200 a year just to display a compliant cookie banner. AesirX takes a different approach: one lifetime price, no visitor limits, and no recurring fees.
Through the current AppSumo Lifetime Deal, WordPress site owners can get AesirX CMP v2.0.0 for a one-time payment starting at just $69 and save up to 86% compared to standard pricing. This includes all key features and future updates, from AI Privacy Advisor and 1-Click AI Auto-Blocking to the new Age and Country Verification powered by ZKPs.
No monthly bills. No price hikes. No hidden limits. Just a permanent, regulation-ready consent management solution you own for life.
➡ <a href="https://appsumo.com/products/aesirx?utm_source=partner-link&amp;utm_medium=referral&amp;utm_campaign=partner-246752" class="fs-4">Get the Lifetime Deal on AppSumo</a>
For more details on AesirX CMP 2.0.0 and its Age and Country Verification feature, visit <a href="https://aesirx.io">https://aesirx.io</a>.&nbsp;
Media Contact
Ronni K Gothard Christiansen, Creator – <a href="mailto:ronni@aesirx.io">ronni@aesirx.io</a>
447 Broadway, 2nd Floor, Suite #1305, New York, NY, US, 10013

Get the Lifetime Deal on AppSumo

AesirX CMP for WordPress v2.0.0 Delivers Regulation-Ready Age and Country Verification Without Surveillance

Press Release Aesirx

AesirX CMP for WordPress v2.0.0 introduces ZKP age and country verification, meeting global laws without tracking, data sharing, or surveillance.

AesirX CMP for WordPress v2.0.0

TL;DR:
Most age verification systems silently track users every time they prove their age - creating hidden surveillance via "phone-home" callbacks and cross-site identifiers. With AesirX CMP v2.0.0, we are launching a better way: age and country verification using zero-knowledge proofs and wallet-based credentials with no tracking, no cross-site IDs, and no per-use costs. Privacy and legal compliance can coexist - and we’ve proven it at scale.
Two weeks ago, I wrote about the <a href="https://www.linkedin.com/pulse/hidden-surveillance-layer-age-verification-how-we-fix-christiansen-mptjc/" target="_blank" rel="noopener">hidden surveillance layer</a> forming behind most age-verification systems: every time you prove you’re “over 18,” the credential issuer can be quietly pinged; every check becomes a breadcrumb linking identity, behavior, and context.
That’s not safety - it’s surveillance by design.
Tomorrow, we will provide a better way.
With AesirX CMP v2.0.0, WordPress sites (≈43% of the internet) can verify age and country with zero-knowledge proofs (ZKPs). No “phone-home” calls to credential issuers, no cross-site IDs, no profiling.
<h2>What’s Changed in the Last Two Weeks - And Why It Matters Now</h2>
Since my last article, the regulatory tide has shifted from forewarning to active enforcement:
<ul>
<li aria-level="1">UK: Ofcom has issued its first enforcement notices under the Online Safety Act, moving from guidance to penalties.</li>
<li aria-level="1">France: Arcom has begun blocking adult sites lacking approved age verification.</li>
<li aria-level="1">Texas: The Attorney General’s office sent formal enforcement letters to platforms failing to comply with HB 1181.</li>
<li aria-level="1">Denmark: The national ID app for online age checks has entered pilot testing, with public rollout slated for 2026.</li>
</ul>
These are no longer “upcoming” rules - they are live obligations. Non-compliance is no longer hypothetical; it’s a legal and financial risk today.
This launch is our counter-example: proof you can meet the law without building a tracking infrastructure.
With enforcement now real and immediate, the debate shifts from whether to verify to how to do it without turning compliance into surveillance. These enforcement actions don’t just demand compliance - they demand it now. The challenge is meeting those legal requirements without building systems that quietly track users for years. That’s exactly where privacy-preserving ID verification changes the equation.
<h2>Why ID Verification Exists - And Why It’s Not Going Away</h2>
Age and identity checks aren’t arbitrary hurdles. They exist to meet legal and societal obligations:
<ul>
<li aria-level="1">Protecting minors from adult content, gambling, and unsafe communities.</li>
<li aria-level="1">Preventing fraud in financial transactions and online marketplaces.</li>
<li aria-level="1">Enforcing jurisdictional rules for restricted goods, services, or media.</li>
<li aria-level="1">Supporting accountability when harm or criminal activity occurs.</li>
</ul>
These goals are legitimate - and they’re only becoming more important as online interactions replace in-person checks.
The problem is that most digital implementations have copied the wrong model: instead of mimicking a bouncer glancing at your ID without taking a copy, they log, store, and cross-reference every interaction. In doing so, they turn safety infrastructure into a persistent surveillance layer.
Once you separate the necessity of verification from the harm of surveillance, the core design flaw becomes obvious.
We can meet these aims with proofs, not profiles.
<h2>The Core Problem We’re Solving</h2>
Most current age or ID verification systems copy a flawed architecture that bakes surveillance into the process. Two design failures stand out:
<ol>
<li aria-level="1">Issuer Observability (“Phone Home”) - Every time you verify, the system pings the credential issuer. That silent callback creates a time-stamped usage log, building a hidden dossier of where and when you prove your identity. Over days, weeks, or years, this becomes a map of your online behavior. </li>
<li aria-level="1">Linkability Across Sites - Many systems reuse the same persistent identifier across multiple services. This makes it trivial to correlate activity from different platforms into a single behavioral profile.</li>
</ol>
Individually, each flaw undermines privacy. Together, they turn legal compliance into a de facto tracking network - one that harms individuals, erodes trust for platforms, and exposes regulators to backlash for enabling surveillance-by-design.
Our launch delivers exactly that: a live, working solution that proves privacy-preserving verification can be done at internet scale.
<h2>What Ships Tomorrow - and How It Works</h2>
With <a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">AesirX CMP</a> v2.0.0, any WordPress site can enforce Age &amp; Country Verification using zero-knowledge proofs - without tracking, profiling, or “phone-home” surveillance. At launch, three credential sources are supported:
<ul>
<li aria-level="1">Concordium ID &amp; Wallet - unlinkability + no issuer observability, by design.</li>
<li aria-level="1">Google Wallet - via Digital Credentials API / OpenID4VP.</li>
<li aria-level="1">Mobile Driver’s Licenses (mDL) - supported through Google Wallet.</li>
</ul>
The Privacy-First Verification Flow:
<ol>
<li aria-level="1">The user selects a supported wallet and consents to verify.</li>
<li aria-level="1">The wallet generates a zero-knowledge proof of the required condition (e.g., “≥18” or “allowed country”).</li>
<li aria-level="1">The site receives only a binary yes/no result and a context-bound pseudonym (e.g., unique to this domain/session) - never the user’s name, date of birth, or any persistent identifier.</li>
</ol>
With Concordium, there’s no issuer callback, no usage log, and no cross-site identifier. If auditability is required, you can anchor a hash commitment - never raw personal data - on-chain.
This is verification as it should be: lawful, privacy-preserving, and built to scale without creating a surveillance layer.
<h2>Privacy and Accountability in the Same Design</h2>
A fair question often follows: “If it’s truly private, how do you deal with abuse or illegal activity?”
The answer is built into Concordium’s architecture: lawful accountability without routine surveillance.
<ul>
<li aria-level="1">No exposure in normal use - Verification events remain anonymous and unlinkable during everyday operation.</li>
<li aria-level="1">Court-order unmasking only - If a serious legal case arises (e.g., child exploitation, major fraud), a governed process allows a court to request correlation between a specific verification event and the issuing authority.</li>
<li aria-level="1">No unilateral access - Neither AesirX nor Concordium can identify a user on their own; it requires due process under applicable law.</li>
</ul>
This design protects children and vulnerable groups from harm without creating a mass-surveillance infrastructure - proving that privacy and accountability can, and must, coexist.
This balance between privacy and lawful accountability sets the foundation for what comes next - extending the same protections to every wallet type and every verification scenario.
<h2>Where We’re Going Next: CuK for Universal Unlinkability</h2>
Tomorrow’s release already delivers full unlinkability with <a href="https://www.concordium.com/solution/id-verification" target="_blank" rel="noopener">Concordium ID</a> and broad compatibility via Google Wallet and mDL.
The next leap is CuK - Contextual Uniqueness Key. Built in partnership with Concordium, CuK is a client-side, per-session, per-domain pseudonym. This means sites and wallets never need to trust a central service. It:
<ul>
<li aria-level="1">Breaks cross-site linkability at the root</li>
<li aria-level="1">Eliminates “phone-home” calls for all wallet types</li>
<li aria-level="1">Preserves lawful accountability without exposing personal data</li>
</ul>
Once finalized, CuK will extend these same privacy guarantees to:
<ul>
<li aria-level="1">Apple Wallet</li>
<li aria-level="1">EUDI Wallets (EU digital identity framework)</li>
<li aria-level="1">mDL Wallets (beyond Google integration)</li>
<li aria-level="1">National eID Wallets (e.g., VNeID in Vietnam)</li>
<li aria-level="1">Emerging credential sources as standards evolve</li>
</ul>
Bottom line: Regardless of wallet or credential issuer, the verification outcome will always be the same - unlinkable proof, zero issuer observability, and accountability only under due process.
This is how we make privacy-preserving verification wallet-agnostic - and close the gap between compliance and true user protection, once and for all.
CuK ensures that unlinkable, phone-home-free verification isn’t limited to one niche use case. Once universal, it can protect privacy across every context where eligibility needs to be proven.
<h2>Why this matters beyond age checks</h2>
The same flawed architecture now driving age-gating is quietly being repurposed across other domains:
<ul>
<li aria-level="1">Social media access and youth protections</li>
<li aria-level="1">Online gambling &amp; gaming eligibility</li>
<li aria-level="1">Fintech/DeFi onboarding (KYC-lite access controls)</li>
<li aria-level="1">Health and wellness services with sensitive eligibility</li>
<li aria-level="1">Cross-border content compliance</li>
</ul>
If we solve the architecture once - using Zero-Knowledge Proofs (ZKPs) and the Contextual Uniqueness Key (CuK) - we prevent surveillance-grade infrastructure from being embedded in every new compliance requirement.
These safeguards are not speculative. They already deliver tangible benefits: businesses can comply without invasive tracking, platforms can meet legal mandates without retaining unnecessary data, regulators can uphold the law without endorsing surveillance, and individuals keep their privacy intact.
Which is why the decisions we make now, and the systems we choose to deploy, will define whether the internet of the next decade protects freedom - or quietly erodes it.
<img src="https/api.aesirx.io/images/Use_Case_1.jpg" alt="Use Case 1" width="3680" height="3204" />
<h2>Use Case: Age-Gated Access Without Surveillance or Per-Use Fees</h2>
Client Profile: A leading European online wine retailer Regulatory Challenge: Age-verification laws required the retailer to ensure customers were over 18 before purchase. Their previous method relied on a national ID system (e.g., MitID + Centralized Solution Provider in Denmark), which introduced three critical issues:
<ul>
<li aria-level="1">Cost: €0.07–€0.13 per verification (typical range), creating a significant recurring expense for high-traffic sites.</li>
<li aria-level="1">Privacy Risk: Every verification “phoned home” to the issuer, generating a cross-service behavioral log.</li>
<li aria-level="1">Compliance Exposure: Centralized logging risked GDPR violations by enabling long-term user tracking.</li>
</ul>
Solution with AesirX CMP 2.0.0 (Concordium ID + ZKP):
<ul>
<li aria-level="1">Privacy-Preserving Verification: Age is confirmed using zero-knowledge proofs, revealing only “Yes” or “No.”</li>
<li aria-level="1">No Personal Data Shared: No names, dates of birth, or raw identifiers are exposed to third parties.</li>
<li aria-level="1">Local Processing: All checks happen client-side - no issuer callbacks, no surveillance logs.</li>
<li aria-level="1">Zero Per-Use Costs: Eliminates the per-verification fee structure entirely.</li>
<li aria-level="1">Unlinkable Sessions: Each visit generates a unique pseudonym, preventing cross-site correlation.</li>
</ul>
Outcome:
<ul>
<li aria-level="1">Fully compliant with EU and national age-gating requirements.</li>
<li aria-level="1">Eliminated the cost of per-use verifications - critical for high-volume operations.</li>
<li aria-level="1">Strengthened trust with privacy-conscious customers by removing unnecessary data collection.</li>
</ul>
While this example highlights regulated alcohol sales, the same architecture is ready today for other industries with eligibility-based access. Here’s who stands to gain from day one.
<h2>Who benefits on day one</h2>
When privacy-first verification ships, it delivers immediate wins for every stakeholder:
<ul>
<li aria-level="1">Retailers of regulated goods - Enforce age restrictions lawfully, without tracking or storing customer identities (no phone-home, unlinkable verification).</li>
<li aria-level="1">Media &amp; content platforms - Gate mature content responsibly, without building covert dossiers on viewers.</li>
<li aria-level="1">Financial and regulated services - Meet access-control mandates while minimizing data retention, reducing audit risk, and protecting customer trust.</li>
<li aria-level="1">Policymakers &amp; regulators - Gain a working, live blueprint that proves privacy and lawful accountability can coexist in production.</li>
</ul>
This isn’t just about compliance - it’s about showing the world that regulation and rights don’t have to be in conflict, if the architecture is designed right from the start.
<h2>What this answers from two weeks ago</h2>
In my last article, I asked a simple but urgent question: Can we verify identity without turning it into a tracking tool?
This release delivers the answer:
<ul>
<li aria-level="1">No issuer observability - No “phone home,” meaning the issuer cannot silently log where or when you verify.</li>
<li aria-level="1">No cross-site correlation - Unlinkable proofs ensure your verification on one service cannot be tied to activity on another.</li>
<li aria-level="1">Preserved due-process accountability - Lawful unmasking is only possible under a valid court order for serious harms.</li>
<li aria-level="1">A wallet-agnostic path forward - With CuK (Contextual Uniqueness Key), these guarantees can apply to any credential source.</li>
</ul>
Two weeks ago, these outcomes were hypothetical. Tomorrow, they’re live in production - and the model is ready to scale. The next step is ensuring it becomes the baseline, not the exception, for how verification is done online.
<h2>The Internet We Keep Will Be the One We Build Now</h2>
Compliance should never come at the cost of turning the internet into a surveillance machine.
With AesirX CMP v2.0.0, we’ve shown it’s possible to protect children, uphold privacy, and maintain trust - at internet scale.
Launching tomorrow:
<ul>
<li aria-level="1">WordPress site owners can enable Age &amp; Country Verification in minutes.</li>
<li aria-level="1">Policymakers and regulators can review a live, privacy-first model that’s ready to inform standards and guidance.</li>
<li aria-level="1">Ecosystem partners interested in pilots beyond WordPress (e.g., CMS/framework adapters, wallet collaborations or enterprises) can contact us to explore next steps.</li>
</ul>
If we align now on unlinkable, phone-home-free verification as the baseline, we can stop building surveillance into every new compliance law - before it’s too late.
Learn more at&nbsp;<a href="https://aesirx.io" target="_blank" rel="noopener">https://aesirx.io</a>.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, AesirX.io

AesirX CMP delivers Age and Country Verification with zero tracking, using ZKPs for privacy-first compliance without phone-home surveillance.

Privacy Without Surveillance: Age Verification with ZKPs

Privacy Without Surveillance: Age Verification, Done Right with Zero-Knowledge Proofs

How to verify age and identity online while protecting privacy, avoiding surveillance, and meeting legal obligations worldwide.

Privacy Without Tracking: Age Verification via Zero-Knowledge Proofs

When regulators or privacy advocates scan a website for compliance, one of the most common violations they find occurs in the first 200 milliseconds. Before any user clicks “Accept” or “Reject,” their device is already contacted by trackers, analytics scripts, or telemetry services.
These violations risk user trust and expose businesses to regulatory action and reputational damage.
The ironic twist? Many of these violations are introduced by the very tools purchased to enforce compliance: Consent Management Platforms (CMPs).
The core issue is how these platforms misuse the legal exception for “technical necessity” under Article 5(3) of the ePrivacy Directive. This article breaks down why that clause is being misunderstood, how CMPs and Google Tag Manager (GTM) are abusing it, and what an actual compliant setup looks like.
<h2>What “Strictly Necessary” Actually Means</h2>
Article 5(3) of the ePrivacy Directive allows certain scripts to run without consent, but only if they are essential for delivering a service the user has explicitly requested.
In practice, this means functionality like login sessions, shopping carts, or security tokens. It does not include telemetry, user behavior tracking, performance monitoring, or invoicing logic.
The European Data Protection Board clarified in <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">Guidelines 02/2023</a> that “strict necessity” must be evaluated solely from the perspective of the data subject. Not from the business. Not from the vendor.
This means that even if a CMP needs to count visitors for billing purposes, or track how users interact with the banner for product analytics, these actions still require prior consent.
<h2>Why Most CMPs Are Non-Compliant by Design</h2>
A CMP’s exempt purpose is to show a consent prompt and register a choice. Yet in most implementations, CMPs do more than this before consent is even collected.
Common violations include:
<ul>
<li aria-level="1">Tracking visitor sessions for usage-based invoicing</li>
<li aria-level="1">Loading performance beacons for UI monitoring</li>
<li aria-level="1">Embedding telemetry to analyze user interaction with the banner</li>
<li aria-level="1">Hosting via third-party CDNs that initiate cookie placement</li>
<li aria-level="1">Loading through GTM, which itself launches multiple domains</li>
</ul>
These elements do not meet the legal threshold of necessity for the user. They serve the business or the vendor. That makes them unlawful without consent.
In our <a href="https://aesirx.io/blog/aesirx/36000-danish-business-websites-just-violated-gdpr" target="_blank" rel="noopener">privacy scans of 36,500 websites in Denmark</a>, we found that all of the most widely used CMPs loaded third-party beacons, telemetry scripts, or analytics trackers before any user interaction - whether deployed directly or via Google Tag Manager. These scripts typically captured user agent details, screen resolution, IP-based geolocation, and session timestamps. The stated purposes included vendor-side invoicing, product telemetry, and UI optimization - none of which are technically necessary to display a consent prompt. Under Article 5(3) of the ePrivacy Directive, these functions require prior consent, which in these cases had not yet been obtained.
<h2>Why GTM Fails Even Before CMPs Load</h2>
Google Tag Manager (GTM) is frequently used to deploy CMPs, but GTM itself begins executing scripts immediately on page load - before any user has made a consent choice. This includes loading third-party resources and initializing tracking-related behavior.
Even with Consent Mode 2.0 enabled, GTM still connects to Google servers and can activate tags in a default “denied” or “pending” state. However, this fallback does not reliably prevent access to the user's device. Scripts may still fire, set cookies, or store unique identifiers based on the assumption that consent will be granted later.
This assumption is fundamentally incompatible with Article 5(3) of the ePrivacy Directive, which requires prior consent before any access to or storage of information on the user’s terminal equipment - regardless of whether consent is expected afterward.
Worse still, scripts injected into the page via GTM often <a href="https://aesirx.io/blog/aesirx/why-privacy-violations-often-go-unseen" target="_blank" rel="noopener">do not appear in the browser's developer tools</a>. They are dynamically inserted into the DOM, making them invisible to basic inspection. For example, LinkedIn conversion tracking - when deployed via GTM - does not expose its cookies, beacons, or script behavior in the browser console. These elements are only revealed through full HAR (HTTP Archive) network analysis.
This hidden execution layer makes it difficult for site owners, auditors, and even regulators to detect what data is being accessed or shared - compounding both the technical risk and the legal exposure.
When CMPs are loaded through GTM, the problem multiplies: you have a non-compliant delivery mechanism executing scripts without consent, which then attempts to enforce compliance. That paradox undermines trust, transparency, and legal defensibility.
Regulators are already enforcing this. A recent ruling from the Administrative Court of Hanover (<a href="https://www.linkedin.com/posts/ronnikc_vg-hannover-ruling-on-cookies-consent-and-activity-7335166836080091136-uULe/" target="_blank" rel="noopener">VG Hannover, 10 A 5385/22, March 2025</a>) explicitly ruled that the use of GTM requires prior, informed, and voluntary consent under both §25(1) TTDSG (now § 25 TDDDG / ePrivacy Directive 5(3) as imposed in German law) and Art. 6(1)(a) GDPR.&nbsp;
<h2>Misclassifying Tracking as Necessary</h2>
One of the most pervasive problems is the vendor-led practice of self-classifying telemetry and analytics as “strictly necessary.”
This misclassification includes:
<ul>
<li aria-level="1">Visitor counters for CMP billing models</li>
<li aria-level="1">Heatmap data collection for UX optimization</li>
<li aria-level="1">Cookie syncing or tag loading that runs “passively”</li>
</ul>
No vendor has the legal authority to redefine what is necessary. That judgment is made in law, and it centers exclusively on the data subject’s interest. Not operational convenience. Not internal dashboards. Not investor KPIs.
Our <a href="https://aesirx.io/blog/aesirx/36000-danish-business-websites-just-violated-gdpr">privacy scans across 36,500 Danish business websites</a> revealed that more than 73 percent deployed tracking technologies before any valid consent was obtained. In the majority of these cases, the tracking included third-party CMPs configured to operate through GTM or external CDNs.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/the-compliance-architecture-that-works.jpg" alt="the compliance architecture that works" width="1884" height="1060" />
<h2>The Compliance Architecture That Works</h2>
Achieving true compliance with the ePrivacy Directive isn’t a technical challenge - it’s a matter of architectural discipline. A properly designed CMP setup follows a simple rule: no data processing before consent.
A compliant implementation follows these principles:
<ul>
<li aria-level="1">Self-hosted deployment: The CMP must be served from the same first-party domain, not a third-party CDN. This ensures no external resources are touched before consent.</li>
<li aria-level="1">Deferred execution: The consent modal is displayed only after the page has fully loaded, with no pre-consent scripts, beacons, or trackers in the critical rendering path.</li>
<li aria-level="1">Zero third-party execution before consent: No Google Tag Manager, ad tech, telemetry, or analytics logic is loaded or initialized before the user has made a clear and informed choice.</li>
<li aria-level="1">Verified by design: Pre-consent network traffic is validated using HTTP analysis, HAR files, and automated <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">privacy scans</a> to ensure that no unauthorized processing occurs.</li>
</ul>
This model is already powering real websites.
<a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">AesirX CMP</a> is an operational example of this privacy-first architecture. It is fully self-hosted, executes no third-party requests, includes optional load of GTM until after consent, and includes tooling to verify compliance before deployment. This design respects the user’s rights - and it satisfies both the letter and the spirit of the law.
For businesses serious about compliance, this is the benchmark.
<h2>What Businesses Must Start Asking</h2>
If a CMP is collecting data about your users before consent, then it is not a consent tool. It is a data collection tool dressed in compliance branding.
That leads to a more fundamental question: why pay for a compliance solution that does not make you compliant?
If your CMP violates the very laws it claims to help you follow, then it is not reducing your risk. It is increasing it.
Real compliance cannot be outsourced blindly. It must be engineered with transparency, restraint, and respect for user rights. Anything less is just a legal fiction.
The businesses that win will be those that treat consent not as a checkbox, but as an unshakable foundation for trust.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="http://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
&nbsp;

Many CMPs and GTM violate ePrivacy law by tracking users before consent. AesirX explains the legal risks and how to implement a truly compliant setup.

The Legal Fiction of Technical Necessity: CMPs and GTM

The Legal Fiction of ‘Technical Necessity’: Why CMPs and GTM Violate Consent Before You Even Click

Most CMPs misuse the legal exception for technical necessity, leading to ePrivacy violations before consent. Learn why and how to fix your setup.

Legal Fictions and the Role of GTM in Consent Management

This past week, age verification enforcement went live in the UK. France reinstated its ban on adult sites without verification. Texas is now fully enforcing its age-check law. Denmark will launch a national age verification app in 2026.
This wave of regulation is reigniting a pressing debate in digital privacy:
<h4>Can we verify age without turning digital identity into a tracking tool?</h4>
Governments are right to demand stronger protections for minors. Platforms are being held accountable. But users are now forced into a false choice: hand over sensitive personal data or lose access to lawful digital services.
That’s not real regulation. That’s coercion by design.
And it gets worse. The most serious risk isn’t just handing over ID. It’s the silent, permanent correlation of identity, behavior, and context every time you prove who you are online. A hidden surveillance layer is forming, powered by credential issuers quietly monitoring how their credentials are used.
<h3>It’s time to break that model.</h3>
<h2>The Laws Are Clear. The Architecture Is Not.</h2>
Across jurisdictions, age verification is now a legal requirement.
In the United Kingdom, Ofcom began enforcing the Online Safety Act on July 25, 2025. Platforms must now implement highly effective age assurance for adult and harmful content or face fines up to £18 million or 10 percent of global turnover. Ofcom has already launched formal investigations into 34 adult websites for noncompliance.
In Denmark, the government is piloting an EU-backed national age verification app, with a full rollout planned in 2026. The system is expected to be integrated with MitID and mandatory for adult content access.
In France, the Council of State reinstated enforcement on July 15, 2025, requiring pornographic websites to implement strict age verification under Arcom’s oversight. Platforms can now be fined up to 2 percent of global revenue and blocked by ISPs for failure to comply.
In Texas, House Bill 1181 has been in effect since 2023. The U.S. Supreme Court upheld the law in 2025, confirming that commercial adult sites must verify age using government-issued ID or facial recognition, or face civil liability.
Regulators are moving fast. But the systems being deployed rely heavily on centralized identity credentials, facial scans, and government-issued wallets. These methods often lack clear protections against one specific and dangerous behavior: silent issuer observability.
<h2>The "Phone Home" Problem</h2>
Whenever a user verifies an attribute like “over 18,” the credential issuer may be pinged in the background. This is what privacy professionals call the phone home problem. It allows the issuer - whether a government, identity vendor, or mobile platform - to know when, where, and why a credential is used.
Over time, this creates a behavioral profile that tracks not just identity but usage patterns and digital context. It enables cross-site surveillance without cookies, and without consent.
Even the EU’s EUDI Wallet project, designed to enable privacy-friendly digital credentials, has drawn criticism for failing to prevent issuer observability. Many implementations allow the credential issuer to log each verification event.
It's like your driver’s license quietly reporting to the state every time you visit a website. That’s not age verification. That’s behavioral surveillance in disguise.
We don’t need to choose between protecting children and protecting everyone else. We can have both - if we build it the right way.
<h2>A Better Model Starts With Privacy First</h2>
At AesirX, in partnership with the Layer 1 blockchain Concordium, we are finalizing a privacy-preserving architecture designed to meet compliance while protecting user anonymity by default.
The foundation is what we call the Contextual Uniqueness Key (CuK) - a client-side pseudonym generated per session and per domain. Each service a user interacts with sees only a one-time-use identity. Nothing persists, and nothing links across services.
The user verifies their age using an identity source of their choice:&nbsp;Concordium Wallet, EUDI Wallet, mobile driver’s license, national ID, or Apple or Google Wallet. A zero-knowledge proof (ZKP) confirms the age claim without exposing any personal data.
Each website receives a unique pseudonym, valid only for that context. No central system sees the full picture. And most importantly, the credential issuer never knows the verification took place.
This breaks the surveillance loop. There are no behavioral breadcrumbs. No phone home.
<h2>Concordium Anchors the Trust Without Owning the Data</h2>
The CuK system is anchored by Concordium’s privacy-first blockchain infrastructure, providing cryptographic proofs, decentralized trust, and legally governed audit capabilities - without ever collecting or storing user data.
Concordium’s unique approach to identity combines <a href="https://www.concordium.com/build/technology#zero-knowledge-section" target="_blank" rel="noopener">zero-knowledge proofs</a>, layer-1 security, and multi-party unmasking, enabling lawful accountability where necessary, while preserving user anonymity by default.
This ensures that platforms and developers can meet regulatory demands without surrendering control to centralized intermediaries. Whether used directly or integrated through middleware like <a href="https://shield.aesirx.io" target="_blank" rel="noopener">AesirX’s Shield of Privacy</a>, Concordium enhances the entire trust layer while maintaining decentralization.
It delivers what regulators expect - traceability, provability, and compliance - while protecting users from being profiled, tracked, or linked across services.
<h3>This isn’t future tech. It’s working today.</h3>
<h2>The Pattern Is Spreading</h2>
Age verification is just the beginning. The same technical architecture is already being proposed or deployed for:
<ul>
<li aria-level="1">Access to social media platforms</li>
<li aria-level="1">Online gambling and gaming</li>
<li aria-level="1">KYC-light DeFi and fintech onboarding</li>
<li aria-level="1">Cross-border content filtering</li>
<li aria-level="1">Health and mental wellness services</li>
</ul>
What we choose today will define the future of identity. If we default to centralized ID observability, we risk building an internet that reports on every action to a third party. If we build with privacy-first primitives like CuK and ZKPs, we can meet legal obligations without turning compliance into surveillance.
We need to move past checkbox regulation and demand real protections: unlinkability, zero-knowledge proofs, decentralization, and trust minimization by design.
<h2>The Identity We Build Defines the Internet We Keep</h2>
Digital identity is becoming the infrastructure of the internet.
We can design a future where compliance means trust, not tracking. Where privacy is a core requirement, not an afterthought. Where platforms, regulators, and developers build systems that truly protect users instead of exposing them.
With AesirX and Concordium, this isn’t a concept or a pitch. It’s real, working, and ready for implementation - and now we are working together to finalize the last parts of our CuK model to protect your privacy online.
If you’re building a platform, writing policy, or shaping digital infrastructure:
The architecture matters.
Design compliance that doesn’t compromise. Build trust you never have to surrender. Let’s build an internet worth trusting.
Reach out to explore pilots, standards collaboration, or help implementing compliant age verification.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="http://aesirx.io">AesirX.io</a>

The Hidden Surveillance Layer in Age Verification - and How We Fix It

The Hidden Surveillance Layer in Age Verification

As age verification laws expand, a hidden risk emerges; identity systems that quietly track behavior. Can we protect minors without building surveillance?

Why we're launching a lifetime Consent Management Platform (CMP) deal on AppSumo&nbsp; -&nbsp; and why it matters right now.
<h2>The Illusion of Compliance Is Costing You More Than You Think</h2>
Imagine paying $1,000+ per year for a tool labeled “compliant” - only to find out it could get you fined.
That’s the hidden risk behind most cookie consent solutions on the market today.
In the past month, we've seen major Cookie Consent-as-a-Service vendors quietly raise their prices - some by more than 200%, especially for businesses with growing traffic or complex page structures.
This might be tolerable if these tools delivered real compliance. But many don’t. They often:
<ul>
<li aria-level="1">Load trackers and scripts via Google Tag Manager or are loaded by GTM before consent</li>
<li aria-level="1">Include pixel trackers, analytics or telemetry within the CMP itself</li>
<li aria-level="1">Rely on third-party CDNs that collect IP addresses for billing or UX tracking</li>
</ul>
This violates both the letter and spirit of global privacy laws and fails to live up to technical necessity requirements for loading prior to consent - and puts the burden of liability squarely on your business, not them.
In our latest privacy scan, <a href="https://aesirx.io/blog/aesirx/36000-danish-business-websites-just-violated-gdpr" target="_blank" rel="noopener">over 73% of sites in Denmark using 3rd-party CMPs were found in violation of ePrivacy rules</a> - despite using “compliance tools.”
So why pay a premium for a consent tool that may actually increase your legal risk?
<h2>Why We're Doing This&nbsp; -&nbsp; And Why It's Time-Limited</h2>
We believe privacy compliance shouldn’t be a luxury.
That's why we're offering something no other CMP vendor will: a fully compliant, first-party Consent Management Platform - available as a one-time purchase.
No subscriptions. No monthly surprises. No per-visitor fees.
And no hidden tracking that undermines your compliance.
This is a serious offering to help agencies, developers, and businesses permanently exit the recurring-cost trap while staying compliant the right way.
Last week, I broke down <a href="https://aesirx.io/blog/aesirx/why-most-cookie-consent-as-a-service-tools-fail-the-eprivacy-directive-test" target="_blank" rel="noopener">why most cookie consent tools fail</a> - by design.
This week, I’m offering the alternative: a privacy-first CMP that gets it right from the start. Currently available for WordPress – with support for more platforms coming soon.
But there’s a catch: this deal is only available for 120 days through AppSumo. After that, it’s gone.
<h2>Built to Actually Comply - By Design</h2>
From day one, we built AesirX CMP with legal compliance as the foundation - not a marketing tagline.
Unlike most CMPs, we:
<ul>
<li aria-level="1">Self-host entirely under your control (first-party architecture)</li>
<li aria-level="1">Block all tracking technologies until consent is explicitly given</li>
<li aria-level="1">Enable 1 Click AI Privacy Advisor for near-seamless configuration</li>
<li aria-level="1">Do not share user data, IPs, or behavior with our servers - ever</li>
<li aria-level="1">Offer full consent logging, export, and audit trails by default</li>
</ul>
And our platform is built to meet the strictest requirements of global privacy laws, including:
<ul>
<li aria-level="1">GDPR &amp; ePrivacy Directive (EU) - Consent must be given before any non-essential data is stored or accessed</li>
<li aria-level="1">UK GDPR &amp; PECR - Explicit opt-in required for all behavioral tracking</li>
<li aria-level="1">Germany (2024-2025 rulings) - Violations found for using GTM, Consent Mode 2.0, and Pixel without prior consent</li>
<li aria-level="1">Norway’s Ekom Act - Requires user consent even for analytics cookies</li>
<li aria-level="1">Vietnam PDPD (in force) &amp; PDPL (from 2026) - Consent is already required by law; PDPL introduces fines of up to 3 billion VND</li>
</ul>
And yes - North American businesses should care too: even in the U.S., state-level privacy laws (California, Texas, Colorado, Connecticut, etc.) are tightening, fines are being issued, and federal frameworks are on the horizon.
<a href="https://aesirx.io/blog/aesirx/tracking-before-consent-can-cost-5000-eur-per-visitor">A German court recently awarded €5,000 in damages</a> to a single user due to Meta Pixel loading before consent. Multiply that by hundreds or thousands of users, and it’s easy to see how the risks add up.
<h2>This Is the Only Time We’ll Offer This</h2>
This is a single, limited deal window for you to:
<ul>
<li aria-level="1">Migrate off expensive, non-compliant third-party CMPs</li>
<li aria-level="1">Take control of your consent management - legally and technically</li>
<li aria-level="1">Future-proof your site before global enforcement catches up</li>
</ul>
It’s a one-time investment. For a lifetime of compliance.
If your current CMP tracks users before they’ve agreed, it’s not a Consent Management Platform. It’s a liability.
We built AesirX CMP to fix that. Now you can own it - forever.
Claim your Lifetime CMP HERE before this 120-day deal disappears forever.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, AesirX.io

Once-in-a-Lifetime Deal  -  Literally

Stop overpaying for cookie banners that don’t comply. AesirX CMP offers a lifetime deal for a real first-party solution. No subscriptions, full control

AesirX introduces its CMP Lifetime Deal on AppSumo: From $69, WordPress users get AI-powered consent management and auto-blocking for fast, easy compliance.
By: AesirX.io Ltd.
NEW YORK, July 25, 2025 – AesirX proudly announces the launch of a Lifetime Deal for its AI-powered Consent Management Platform (CMP) on AppSumo, giving WordPress users an affordable way to manage global privacy compliance. Unlike most CMPs that charge monthly based on site traffic or page volume (costs that rise as websites grow), AesirX offers a lifetime price from just $69, with four plans to choose from and up to 86% off the usual price. Built with automation in mind, AesirX CMP includes the AI Privacy Advisor to scan, detect, and auto-block unauthorized tracking across cookies, scripts, and beacons, enforcing real user consent, simplifying legal compliance, and protecting privacy from day one.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/take-control-of-tracking-reduce-privacy-risks-and-make-compliance-easier.jpg" alt="take control of tracking reduce privacy risks and make compliance easier" width="3840" height="2160" />
Take control of tracking, reduce privacy risks, and make compliance easier
A Consent Management Platform (CMP) manages and documents user consent for data collection to help businesses comply with complex privacy regulations. Yet, most CMPs fail to fully protect websites from privacy risks, leaving organizations vulnerable to non-compliance and reputational damage, especially with privacy laws like GDPR, ePrivacy Directive, and CCPA evolving fast.&nbsp;
AesirX Consent Management Platform proactively protects any site with a privacy-friendly approach that blocks all unauthorized tracking before consent is given, not just cookies. This first-party solution provides a fully compliant, uninterrupted consent interface, even with browser restrictions.
<h2>The Lifetime Deal&nbsp;</h2>
To officially launch the platform, AesirX has partnered with AppSumo to offer website managers, agencies, and businesses a cost-effective way to manage consent and privacy compliance effortlessly.
With a one-time payment, users get lifetime access – no monthly fees, no surprises. This fixed-cost solution gives complete control over consent management without ongoing expenses. Plus, as an added bonus, AesirX includes 1 year of Privacy Monitoring, providing automated security scans and instant alerts to help users maintain compliance from day one.
&nbsp;<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/huge-savings-up-to-86-off-aesirx-cmp-on-appsumo.jpg" alt="huge savings up to 86 off aesirx cmp on appsumo" width="2560" height="1440" />
Huge savings, up to 89% off AesirX CMP on AppSumo
<h2>Platform Features and Benefits</h2>
<a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">AesirX Consent Management Platform</a> provides a responsible approach to managing cookies and tracking, helping businesses build trust and improve user engagement. Unlike traditional solutions that rely on third parties, AesirX takes a first-party approach, enabling greater data ownership, reliability, and compliance.
Designed to align with evolving global privacy regulations, AesirX meets the requirements of the General Data Protection Regulation (GDPR), ePrivacy Directive (ePD) 5(3), Privacy and Electronic Communications Regulations (PECR), the California Consumer Privacy Act (CCPA), and hundreds of other international privacy standards by default. Consent logic can be automatically applied based on browser language, location, and time zone, removing the need for manual configuration.
<h3>Key features include:</h3>
AesirX Consent Shield For websites concerned about unauthorized tracking, AesirX Consent Shield acts as the enforcement layer bringing an added layer of protection. It prevents selected scripts, beacons, and trackers from loading until explicit consent is given so that no data is collected prematurely.
AesirX AI Privacy Advisor For site owners looking to automate compliance without sacrificing control, AesirX AI Privacy Advisor delivers a comprehensive set of features:
<ul>
<li aria-level="2">It combines real-time analysis with intelligent automation, running two scans (before and after consent) to accurately detect third-party cookies, scripts, and beacons that require user approval.&nbsp;</li>
<li aria-level="2">Based on these results, users can apply blocking rules with the 1-Click AI Auto-Blocking feature, automatically configuring Consent Shield to restrict unauthorized activity.&nbsp;</li>
<li aria-level="2">To support documentation needs, AI Privacy Advisor also generates draft cookie declarations, privacy policies, and consent text based on real scan data, so the content in privacy documents matches how the site is actually set up, supporting legal obligations under global regulations.</li>
</ul>
Category-Based Tracking Control Administrators can define and manage all tracking technologies across clearly defined categories (e.g. analytics, advertising), allowing users to consent per type.
Google Tag Manager Support This approach improves upon Google’s Consent Mode 2.0 by fully preventing GTM scripts from running before consent, eliminating unauthorized data collection and cross-border transfers prior to user approval.
Geo-Based Consent Handling Apply consent logic automatically to align with local laws using browser language, time zone, and location – no hard-code rules needed.
GPC Signal Detection Recognizes and honors Global Privacy Control signals, complying with Do Not Track preferences where required (e.g. CCPA/CPRA).
Configurable Consent Logic Easily choose between Opt-In (e.g. GDPR for the EU) or Opt-Out (e.g. CCPA for California) models directly within the CMP dashboard, based on your legal requirements.
Customizable, Multilingual Consent Banners Customizable banners in 41 languages with different template options or editable text for full user control – matching both brand and regional UX.
Customizable, Multilingual Consent Banners Customizable banners in 41 languages with different template options or editable text for full user control – matching both brand and regional UX.
Audit-Ready Consent Logs Consent approvals, rejections, partial consents, and withdrawals are logged automatically with timestamps, allowing easy generation of audit and regulatory proof.
&nbsp;<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/bonus-1-year-privacy-monitoring-included-with-appsumo-deal.jpg" alt="bonus 1 year privacy monitoring included with appsumo deal" width="3840" height="2160" />
Bonus: 1 Year Privacy Monitoring Included with AppSumo Deal
The platform is simple to implement via a 1-click WordPress plugin and step-by-step documentation, minimizing setup time, data exposure, and tracking risks.
With this Lifetime Deal, businesses get a sustainable, audit-ready solution that simplifies privacy compliance and delivers real control without ongoing costs.
<h2>About AesirX</h2>
<a href="https://aesirx.io" target="_blank" rel="noopener">AesirX is a privacy-first platform</a> that enables businesses to manage data responsibly. From cookie-free analytics to decentralized identity management, AesirX solutions meet the highest standards of privacy and compliance, helping businesses thrive in a privacy-conscious world.
For more details and to access the exclusive Lifetime Deal for AesirX Consent Management Platform, visit <a href="https://appsumo.com/products/aesirx?utm_source=partner-link&amp;utm_medium=referral&amp;utm_campaign=partner-246752" target="_blank" rel="noopener">AppSumo</a>.
<h2>Media Contact</h2>
Ronni K Gothard Christiansen, Creator - <a href="mailto:ronni@aesirx.io" target="_blank">ronni@aesirx.io</a> 447 Broadway, 2nd Floor, Suite #1305, New York, NY, US, 10013

AesirX launches an exclusive lifetime deal on AppSumo to simplify consent management with built-in AI to reduce privacy risks for GDPR compliance.

Press Release: AesirX CMP Launch AppSumo Lifetime Deal

AesirX CMP Lifetime Deal released with 1-click AI Auto Blocking. From $69, WordPress users can easily configure rules and meet global privacy laws fast

Press Release: AesirX CMP Launch AppSumo Lifetime Deal 

Press Release: AesirX Launch Lifetime CMP Deal on AppSumo – Privacy Compliance With 1-Click AI Auto-Blocking

AesirX launch exclusive lifetime deal on AppSumo to simplify consent management with built-in AI to reduce privacy risks for GDPR compliance.

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

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

AesirX CMP for WordPress v2.0.0 Delivers Regulation-Ready Age and Country Verification Without Surveillance

Privacy Without Surveillance: Age Verification, Done Right with Zero-Knowledge Proofs

The Legal Fiction of ‘Technical Necessity’: Why CMPs and GTM Violate Consent Before You Even Click

The Hidden Surveillance Layer in Age Verification - and How We Fix It

Once-in-a-Lifetime Deal - Literally

Press Release: AesirX Launch Lifetime CMP Deal on AppSumo – Privacy Compliance With 1-Click AI Auto-Blocking

Referral Link

Share On Social Media

Revenue

NoData

Commission

No Data