Censor Tracker: a censorship circumvention extension for Chrome and Firefox

What the extension does and where it lives

Censor Tracker is a censorship circumvention browser extension for Google Chrome and Mozilla Firefox, published on the Chrome Web Store and as a Firefox add-on, and the project site is censortracker.org.

What it does is stated in the feature list. There are configurable proxy settings, country specific proxy routing, customisable proxy and exclusion lists, and built-in resistance to censorship. It also warns on websites that share user data with third parties, which is a separate concern from blocking and is a reasonable thing to see in the same tool.

The more interesting capability is the protocol support. The extension enables the use of custom proxies and supports Vless, Vmess and Shadowsocks in the browser through an external client called Censor Tracker Proxy, which lives in its own repository. The README is explicit that this client is required for those protocols, so the extension alone is the simpler path and the protocols are an additional component.

The default branch is stable, the primary language is listed as HTML, and the topic tags cover the ground the project works in: addon, brave, censorship, chrome, chromium, dpi-filtering, firefox, microsoft-edge, mozilla, proxy, shadowsocks, vless, vmess, webextension and xray-core.

The licence field on the repository says MIT, and the README confirms Censor Tracker is licensed under the MIT License.

The permission list, and why each one is there

The permissions section is the most useful part of the README for anyone deciding whether to install it, because a proxying extension asks for a lot.

The alarms permission enables periodic tasks such as database synchronisation and re-requesting the list of proxy servers, which is how the extension keeps its blocklist and its proxy list fresh. The activeTab permission detects IDO websites, which the README says is primarily relevant for Russian users, so that is a locale-specific feature rather than a general one. The management permission identifies permission conflicts, for example with other extensions, which is a thoughtful touch given that proxy extensions often collide with ad blockers.

Then notifications for the warnings, proxy for configuring and using the proxy servers, storage for saving user preferences, and unlimitedStorage for the database of blocked websites, which the README explains is because of its large size. The webNavigation permission manages and monitors web requests.

And finally the two host permissions, for http and for https on all URLs. The README gives three reasons: allowing website proxying, retrieval of proxy server lists, and user country detection, which is required for country specific proxying.

So the permission set is broad, and every entry has a stated purpose, which is a better position than a proxy extension that asks for everything without explanation.

The build system and the two store targets

The development section describes a Node and npm toolchain, with node v17.4.0 or higher and npm 8.3.1 or higher, and it optionally suggests nvm for managing versions.

The build is a two step process, and the first step is a plain install of the dependencies.

~ npm install

The second step is the webpack build, with a separate command per browser, and the built extension lands in a per-browser directory.

~ npm run build:chrome
~ cd dist/chrome

~ npm run build:firefox
~ cd dist/firefox

The package.json shows how much of the variation is handled by environment variables rather than by separate configuration. Every build script sets NODE_ENV and BROWSER, and the development and production variants differ only in that pair, with the production ones running the same webpack config with --progress.

The release scripts use the web-ext tool to package the built directory into an artefact, with a combined release target that builds Firefox and then Chrome.

"release": "web-ext build -o --source-dir=./dist/firefox/prod --artifacts-dir=./releases/firefox && web-ext build -o --source-dir=./dist/chrome/prod --artifacts-dir=./releases/chrome"

There is also a watch target for each browser, a lint target and a stylelint target, and a pair of locale scripts, one to format the translation files and one to check them, with a tasks/ directory holding those Node scripts. The Makefile is a thin wrapper over the npm scripts, with chrome, ff and clean targets.

What the build output tells you about the project

The package.json is worth reading for what it does not contain, because the shape of a proxy extension's dependencies is a design document.

The runtime dependencies are axios for HTTP requests, tldts for parsing and extracting the registrable domain from a URL, validator for input validation, and codemirror, which is a text editor component.

The tldts and validator pair is the interesting one. Parsing the registrable domain correctly is what lets the extension decide whether a hostname is on the blocklist, and validating input is what stops a malformed configuration from breaking the proxy routing. Those two are the whole matching engine, which tells you the blocklist is matched on domain rather than on anything more elaborate.

Codemirror is there because the extension lets you edit the proxy and exclusion lists by hand, so there is a text editor embedded in the settings.

The main entry is dist/index.js, and the package is marked as an extension rather than a library, with a description field that is simply a pipe character.

The repository layout is small and conventional for a browser extension: src/ for the source, tasks/ for the locale tooling, a webpack config, a tsconfig, a babel config, an eslint config, a stylelint config, a Makefile, a CHANGELOG.md and a CONTRIBUTORS.md.

The one thing the repository does not contain is the proxy infrastructure itself. The proxy servers and the external client are separate projects, so this repository is the browser side of a larger system.

Where Censor Tracker is the wrong choice

The first limitation is the scope. It is a browser extension, so it only affects the browser, and an application that makes its own network connections outside the browser, or a command line tool, is not covered by it. For a user whose whole problem is a blocked application rather than a blocked website, this is the wrong layer of the stack.

The second is that the protocol support depends on another installation. Vless, Vmess and Shadowsocks are supported in the browser only through the Censor Tracker Proxy client, which is a separate repository and a separate thing to configure. Someone who wants Shadowsocks in the browser has to set up a local client first.

The third is the reliance on a shared infrastructure. The extension fetches a list of proxy servers, and the alarms permission exists to re-request that list. A pool of shared proxies is a best-effort mechanism: some of them will be slow, some will be blocked, and none of them is a guarantee.

The fourth is the dependency on a maintained blocklist. The database of blocked websites is synchronised from somewhere, and the extension stores it locally with unlimitedStorage because it is large. The quality of the extension is therefore substantially the quality of that database, and the README does not publish anything about how it is produced.

The fifth is the age of the release line. The recent releases listed are 18.7.0-preview from 2024-11-19, 18.6.0-preview from 2024-10-28 and 18.0.0 from 2023-08-31, while the package.json version is 20.0.0, so the published build numbers and the source version have diverged and the two previews suggest an in-progress line.

How Censor Tracker compares with a system proxy and with a VPN

The comparison with a system proxy is the most direct one, and the difference in approach is where the traffic is redirected. A system proxy or a VPN client handles every connection from the machine, so an application that ignores the browser is covered. A browser extension handles the browser's traffic, which means it needs no system configuration and no elevated privileges, and it also means the coverage stops at the browser.

That is a genuine advantage in some environments. On a locked-down corporate machine, a user may not be able to install a VPN client, but an extension from the store installs without administrator rights.

The second comparison is with a VPN, and the difference is the trust model. A VPN is a single operator you trust with your traffic, and it gives you a stable exit address. Censor Tracker uses a pool of proxies, so your exit address varies and you are trusting an infrastructure you did not choose, which for a privacy tool is a slightly awkward trade.

The third comparison is with a censorship-resistant DNS resolver or a filtering gateway. Those work at the network level and cost nothing per device, and they only handle name resolution, so they cannot help with a site that resolves correctly but is blocked afterwards.

The fourth comparison is with the do-it-yourself approach of running Shadowsocks or Xray locally. That gives full control and better performance, and the README itself points at the Censor Tracker Proxy project for exactly that, so the extension can be seen as the approachable front end for a setup the user could otherwise do by hand.

Licence, project state and what to check before installing it

The licence field on the repository says MIT, and the README confirms it and links the LICENSE file. A permissive licence is the right choice for a browser extension, since the point of publishing it is that people can build on it.

The project is not archived and the last push was on 2026-07-31, so it is maintained, and the recent releases show a preview line from late 2024 while the package version has moved on to 20.0.0, which suggests the source is ahead of the last tagged store build.

The browser support list is explicit: Mozilla Firefox 98 or higher, and Chromium 94 or higher, which covers Google Chrome, Brave, Edge and Opera.

Four things to check before you install it.

The permission list, which you have now read. The extension asks for host access to every http and https URL, for webNavigation, for alarms, for proxy, for storage and for unlimitedStorage, and that is the cost of doing proxying inside a browser.

Whether you need the external proxy client. If your requirement is Shadowsocks or Vmess in the browser, the Censor Tracker Proxy project is a prerequisite, and you are then running two pieces of software rather than one.

Which store build you are getting, since the store versions are numbered in the high teens while the source is at 20, and the store build is what most people will actually install.

And the troubleshooting note in the development section, which says that if you hit an error building with npm you should check that your shell supports per-command environment variables, with the example of setting NODE_ENV inline for a production build.

Editorial conclusion

Censor Tracker suits a user in a network where sites are blocked and who wants a browser-level fix without configuring a system proxy, and it is a readable reference for anyone building a similar extension. It is the wrong tool if you need full device coverage rather than browser coverage, since the external proxy client is a separate installation for the protocol support, and the wrong choice if you need a guarantee, because a proxy pool and a blocklist are both best-effort. Before you rely on it, check the browser versions it supports and read the permission list, since the extension asks for broad host permissions and that is the price of the proxying.

Frequently asked questions

Official sources

1. censortracker/censortracker on GitHub
2. License: MIT
3. Project website
4. README
5. Releases