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