Adblock-Rule-Collection: one subscription built from seven upstreams, twice a year a day

Ten files, because five filter targets times two editions

The output shape is the first thing to understand, and it is a five by two matrix rather than a single list.

The five targets are an ad filter list, a DNS filter list, a host list, a host list for IPv6, and a domain blocking list. Each of those exists in a full edition and a Lite edition, which comes to ten files named with a common ADBLOCK_RULE_COLLECTION prefix. So the naming is ADBLOCK_RULE_COLLECTION.txt for the full ad filter list, ADBLOCK_RULE_COLLECTION_Lite.txt for the reduced one, and the same pair with _DNS, _HOST, _HOST_IPV6 and _DOMAIN inserted before the extension.

The distinction between them is not depth, it is source. The full edition pulls from all seven upstreams, and the Lite edition contains only the AdGuard official lists. That is stated as the recommendation: the documentation says the full version will have many false positives and advises using the Lite version instead.

The repository also carries a Whitelist.txt and a timestamp.txt at the root, so the whitelist exceptions and the build time are both inspectable rather than baked invisibly into the merged output.

The project warns against its own full edition, and says why

The warning section is the most useful part of the documentation, and it is unusually blunt about the trade-off.

The stated risks are that the subscription may break the functionality of some websites, and that it may block certain adult and gambling sites. The project asks you to think before using it, and says that if a false positive occurs you should report it upstream rather than to this repository, because the repository's stated job is only deduplication, conversion and merging. It is not the author of any individual rule.

Two boundaries are drawn. The full edition will have many false positives, so use the Lite one. And the scope is limited to lists related to Chinese and English ad blocking, network security and privacy protection, with a code-formatted emphasis on each of those three categories. Nothing outside that scope is collected, which is worth knowing if you expected a broader security feed.

That combination, a large merge plus an explicit warning against the large merge, tells you the intended audience. This is for someone who wants breadth and accepts the noise, and the Lite edition exists for everyone else.

Seven upstreams, three of which are security feeds rather than ad lists

The source list explains the false positive problem better than the warning does, because the sources are not homogeneous.

Five are advertising filter projects: AdAway, AdGuard, EasyList, uBlock Origin's uAssets, and a list under the AdBlocker name hosted at adblockultimate.net. Merging those produces overlap, which dedup handles, and occasional disagreement, which dedup cannot resolve.

Two are security feeds. URLhaus from abuse.ch is a malware URL repository, and malware-filter on GitLab is a filter project. Pulling those into an ad blocker is a scope change rather than a formatting one, and it is the obvious place to look first for rules that block something a user needed. That is one plausible route to the false positives the warning describes, though the documentation does not attribute them to any particular source.

The compatibility claim covers Adblock Plus syntax, uBlock Origin syntax and AdGuard syntax, and any filter list using Adblock Plus syntax can be added as an upstream. The stated targets are AdGuard, Adblock Plus, uBlock Origin, Brave Browser and DNS servers generally.

Releases every 20 minutes, and the release tag is a timestamp

The publishing cadence is unusual and worth understanding before you subscribe.

A release is published automatically every 20 minutes, and the documentation says the local import route is to download the filter files from the Release rather than from the raw branch URLs. The reason to prefer releases is that they are versioned, and the reason the cadence is fast is that upstream lists change fast, and a subscription that lags a day behind a security feed is a subscription that is late.

The tag format makes this concrete. The most recent release is named release-2610010634, which reads as a compact date and time: year and month, day, then hours, minutes and seconds. The repository uses a rolling release name rather than semantic versioning, so there is no meaningful version to pin and no changelog to diff between two of your own snapshots.

Two consequences follow. First, if you need a stable pinned list for reproducibility, you have to keep your own copy, because the subscription URL will serve different content tomorrow. Second, a rule that starts breaking a site will break it again on the next refresh, so the recovery path is upstream rather than waiting for a fix here.

Two licences in the repository, and the NC clause decides your use

The repository carries two licence files, and which one governs you depends on what you intend to do with the output.

The files are LICENSE-CC-BY-NC-SA 4.0 and LICENSE-GPL 3.0, and both are linked from the README badge area and repeated in the licence section. The repository summary records no single licence identifier for the project as a whole, which is consistent with the two files being present rather than one superseding the other.

The non-commercial clause in CC-BY-NC-SA 4.0 is the operative one for most commercial readers. It permits sharing and adaptation provided the work is not used commercially, and it requires the same licence on derivatives. If your plan is to ship a product with these lists bundled, or to run them as the basis for a service, that clause is the thing to resolve, and resolving it means asking the author rather than assuming which file wins.

The GPL-3.0 alternative is the permissive-by-copyleft option and is the one to look at if your use is commercial, because GPL obligations attach to distributing the work rather than to using it internally. Neither file's precedence over the other is stated in the documentation I have.

The Python scripts are the DIY path, and you own the output path

If you would rather generate the lists yourself than subscribe to them, the repository ships two scripts and the documentation points you at them directly.

The names mirror the two editions: Adblock_Rule_Generator.py and Adblock_Rule_Generator_Lite.py. The instructions say you can use them to merge and dedupe into a generated list, and that you should modify the save path and the output filename. Adding further upstreams is the documented extension path, with the constraint that any list using Adblock Plus syntax is accepted.

That is a real difference from a subscription-only project, and it inverts the maintenance relationship. Subscribing means upstream changes reach you and you deal with the consequences. Generating means you choose the upstream set, you choose when to rebuild, and a bad rule stays bad until you change something. For anyone who needs a pinned list, a corporate baseline, or a specific set of sources, generating is the only workable option.

The primary language of the repository is Python, and no dependency list, no test suite and no version requirement for the interpreter are documented, so treat the scripts as readable source to adapt rather than as a packaged tool.

A subscription URL is a supply chain, and this one refreshes every 20 minutes

It is worth being clear about the trust model, because the design makes it unusual.

A user who installs this subscription is executing rules produced by seven external projects, re-serialised and re-published by a repository they did not audit, on a schedule of 20 minutes. The rules can block requests, and a filtering rule is a small piece of executable configuration in the browser. The chain from EasyList's git repository to a request being blocked on your machine is four hops long.

None of that makes the project wrong. Deduplicating and normalising widely used lists is real work, and the alternative for most users is maintaining their own subscription list by hand. But the honest framing is that this trades auditability for convenience, and the Lite edition is where the trade is most favourable because it narrows the source set to one project.

The two files to check before subscribing are the one you will actually load, and Whitelist.txt, which is the escape hatch. If a site breaks, the whitelist is where you fix it, which is a faster path than waiting for someone else's rule to be retracted.

Editorial conclusion

Take the Lite edition if you want a single subscription that tracks upstream without you maintaining a list, since it is the one the project itself recommends and it is small enough to debug. Leave the full edition unless you are willing to report false positives, because the documentation says plainly that it will break some sites. Verify first which licence you need, since the repository ships both CC-BY-NC-SA 4.0 and GPL-3.0 and the non-commercial clause is the one that decides whether you can ship it inside a product.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes