Kill the cookie banner (or stop pretending it protects anyone)
July 31, 2026
A manipulative cookie banner does not protect your visitors. It protects the story that they agreed to be tracked. Sites that bury Reject under three settings panels never collected meaningful consent. Sites that load analytics, pixels, and ad tags the moment someone mashes Accept are using the modal as cover, not as a choice.
The useful question is not how to style the modal. It is whether the site needed non-essential device storage at all.
The banner was never the requirement#

The pop-up epidemic is usually blamed on the GDPR. That is the wrong statute for the sticky part. GDPR.eu's cookie guide points at the ePrivacy Directive, amended in 2009, as the rule that earned the nickname "cookie law" because consent pop-ups exploded after it.
For sites that fall under the EU ePrivacy baseline (as implemented in national law), the practical ask is blunt. Before the site stores information on a device, or reads information already stored there, it needs the visitor's consent, except for cookies that are strictly necessary to deliver a service the visitor asked for. Other jurisdictions can differ. The common cargo-cult mistake is treating a pastel modal as a universal checkbox for every homepage on earth.
Login sessions. Shopping carts. Load balancing. Security tokens. Those can land without a prior modal. Analytics cookies do not get that free pass. The old Article 29 Working Party said first-party analytics fall outside the consent exemption even when the privacy risk is low (Opinion 04/2012).
So a site that only sets a session cookie and never loads a tracker is not missing a banner. It is already inside the exception. A site that injects Google Analytics, Meta pixels, and a heat-map script, then wraps them in a CMP, is not "complying with privacy." It is buying a permission dialog for the stack it chose.
Most banners are built to harvest yes clicks#

If the banner were protection, Reject would be as easy as Accept. On a large share of high-traffic properties it is not.
Accept All is one fat, high-contrast button. Reject hides behind Manage preferences, then a second screen of toggles, then Save.
- Pre-ticked marketing categories still appear on first load.
- Some walls block the page until the visitor clicks something.
- Some treat scrolling as consent.
- Some ask again on the next visit after a clear no.
That pattern is widespread enough that regulators treat unequal ease as a real failure mode, not a UI nit. Consent tooling is often sold on higher opt-in rates. A modal that is honest about tracking loses that sales metric. A modal that steers the hand toward yes wins the dashboard and loses the visitor.
Regulators already priced the equal-ease rule. In late 2021 France's CNIL fined Google €150 million and Facebook €60 million because refuse was harder than accept on major properties. CNBC quoted the watchdog directly. The sites "do not allow to refuse cookies as easily as it is to accept them" (CNBC).
A banner that fails that test is not protecting anyone. It is manufacturing a paper trail for tracking the visitor would have rejected if Reject sat next to Accept.
Zero trackers, zero Set-Cookie, zero banner#

Protection looks boring in the response headers.
On 2026-07-31 a plain curl of the rizz.dev homepage returned zero Set-Cookie headers. No analytics script tags. No consent overlay. The same probe against news.ycombinator.com and plausible.io also returned zero. The New York Times homepage returned seven Set-Cookie headers. The Guardian returned eight.
Sites that refuse non-essential tracking do not need a consent wall on the door. Sites that load a tracker zoo need one. Many of those still ship a first layer that makes Accept the only easy path.
The same contrast shows up in the product decision. Drop third-party analytics and most marketing pixels, keep only what the product actually needs for login or payments, and the legal surface shrinks with the stack. That is the same privacy instinct as treating middleboxes honestly in Cloudflare Is the Biggest Man-in-the-Middle in History. Name the trade. Do not hide it under a pastel Accept button.
If ads fund the site, the banner is the bill#
Some products live on retargeting, multi-touch attribution, and ad platforms that only work with device identifiers. For those stacks a consent UI is not optional theater. It is the cost of the business model under EU rules.
Own that cost. Equal Reject on the first layer. No pre-ticked marketing categories. No scripts that fire before a real yes. Withdrawal as easy as the original click. Document what was accepted.
What fails the job is dressing that stack in a caring-privacy banner while Accept is the only one-click path. The law asked for consent. The design asked for surrender.
If the ad model cannot survive an honest Reject rate, the problem is the model, not the visitor who clicked no.
Delete the reason for the banner first#

Monday work is a strip list, not a CMP theme pass.
- Inventory every third-party script and cookie purpose on the site.
- Delete anything that is not strictly necessary for a feature the visitor asked for.
- Replace "GA is required for everything" with first-party, aggregate, or cookieless analytics if page counts still matter. Re-check the product against ePrivacy storage rules rather than marketing claims.
- If non-essential tracking remains for ads or product analytics that touch the device, ship a banner with Accept and Reject as equal first-layer actions and block those scripts until yes.
- Write a privacy page that matches the stack that actually shipped.
Consent fatigue is real enough that the UK's information commissioner has treated cookie pop-ups as a global nuisance problem (BBC). Fatigue is not fixed by a prettier CMP. It is fixed by fewer sites demanding a decision they should never have forced.
Kill the cookie banner when the trackers are gone. Keep an honest one when ads still need a device identifier. Stop pretending the modal itself was the protection.
A banner earns its keep only when three checks pass on a cold visit. Reject sits on the first layer next to Accept. Non-essential scripts stay blocked until a real yes. No non-essential device access runs by default. Fail any one of those and delete the theater before polishing the theme.
