I Still Don't Care About Cookies: the debloated cookie-banner fork for Chrome, Firefox and Edge

Why this fork exists at all

The original I Don't Care About Cookies was acquired by Avast, which itself sits under Gen Digital. The README states the maintainer's reason plainly: "I simply don't trust Avast with my data." That is the whole pitch. The fork keeps the extension's job and moves development to a public repository, where the README argues website support can be added faster.

The audience is narrow but real. It is for people who already wanted cookie banners gone and who are unwilling to run a build controlled by a company they do not trust. It is not for someone looking for a general privacy suite, and it is not a tracker blocker. The extension's stated purpose is to get rid of cookie warnings, nothing broader.

How the rule list and the API divide the work

Two mechanisms sit side by side. The first is a local rule file, src/rules.json, generated by a script in the repository. The second is a remote service at api.istilldontcareaboutcookies.com, which the extension queries. The README describes the API as backend-facing software whose source lives in a separate GitHub repository and is written with the C# ASP.NET MVC library.

That split matters more than it first appears. Local rules handle the sites someone has already written a rule for, and they work with no network call. The API presumably covers the long tail and sites whose markup changes often, but the README does not spell out the fallback order, what happens when the API is unreachable, or how much of a page's behaviour is decided remotely. If you care about that boundary, the extension's own code is the only place to check it, and the README will not answer it for you.

A rule can be added through tooling rather than by hand. The package.json defines add-rule and generate-block-rules scripts, the latter writing to src/rules.json before Prettier reformats the file. The dependency list includes acorn, a JavaScript parser, which suggests rules are derived by parsing page scripts rather than by pattern-matching raw HTML. The README does not document that pipeline, so treat it as an inference from the dependency and script names, not a stated design.

Installing it from the store or from source

The README lists three store links: Firefox Add-ons, the Chrome Web Store and Microsoft Edge Add-ons. There is no build-from-source instruction in the README itself. Manual installation is delegated to two wiki pages, one for Firefox and one for Chrome, linked under the heading "Manual installation".

If you want the packaged extension, use the store for your browser. The Edge listing is a separate URL from the Chrome one, so do not assume the Chrome package is what Edge users should install.

For working on the code, the repository is a Node project. The scripts below are the ones package.json actually defines; there is no build script among them.

npm install
npm run lint
npm run generate-block-rules

The first command installs the dev dependencies listed in package.json: eslint, eslint-config-prettier, globals and prettier, plus acorn, commander and packages as runtime dependencies. The second runs ESLint over src and the repository root. The third regenerates src/rules.json from the tools directory and pipes it through Prettier. Running the third command rewrites a tracked file, so expect a diff.

Adding a single rule goes through the add-rule script, which wraps tools/add-rule.js:

npm run add-rule

The README does not document the arguments this script accepts, so check tools/add-rule.js before running it. Translation work does not happen in the repository at all; the README points contributors to a Crowdin project.

The API is the part you cannot inspect from the README

Every install of this extension talks to a server the maintainer operates. The README is upfront that the API exists and that its source is public in a separate repository, which is more than many extensions offer. It is still a dependency you take on.

Three things are not answered in the README. What data the request carries, whether any identifier is attached, and what the extension does when the API returns nothing useful. The repository does include a PRIVACY_POLICY.md at the top level, and that file, not the README, is where those questions belong. Anyone evaluating this for a managed fleet should read it before rolling the extension out.

The practical consequence: a site with no local rule depends on a network round trip to a third-party host. On a locked-down network, or in a browser profile that blocks third-party requests, the API path may not work while local rules still do. The README does not describe that degradation.

Where it is the wrong tool

The README lists Firefox, Chrome and Edge builds. The related searches show people asking about Android, iPhone, Opera and Opera GX, and the repository material does not answer any of those. Opera and Opera GX can typically install Chrome Web Store extensions, but this README does not say so, and neither does it mention any mobile build. If a phone browser is your target, this project gives you nothing to install.

There is a second limitation that is easy to miss. Hiding a consent banner is not the same as refusing cookies. The extension removes the interface; it does not change what the site's own scripts do, and the README makes no claim about which cookies end up stored. If your goal is to control what a site writes to your browser, this is the wrong layer. Use a content blocker with cookie rules or a browser that blocks third-party cookies by default.

A third case: sites that gate content behind the banner. If a rule hides the dialog without triggering the accept path the site expects, the page may stay unusable. The README does not discuss this failure mode, and it is the kind of thing that shows up site by site rather than in documentation.

How it differs from a general content blocker

The obvious comparison is uBlock Origin with a cookie-notice filter list. The approaches are not the same. uBlock Origin matches network requests and DOM elements against filter lists you choose and can audit, and it runs entirely locally. This extension ships a curated rule set plus a live API, and its rules are written to interact with a page's consent logic rather than only to hide an element.

That difference cuts both ways. The API can react to a site redesign without waiting for you to update a list, which is the argument for the design. It also means a server the maintainer controls participates in your browsing, which a filter list does not. If you already run uBlock Origin with a cookie list and it works on the sites you use, adding this extension buys you little and costs you a second source of rules. If you hit banners that list misses, the API is the reason this project might still be worth installing.

The fork's own lineage is the other comparison. It is based on version 3.4.3 of the original extension, which the README notes was distributed under GPLv3. The upstream project is now Avast-owned. Choosing between them is a question about who runs the backend, not about what the extension does.

Licence, maintenance and the cost of upgrading

The licence is GPL-3.0, and the README states the fork is based on v3.4.3 of the original, which was distributed under the same licence. For anyone embedding this in a product, GPL-3.0 is a copyleft licence with obligations that differ from permissive licences, and the source of the original extension is part of the lineage. That is a factual note, not legal advice; talk to someone qualified if you plan to redistribute.

The last push to the default branch was on 2026-09-23, and the repository is not archived. Recent tagged releases are v1.1.9, v1.1.8 and v1.1.7, and package.json carries version 1.1.9, so the manifest and the latest tag agree.

Upgrade cost is low for users and moderate for contributors. Store installs update on the browser's schedule. Self-built copies need a manual reload, and if you have edited src/rules.json, regenerating it with generate-block-rules overwrites your changes. Keep local rules in a separate branch or expect to reapply them. The README does not document a rollback path for a bad release, so pinning a specific release from the releases page is the only lever the repository offers.

Editorial conclusion

Adopt it if you want the original extension's behaviour without the Avast-owned build, and you accept that a remote API sees which sites you visit. Skip it if you need a mobile browser, since the README lists only Firefox, Chrome and Edge builds, or if you want to audit every rule locally, because the API path is a network dependency. Before installing, read PRIVACY_POLICY.md in the repository and the wiki installation guide for your browser, then check whether the release you download matches the version in package.json.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. OhMyGuus/I-Still-Dont-Care-About-Cookies on GitHub
4. README
5. Releases