Runet Censorship Bypass: a PAC-script extension for Russia

The problem: a blocklist that changes faster than your VPN

Russian site blocking is enforced against addresses, not against categories. The project's README describes the mechanism plainly: on every request the PAC script checks if the host is blocked or if its IP is blocked, and if an address is blocked, the script returns the proxy server to the browser. That is the whole idea. Traffic to unblocked hosts goes out directly, with no proxy in the path, and only the addresses that appear on a blocklist are rerouted. For someone in Russia who needs a handful of news sites, that is a materially different trade from a full-tunnel VPN, which moves every request including banking and government portals that are often hostile to foreign exit IPs. The extension is aimed at individual browser users, not at network operators, and it assumes you are running Chrome, Chromium, Edge, Firefox or Opera on a desktop. The README says nothing about Android or iOS builds, and the repository layout shows only an extensions/ directory and a package.json whose main dependency is the Open Collective postinstall script, so there is no server component to run yourself.

How the PAC script decides, and where the blocklist comes from

A PAC script is a JavaScript file, triggered on every URL request, which tells the browser which proxy to use if any for this particular URL. The extension sets that file in browser settings and keeps it synced with the copy on the server. Two built-in scripts are offered as a user choice: Antizapret, hosted on a dedicated server, and Anticensority, hosted on GitHub. They differ in what they do with a blocked request. Antizapret's PAC script returns its own proxy servers; Anticensority's PAC script returns local Tor. Neither list is hand-maintained inside this repository. The README states that PAC scripts on servers are updated periodically from the zapret-info/z-i repository, which is the community mirror of the Russian registry. That dependency is the design's weak point as much as its strength: the extension itself is thin, and the accuracy of blocking decisions is inherited from an external data source that updates on its own schedule. The extension also cannot see inside TLS, so the host and IP checks described in the README are the extent of its judgement. A site blocked by SNI filtering on a shared CDN address may behave differently from one blocked by a dedicated IP, and the README does not document how the PAC script resolves that ambiguity.

Installing it and making the first blocked request

The README lists packaged installs for Chrome Web Store, Microsoft Edge Add-ons and Firefox Add-ons, plus a MINI variant on Chrome and Edge. Opera users are told to install the Opera extension installer from the WebStore first, then follow the Chrome entries. There is no npm or pip install path; the repository's package.json exists to run the Open Collective postinstall hook, not to ship the extension. For a normal user the first step is the store listing:

# No CLI install. Open the store listing in your browser:
# https://chrome.google.com/webstore/detail/npgcnondjocldhldegnakemclmfkngch

The README warns that Google address blocking may prevent installation from the WebStore. When that happens it points to the offline packages on the releases page and to a wiki page titled Автономная-установка-расширения for the manual procedure:

# Offline installation packages:
# https://github.com/anticensority/runet-censorship-bypass/releases

After installation, the extension writes a PAC script into browser settings and keeps it synced. You should see the extension's own settings surface where you pick Antizapret or Anticensority. Picking Antizapret means blocked hosts go through Antizapret's servers. Picking Anticensority means they go through Tor running on your own machine, and the README does not document how that local Tor instance is provisioned or started, so treat that option as one you must verify yourself before relying on it. To confirm the extension is doing anything at all, load a host that appears on the current blocklist and watch whether the request leaves through the proxy; a host that is not on the list should resolve directly.

The Manifest V2 problem and the release cadence

The most recent release listed for this repository is 0.0.1.63, dated 2024-03-29, and its own release title says it is the last release in Manifest V2 format. Two earlier release candidates, 0.0.1.53-rc0 and 0.0.1.52-rc0, date from 2021. Nothing in the repository shows a Manifest V3 build. That matters because Chromium's extension platform has been moving away from V2, and an extension that sets a PAC script through browser settings is exactly the kind of capability that platform changes tend to constrain. The repository is not archived and the last push was on 2026-08-03, so there is ongoing activity, but activity is not the same as a shipped V3 extension. A reader searching for a manifest v3 version of this tool will not find one documented here. If your browser has already stopped loading V2 extensions, the store listing and the offline packages will not help you, and the README offers no migration note.

When this is the wrong tool

The extension only covers the browser it is installed in. Anything outside that browser, including native apps, system updates and command-line tools, is untouched. It also has no answer for protocol-level blocking that does not present as a hostname or IP match, and no answer for a blocklist entry that has not yet propagated from zapret-info/z-i. The Antizapret option concentrates trust: every blocked request is visible to Antizapret's proxy servers, and the README does not describe any encryption or logging policy beyond the fact that the servers are dedicated. The Anticensority option avoids that concentration but shifts the burden onto a local Tor setup the README does not explain. If your threat model includes an adversary who can correlate your direct traffic with your proxied traffic, per-request routing is a weaker pattern than a uniform tunnel, because the direct requests reveal what you are not trying to hide. And if you need a mobile client, this is simply not the project: the README lists desktop stores only.

Censor Tracker and the difference in approach

Censor Tracker is the obvious comparison for a Russian-speaking user choosing between extensions. The difference is where the intelligence lives. This project keeps a PAC script in charge of per-request decisions and derives its blocklist from zapret-info/z-i, with the proxy endpoints supplied either by Antizapret or by local Tor. Censor Tracker is described in the search results as a proxy for privacy and security rather than as a PAC-script generator, which points to a different architecture: proxy selection managed inside the extension rather than delegated to a browser-level PAC file. That distinction has practical consequences. A PAC script applies to the whole browser profile and to every request the browser makes, including requests from pages you did not intend to route, whereas an extension-managed proxy layer can scope its decisions differently. Neither approach is strictly better; the PAC model is simpler to reason about and easier to audit, because the decision logic is a single JavaScript file the browser executes. If you want to read the exact rule that decided a request, the PAC model gives you that. If you want the extension to own the proxy configuration end to end, it does not.

Licence and the cost of keeping it working

The repository is licensed GPL-3.0, while the root package.json declares ISC for the packaging metadata. That split is worth noticing if you plan to fork or redistribute: the extension source under extensions/chromium/runet-censorship-bypass is the part the GPL-3.0 LICENSE file governs, and the package.json licence field describes a small npm wrapper around Open Collective, not the extension. GPL-3.0 means a modified distributed version must carry the same licence and source. This is not legal advice; if you are embedding the extension in a product, read the LICENSE file and the extensions/ directory yourself. On upgrade cost, the release history shows the shape of the problem: the newest release is from 2024 and is explicitly the last V2 build. Anyone running this is therefore on a branch that the release notes themselves describe as terminal for its format. The maintenance burden is not in the extension's code, which is small, but in tracking two external moving parts, the zapret-info/z-i list and the browser's extension platform.

Editorial conclusion

Adopt it if you browse from Russia on Chromium or Firefox and want per-request proxy selection rather than a VPN that moves all traffic. Do not adopt it if you need Android, if you cannot tolerate a Manifest V2 release, or if you want a tool whose maintainers have shipped a new version in the last two years. Before installing, check the offline package release page, confirm whether your browser still loads a Manifest V2 extension, and decide up front whether you will point the PAC script at Antizapret's servers or at your own local Tor instance, because that choice determines who sees your traffic.

Frequently asked questions

Official sources

1. anticensority/runet-censorship-bypass on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases