DEV Community

GlenKit
GlenKit

Posted on

Hiding a cookie banner is not consent — what actually happens when you click "Reject all"

Most banner blockers do the same thing: they hide the banner with CSS and call it a day. The banner is gone from your screen — but nothing was ever told to the site. The tracking scripts you were shown a choice about? They load anyway. You got the appearance of consent without the mechanism.

I spent the last few months building a browser extension that takes the other approach: instead of hiding banners, it presses the real "Reject all" button — or calls the consent platform's own API when one exists. Here's what I learned about how consent actually works under the hood, and why "hiding" and "rejecting" are legally very different things.

What "Reject all" actually triggers

When you click a real reject button, one of several things happens depending on the consent management platform (CMP) the site uses:

  1. A consent cookie gets written with an explicit deny state. The site's tag manager reads it on every subsequent page load and withholds non-essential scripts.
  2. A JavaScript API is called — most major CMPs expose an API of their own, which propagates into an event that third-party scripts listen for.
  3. In some setups, a server-side endpoint is hit to log the opt-out.

The point: rejection is a state change, visible to the site and to every script that respects the framework. Hiding the banner is a visual change, visible only to you.

The long tail is the hard part

The big consent platforms are easy — each has documented APIs and stable DOM structures. A couple dozen platforms by name covers a huge share of the web.

The long tail is everything else: regional CMPs, self-hosted script snippets, and sites that roll their own banner. For those, the extension ships a text-matching fallback that recognizes reject-style buttons across 35 languages — because "Refuser tout", "Alle ablehnen" and "拒绝全部" all mean the same thing, and your blocker should speak all of them.

It also sends the Global Privacy Control (GPC) signal on every page, which several US state laws now treat as a binding opt-out.

One more detail that matters: after clicking, the extension verifies the banner is actually gone — because a click that silently failed is worse than no click: you think you opted out, and you didn't.

Why not just block everything?

Because that breaks sites, and because it's not what you asked for. A real consent framework gives you a choice; the respectful default is the one privacy law actually contemplates: non-essential tracking off, site functional, zero data sent anywhere.

That last part is the design constraint I'm proudest of: the extension itself is 100% local. No account, no analytics, no telemetry. It stores exactly two things per site — the hostname and your choice — and you can wipe it anytime.

Try it

CookieGuard runs on Chrome and Edge. The free tier gives you 40 successful rejections a week with every detection feature enabled; Pro ($19.9 lifetime or $11.99/year) lifts the cap and adds per-site defaults.

We're also launching on Product Hunt — if you've ever wondered whether your "Reject all" click actually did anything, it's a fun rabbit hole.

Happy to answer questions about consent-platform internals in the comments — it's a weirder ecosystem than you'd expect.

Top comments (0)