Privacy Badger: an extension that learns which trackers to block

The problem Privacy Badger targets: trackers you never see

Most blocking tools start from a list. Someone maintains rules, you subscribe, and the browser refuses matching requests. Privacy Badger takes the opposite stance. The README describes it as an extension that "automatically learns to block hidden trackers", which means the decision is made from observed behaviour on the sites you visit rather than from a rule someone wrote in advance.

The audience follows from that. It is for people who want third-party tracking reduced without auditing filter lists or deciding which of several subscriptions to trust. It is also for people who care about the signals the extension emits: the README states that Privacy Badger sends the Global Privacy Control signal to opt you out of data sharing and selling, and the Do Not Track signal to tell companies not to track you. The blocking heuristic is framed as the fallback for trackers that ignore those signals.

That ordering matters. The extension's first move is a request, not a block. Only when a domain keeps behaving like a tracker does it get shut off.

How the learning heuristic changes what gets blocked over time

The mechanism is behavioural. As you browse, Privacy Badger observes third-party requests and builds a per-domain judgement about whether that domain is tracking you. Domains that look like trackers move toward being blocked; the extension's own copy calls this learning, and the repository keeps the seed data and configuration that ship with the extension under src/data, including seed.json and pbconfig.json.

Because the decision is local and accumulated, the same site can behave differently in two browsers. A fresh profile starts with less evidence than one that has been used for weeks. That is the trade-off at the centre of the design: you get blocking that adapts to what actually loads on the pages you visit, and you give up the predictability of a fixed list where the same domain is blocked or allowed everywhere, immediately.

The README also names two features beyond blocking. Click-to-activate replacements cover potentially useful trackers such as video players and comments widgets, so the embed is not loaded until you ask for it. Link cleaning applies to Facebook and Google links, described in the README as preventing those services from tracking you through the links you follow. Neither is a filter-list feature; both are attempts to keep a page usable while removing the tracking path.

Installing Privacy Badger and a first real use

The README is short on installation detail by design. It says: "To install Privacy Badger, visit the Privacy Badger homepage." There is no command-line install for end users, and no package manager entry. The homepage at privacybadger.org is the distribution point, and the FAQ there is where the project points for more detail.

For development, the repository is a WebExtension project. The Makefile defines a Firefox run target that uses web-ext, which is listed in devDependencies at version 10.7.0:

make runfa

That target runs web-ext against the src directory with the Firefox target. The equivalent command, if you prefer to call it directly, is in the same Makefile:

./node_modules/.bin/web-ext run -s src/ --target firefox

Before either works you need the dependencies installed. The Makefile's lint target invokes the local eslint binary, so the project expects node_modules to be populated:

npm install
make lint

The Makefile also has a crx target that packs the extension for Chrome using google-chrome --pack-extension and a dummy key under release-utils. That is a development and distribution helper, not something an end user needs.

Once the extension is loaded in a browser, the first real use is simply browsing. Open a few sites that embed third-party widgets and watch which domains the extension begins to block. The important thing to understand is that the first visits are a learning period. If you judge the extension on a single page load, you are judging it before it has any evidence.

Where Privacy Badger is the wrong tool

Privacy Badger is not a general ad blocker, and the README does not claim it is. Its stated purpose is blocking hidden trackers. If what you want is fewer ads, a filter-list blocker is built for that job and Privacy Badger is not a substitute.

The second limitation is the learning model itself. Blocking decisions depend on observed behaviour, so a tracker that has not yet been seen on your machine is not yet blocked. A curated list can block a domain the moment the list is updated, before you ever encounter it. Privacy Badger cannot do that for a domain it has not observed, because the observation is the input.

Third, the project's own documentation surface is thin relative to the codebase. The README covers what the extension does and where to get it, and points to the homepage FAQ, the contributor guide, the issue tracker and the discussions forum. It does not document rollback behaviour, per-site exceptions, or how to review and override the learned decisions. Those may exist in the extension UI or in the doc directory, but the README does not describe them, so do not assume a documented procedure for undoing a bad block.

Privacy Badger compared with uBlock Origin and Disconnect

The comparison people search for most is against uBlock Origin, and the difference is structural rather than a matter of tuning. uBlock Origin is a filter-list blocker: rules decide what is blocked, and the lists are curated and updated. Privacy Badger decides from observed behaviour, with a seed dataset and configuration shipped in src/data. One gives you a blocklist you can inspect and reason about in advance; the other gives you a local model that changes as you browse. Neither approach is a superset of the other.

Against Disconnect, the contrast is similar in kind. Disconnect is a list-based blocker, so its coverage is defined by the list it ships. Privacy Badger's coverage is defined by what it has seen and judged on your profile. If you want to know exactly which domains are blocked before you visit a site, list-based tools answer that question directly and Privacy Badger does not.

Privacy Badger's distinguishing feature in this group is not blocking at all. It is that the extension sends Global Privacy Control and Do Not Track, and treats blocking as what happens when those signals are ignored. A filter-list blocker has no equivalent stance. That makes Privacy Badger complementary to a filter-list blocker for some users, and redundant for others.

Maintenance, releases and what GPL v3 means for reuse

The repository is not archived, and the last push was on 2026-09-22. Releases are dated: release-2026.9.15 on 2026-09-15, release-2026.8.7 on 2026-08-07, and release-2026.6.16 on 2026-06-16. The cadence visible in those three tags is roughly monthly, which is consistent with a project that ships regularly rather than one that has stalled.

Upgrade cost for an end user is low. The extension updates through the browser's normal extension update path once installed from the homepage. There is no server component and no configuration file to migrate. For a developer building from source, the Makefile is the entry point and it has targets for data maintenance that are not part of a normal upgrade: updatepsl, updateseed, apply_effdntlist, updategoogle and updatecnames all regenerate shipped data. If you fork and rebuild, you inherit the responsibility for running those.

The README states that Privacy Badger is licensed under the GPL v3 or later, with the LICENSE file at the repository root. The repository metadata reports the license as NOASSERTION, which means the automated classifier did not reach a definitive conclusion; the README and LICENSE file are the statements to read. GPL v3 is a copyleft licence, so redistributing a modified version carries obligations that a permissive licence would not impose. That is a description of the licence, not legal advice, and anyone planning to ship a modified build should read the LICENSE file itself.

Editorial conclusion

Privacy Badger suits people who want tracker blocking without maintaining filter lists and who accept that blocking decisions are learned per browser profile rather than shipped as a curated list. It is the wrong tool if you want a general-purpose ad blocker, since its job is hidden trackers, not ads, and it will not replace a filter-list blocker for that purpose. Before adopting it, read the FAQ on privacybadger.org, check the repository's doc directory and Makefile targets to see what the project itself documents about building and running it, and confirm that the install path on the homepage matches the browser you actually use.

Frequently asked questions

Official sources

1. EFForg/privacybadger on GitHub
2. Issues
3. Project website
4. README
5. Releases