Deny Cookies

Cookie banners are a tax on every new site. I paid it for years, then went looking for something to pay it for me.

Most of what's on offer hides the banner. That sounds like the same thing and isn't. The pop-up goes away, the consent question stays unanswered, and the tracking carries on. Hiding breaks pages too. The scroll lock stays, the buttons stay dead. And I don't care about cookies clicks Accept when hiding breaks the site. Some tools do genuinely reject, Consent-O-Matic and Ghostery among them.

So I wrote one that clicks reject.

It drives the site's own consent UI. Easy case: a reject button on the banner, found and clicked. Common case: no reject button at all, so it opens the preferences panel, switches every non-essential category off, and hits Save. Never Accept: the Save control is matched against a list that excludes every accept word. It carries rules for 17 consent systems, seeded from DuckDuckGo's autoconsent and Consent-O-Matic, and falls back to a generic engine whose reject and save vocabularies run to ten languages, Japanese, Chinese and Korean included. Where a site uses TCF it reads the consent string back to check the answer stuck, and prints it raw in the popup.

Finding the banner was the hard part

I assumed rejecting was the difficult bit. I ran 22 live sites through the shipped code, and detection was where the coverage was going, in three ways.

The detector could only enumerate banners that named themselves, with an id or class containing cookie, consent, gdpr. That naming is optional. x.com is the pure case: no cookie token, no aria-label, no dialog role anywhere, and a "Refuse non-essential cookies" button my reject vocabulary already matched. So a second route searches for the control and climbs to what contains it, and the container has to be an overlay. Otherwise a page footer with a Cookie Policy link reads as one.

The other two faults mattered more. A failed attempt was terminal, so one early miss ended the hunt for that page. On onetrust.com the miss was an Adobe CMS naming its blocks cmp-container, where cmp means content management page. And anything mounting after ten seconds was unreachable.

Resolved banners went from 10 of 18 to 16 of 18 across those sites. All six gains came from the two lifecycle fixes, not from the control-first search. That class barely shows up in a corpus of big publishers, so its evidence is a harness scenario built from x.com's captured DOM.

It stops rather than guess

The panel walker refuses to improvise. If a toggle's state lives only in a CSS class and can't be read, or its label can't be matched to a known category, the pass bails and touches nothing further. The banner stays, marked amber on the page. A wrong guess there can switch something on. Leaving it is better. If a site won't work without a choice, it asks you once, and remembers.

Banners saying "by continuing to browse you agree" have nothing to reject. They're graded red rather than green, and the known tracking cookies are wiped at the start of every visit on those hosts. It doesn't block their scripts. Analytics still run while you're there. What it stops is the ID carrying over.

What it doesn't do

Chrome only. No Firefox or Safari build, and that's a gap. It isn't an ad blocker and won't become one, which is a decision. A banner mounting more than about 90 seconds after load is missed until the next page load, because it stops watching rather than cost you performance forever. Also a decision.

Pre-launch. It isn't on the Chrome Web Store, so installing means loading it unpacked. The 55 unit tests pass, there's a browser harness for what a headless runner can't reach, and I've run it against live sites. Nobody else is running it.

Stack: Chrome MV3 and plain JavaScript, no build step and no dependencies, because an extension you can load unpacked and read straight through is easier to trust than a bundle. The rules are a JSON file rather than code, so fixing a site is a data edit.