Every time you land on a website, a banner appears. Sometimes it's a thin strip at the bottom. Sometimes it's a full-screen overlay that greys out everything behind it. It asks for your consent to use cookies. You click whatever gets it out of the way fastest, and you move on.
That click is worth money. Significant money. And the design of that banner — which button is prominent, which is buried, how many taps it takes to actually say no — is not accidental. It's engineered.
This is the part the privacy policy doesn't mention: most cookie consent interfaces are built to produce a specific outcome, and that outcome is your acceptance. The law says consent must be freely given, specific, informed, and unambiguous. What most sites deliver is a UI pattern specifically designed to make the alternative feel more difficult than it actually is.
What the law actually requires
The GDPR, in force across the EU since 2018, is explicit on this point. Recital 42 states that consent should not be considered freely given if the data subject has no genuine or free choice. The European Data Protection Board's Cookie Banner Task Force report goes further, identifying specific design patterns that violate the regulation even when a "reject" option technically exists.
The core principle is symmetry: rejecting tracking must be as easy as accepting it. A single "Accept All" button on the first layer of a banner, paired with a "Manage Preferences" link that opens a submenu with seventeen toggles to switch off individually, does not meet that standard. Neither does a grey "Reject" button next to a bright green "Accept All" — the asymmetry in visual weight is itself a manipulation.
In the US, the California Consumer Privacy Act and its 2023 amendment under CPRA establish similar principles for California residents. Virginia's VCDPA followed. The FTC's report on dark patterns explicitly names cookie consent interfaces as an area of concern, noting that design choices that make opting out more difficult than opting in undermine the validity of any consent obtained.
The gap between what regulators require and what most sites actually implement is not a grey area. It's a well-documented, deliberately maintained discrepancy.
The anatomy of a manipulative banner
Cookie fatigue is a documented phenomenon. Users encounter these banners hundreds of times and, after a while, click whatever removes them fastest. Banner designers know this. The asymmetric design is a direct exploitation of that fatigue.
Here's what a manipulative consent implementation looks like at the code level:
// Typical asymmetric consent banner implementation
// "Accept" requires one click. "Reject" requires navigating a submenu.
function renderConsentBanner() {
const banner = document.createElement('div');
banner.innerHTML = `
<div class="consent-overlay">
<p>We use cookies to improve your experience.</p>
<!-- Primary CTA: prominent, coloured, first in DOM -->
<button class="btn-primary" onclick="acceptAll()">
Accept All
</button>
<!-- Secondary CTA: grey, small, hidden below the fold on mobile -->
<a class="btn-text-link" href="/cookie-settings">
Manage preferences
</a>
<!-- "Reject All" doesn't exist on this layer at all -->
</div>
`;
document.body.prepend(banner);
}
The "Reject All" option, if it exists at all, is typically three clicks deep — behind "Manage Preferences," then a settings panel, then a "Confirm my choices" button that requires all toggles to be manually switched off first. Princeton and Cornell research on consent banner effectiveness found that even when users explicitly intended to reject tracking, the majority ended up accepting it due to interface friction. The design wasn't confusing by accident. It was confusing by design.
What actually happens when you click "Accept"
The moment you accept, a sequence of events starts that most users never see. Third-party scripts that were blocked pending consent are now permitted to execute. What follows is not simply "improving your experience" — it's a data collection and distribution pipeline that operates in milliseconds.
Your IP address, browser fingerprint, screen resolution, operating system, and the full URL you were on when you accepted are packaged into a bid request. This request is transmitted to a Real-Time Bidding (RTB) exchange — an automated auction platform where advertisers compete to serve you an ad based on your profile. The entire process, from your click to the winning advertiser receiving your data, takes roughly 100 milliseconds.
// What a third-party script does the moment consent fires
document.addEventListener('consentGranted', function() {
// Fingerprinting — builds a unique identifier without cookies
const fingerprint = {
screen: `${screen.width}x${screen.height}`,
timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
language: navigator.language,
platform: navigator.platform,
plugins: Array.from(navigator.plugins).map(p => p.name),
canvas: getCanvasFingerprint() // unique rendering signature
};
// Packed into a bid request and dispatched to RTB exchanges
fetch('https://rtb-exchange.ad-network.com/bid', {
method: 'POST',
body: JSON.stringify({
user: fingerprint,
page: window.location.href,
timestamp: Date.now()
})
});
});
You don't know which companies received that request. The privacy policy lists "advertising partners" without naming them. By the time you finish reading the first paragraph of the article you came to read, your data has been auctioned to a network of buyers whose names you will never see.
Why regulators can't fix this at scale
The enforcement picture looks more active than it is. The CNIL in France and the ICO in the UK have both issued significant fines for non-compliant cookie banners. Google was fined €150 million by the CNIL in 2022 specifically because its "Refuse all" option required more clicks than "Accept all." Facebook received a similar ruling.
These are meaningful precedents. They are not a solution.
There are approximately 1.5 billion websites on the internet. Regulatory agencies do not have the staff to audit even a meaningful fraction of them. The enforcement that does happen is reactive — triggered by complaints, not proactive monitoring. A company can run a non-compliant banner for years before a complaint reaches the right desk, is investigated, and results in any action. The fine, when it comes, is a one-time cost. The data collected in the interim has already been sold.
The math doesn't work in the consumer's favour. Regulatory pressure changes industry norms slowly. Banner manipulation operates continuously, right now, on every page load.
What browser-side equalisation actually does
The approach that works at the speed of the problem is client-side intervention. Instead of waiting for a regulator to audit a site, a browser extension can inspect the consent banner's DOM structure the moment the page loads and apply the legal standard the site should be meeting anyway.
Here's the core logic of what an equalisation extension does:
// Cookie Consent Equalizer — core detection logic
function analyseConsentBanner(doc) {
const bannerSelectors = [
'[class*="cookie"]',
'[class*="consent"]',
'[id*="cookie-banner"]',
'[aria-label*="cookie"]'
];
for (const selector of bannerSelectors) {
const banner = doc.querySelector(selector);
if (!banner) continue;
const buttons = banner.querySelectorAll('button, a[role="button"]');
const buttonTexts = Array.from(buttons).map(b =>
b.textContent.trim().toLowerCase()
);
const hasAccept = buttonTexts.some(t =>
t.includes('accept') || t.includes('agree')
);
const hasReject = buttonTexts.some(t =>
t.includes('reject') || t.includes('decline') || t.includes('refuse')
);
// If there's an accept but no visible reject on this layer — asymmetric
if (hasAccept && !hasReject) {
return { asymmetric: true, banner, buttons };
}
}
return { asymmetric: false };
}
function equalise(result) {
if (!result.asymmetric) return;
// Find the accept button to mirror its visual weight
const acceptBtn = Array.from(result.buttons).find(b =>
b.textContent.toLowerCase().includes('accept')
);
if (acceptBtn) {
const rejectBtn = acceptBtn.cloneNode(true);
rejectBtn.textContent = 'Reject All';
rejectBtn.style.cssText = acceptBtn.style.cssText;
rejectBtn.onclick = () => triggerRejectAll(result.banner);
acceptBtn.parentNode.insertBefore(rejectBtn, acceptBtn.nextSibling);
}
}
The extension doesn't override the site's consent system — it adds the option the site should have included in the first place. The "Reject All" button it injects triggers the same rejection pathway that exists deeper in the site's own consent management platform, just surfaced to where the law says it should be: the first layer, with equal visual prominence.
The broader pattern
Cookie banners are one instance of a wider category the FTC calls "dark patterns" — interface design choices that steer users toward outcomes that benefit the company at the user's expense. The same asymmetric design principle appears in subscription cancellation flows, trial-to-paid conversion screens, and pre-ticked opt-in boxes for marketing email.
What makes cookie consent a useful case study is that it's the most visible example, it's explicitly regulated, and the gap between what the law requires and what sites deliver is measurable and documented. Academic research has quantified it. Regulators have named it. The industry has continued anyway, because the enforcement cost remains lower than the data revenue.
The consumer-side response to that calculation is tooling that doesn't depend on enforcement timelines. A browser extension runs on every page, every time, regardless of whether a regulator has looked at that particular site. It applies the standard the law already requires without waiting for anyone else to notice the violation.
That's not circumventing anything. It's just enforcing what the regulation already says, at the speed the problem actually operates.
Cookie Consent Equalizer
A browser extension that detects asymmetric cookie banners and surfaces a "Reject All" option at the first layer — where the law says it should be. No configuration required.
For users: Get it on Gumroad →
For developers: The full source code — DOM scanner, consent pathway detector, and equalisation logic — is available for commercial use.
Top comments (2)
The detection logic makes sense, an accept button with no reject on the first layer is a clean signal to key off. Where I'd love more detail is triggerRejectAll. Every consent platform buries its real reject action somewhere different, OneTrust, Cookiebot, and a custom one all wire it up their own way, so cloning the accept button is the easy half and firing the site's actual reject path is the hard half. Do you walk the deeper settings panel and flip each toggle, or is there a per platform adapter behind that function? That's the bit that decides whether the injected button really rejects or just looks like it does.
This was a great breakdown. I'm curious if