adfilt: adblock lists that will never support Manifest v3

The Manifest v3 refusal is permanent, and it is structural

The first thing the README says, before anything about lists, is a refusal, and it is phrased as an absolute.

The lists do not, can not, and will never ever support Manifest v3, due to the lack of list hotfixes and its various syntax limitations. Issue reports for Manifest v3-based extension versions will not be accepted, and if you do submit one, the author says you would be asked to use an alternate web browser instead. On Windows, running winget search mv2 and/or winget search gecko in PowerShell shows a more-or-less up-to-date list of supported alternate browsers.

The two reasons are worth understanding rather than treating as opinion, because they are properties of the platform rather than preferences.

The first is list hotfixes. Under Manifest v3, an extension's filter lists are declarative rules rather than code, which is the point of the design: it removes the ability to run downloaded JavaScript. The consequence for filter list maintainers is that a list cannot be updated with new logic or new filter types on the fly, because the extension is not permitted to execute a list that does more than match patterns. A maintainer who needs to change how a rule is interpreted has to ship a new extension version. That is a different release rhythm from the one a filter list operates on, where a false positive discovered this morning is fixed this morning.

The second is syntax. Manifest v3's declarativeNetRequest implementation supports a subset of the filter syntax that Adblock Plus and uBlock Origin have accumulated over fifteen years, and the subset is not complete. Entries in these lists use cosmetic filters, procedural selectors and syntax that a Manifest v3 extension cannot express.

So the refusal follows from the two facts, and the winget suggestion is a real answer rather than a brush-off. Browsers that still support Manifest v2 exist and can be found by package name on Windows, and the author points at that as the path for someone whose browser has removed Manifest v2 support.

The scope of the refusal is worth noting. It applies to issue reports about Manifest v3 extension versions, not to every report. A report about a broken entry in a Manifest v2 extension is in scope. The author's position is that Manifest v3 cannot consume these lists, so a Manifest v3 bug is not a bug in these lists.

There is also an AntiMV3List.txt file in the repository root, which is presumably a filter list for blocking Manifest v3-related telemetry or prompts, and its presence is a small joke at the repository's own expense. The topics list confirms the framing: ad-blocker, adblock, adblock-plus, adblocking, adguard, brave-browser, filterlist, firefox, hosts, hosts-file, hostsfile, json, manifest-v2, manifestv2, mv2, opera, ublock-origin, vivaldi.

Safari is dropped too, for the same reason Chromium was

The Manifest v3 section is not the only platform exclusion, and the second one is more recent and more disruptive for a lot of people.

The author states that support is no longer offered to Safari 13 and later, except when using AdGuard's paid version, and gives the reason directly: Safari decided to do the exact same things that Chromium ended up doing.

That is a single sentence and it compresses a long argument. Safari's content blocker extensions moved to the Manifest 3 model, with the same consequence: no remotely-updatable filter lists and a restricted rule syntax. So a list that cannot work under Manifest v3 cannot work in a current Safari either, and AdGuard's paid product is carved out because it is not a browser extension in the same sense, it is a network-level blocker that does not depend on the extension model.

The combined effect is that the lists have narrowed their target over time, and the narrowing has removed both of the two most widely deployed browser engines. A user on Chrome, Edge, Opera, Brave or Vivaldi's Chromium builds has no Manifest 2 extension any more. A user on Safari 13 or later has the same problem. So the population that can actually use these lists today is: Firefox and its forks, the Manifest 2 Chromium forks, and users of network-level blockers such as AdGuard Home, pfBlockerNG and hosts files.

That is a real and shrinking audience, and the author is explicit about it rather than quietly narrowing support. That matters for an evaluator, because a project that has decided its platform is a shrinking platform has made a different bet from one that is simply behind.

The exception list is instructive too, and it names the products the lists actually reach: uBlock Origin, AdGuard, AdNauseam, AdBlock, Adblock Plus, AdGuard Home, pfBlockerNG, Brave Browser, Zen Desktop, and Vivaldi's privacy settings. The signature list, Dandelion Sprout's Nordic Filters in NorwegianList.txt, is described as being for all up-to-date adblockers, with a userbase very loosely estimated in the low seven digits, and various modified versions of it are included in those products.

Two things follow from the modified-versions wording, and they point in opposite directions. The positive reading is reach: a list maintained by one person in their spare time is a component of a large share of the blocking software in circulation. The cautious reading is that a modified version has diverged, and the divergence is invisible to subscribers, who cannot tell which fixes from master are in their copy and which are not. The author is upfront that the versions are modified, which is more than most projects would say.

Three Gecko forks dropped over community conduct, with entries delegated elsewhere

There is a third platform exclusion in this README, and it is the strangest thing in the file, so it is worth quoting the reasoning and then describing the technical consequence.

The note for UXP browser users says that, due to the Pale Moon community being protective of consistent abusive hate speech and grave insults, the author will no longer use Pale Moon, Basilisk or Borealis to test any entries or for anything else. UXP browser entries that cannot be reproduced in Firefox, Vivaldi or Tor Browser will be delegated to uAssets, which is uBlock Origin's own repository of user-submitted filters.

The stated reason is about the conduct of a user community rather than about the software. That is a value judgement the author is entitled to make about who they will and will not work with, and it is stated once, plainly, in the project's own documentation, which is a better way to make it than to quietly stop testing. What follows is the part with engineering content.

The workflow this repository uses, as the tool list makes clear, is empirical: you add an entry because you saw something on a site, you check that it does not break anything, and you check that it still works in the browsers your users have. Testing in a browser is how you discover that a rule hides a control you needed, or that a hosts entry breaks a site whose certificate you cannot see. Remove the browsers from the test matrix and you remove a class of false-positive detection.

The mitigation is the delegation clause. An entry for a UXP user that the author cannot reproduce in Firefox, Vivaldi or Tor Browser goes to uAssets instead, so the request is not lost, it is handled by a project that still tests on UXP. That is a reasonable division: this repository handles what it can verify, and the project that shares the platform handles the rest.

The three affected browsers are all Gecko forks in the same family, so the practical loss is one rendering engine rather than three, and Firefox covers the same engine. So the technical cost is small. The governance signal is larger: a maintainer of a list bundled in nine products has decided that some of his users' reports will be handled by someone else, and has written down how.

The tools section adds one more platform in the same list, and it is the honest one. To look for invalidly written entries according to uBlock Origin's syntax, the instruction is to use uBlock Origin, set the logger to All, and resync the lists. So the reference implementation for correctness is uBlock Origin's own parser, running in uBlock Origin, which is the same parser that will consume the list in most installations.

The email policy names a headcount, two countries and a date

The contact section contains the most specific access policy I have read in a project README, and it is worth reproducing because its specificity is the point.

The author advises against sending reports on email. From 16 April 2025, email reports will only be processed if a person is not actively using GitHub or GitLab in general once every 2 weeks or more often, and/or if the person is an official representative of a Nordic or German company with 20 or more employees. Clear failure to adhere to this will have the emails marked as spam.

Three conditions, and the first two are joined by and/or so either is sufficient. Do not use GitHub or GitLab more than once a fortnight, or represent a Nordic or German company with at least twenty employees.

The intent is legible. A filter list maintainer wants reports from users who cannot use a forge, and wants them from organisations that have a stake in blocking working. The enforcement is a spam folder, which is the one lever a person with a hosted email address actually has.

It is also a policy that will misfire. The Nordic and German company condition is presumably a nod to the list's name and its origin, and it excludes an individual in, say, the Netherlands or Japan who does not use GitHub, who is precisely the person the first condition is meant to catch. The GitHub frequency condition is measurable in principle and has no defined threshold: once every two weeks or more often is the boundary, and nobody measures it. And a spam filter does not know about the policy, so a compliant sender is filtered on exactly the same grounds as a spammer.

The rest of the contact section is more conventional and better calibrated. Issues and pull requests are both allowed, with a request to add screenshots and the lists that were used when testing, which is the right evidence to ask for. Reports will usually be looked into within 72 hours, and the qualifier is important: major delays can happen if the author has health problems at the time.

That single clause is the real bus factor statement in this repository. One named person, a hobby project they work on as much as they feel like, a stated possibility of health-related absence, and lists that ship inside nine products. The 72-hour figure and the health caveat together are more informative than any governance document, because they say both what you can expect and what can change.

Reports on the GitLab mirror are allowed but the author notes they have not yet tested how quickly they would notice them, which is an honest admission that the mirror is a second-class channel.

Releases named after commit counts, the last from January 2022

The release history in this repository is not a version history, and understanding why changes how you should consume it.

The three most recent releases are 2.0, 2,000th commit celebration, on 2019-06-11; 3.0, 5,000th commit celebration, on 2020-07-14; and 4.0, 10,000th commit celebration, on 2022-01-08. The last push was on 2026-09-27.

So the releases are named after cumulative commit counts and marked as celebrations. There is no 5.0 for the twenty-thousandth commit, so either the practice stopped or the count milestone was not reached. Either way, the last release is from January 2022 and the branch has four years and eight months of commits past it.

For a filter list this is arguably the right design, and it is worth saying why before treating it as a gap. Nobody installs a filter list from a release. Nobody pins a list version, because a list is a text file that a blocker re-fetches on a schedule, and a pinned list is a list that goes stale and stops blocking. The subscription mechanism is a URL, and what the user consumes is whatever is at that URL at fetch time. There is a commit feed link in the README for exactly this reason, alongside the repository-size badge and the logo.

So the absence of releases is not a packaging failure. It is a repository where the branch is the release. The relevant history is the commit log and the feed, not the tags.

What that means for an evaluator is that there is no stable snapshot to cite, compare or roll back to. If you want to know whether a specific entry is in a specific version of the list, you need a commit hash, not a tag. And if you are running these lists in production, you are consuming a moving target by design, which is correct for blocking and incorrect for reproducibility.

Two more structural details sit alongside. There is a .gitlab directory and an official mirror on GitLab at gitlab.com/DandelionSprout/adfilt, so there are two forges carrying the same content. And the licence is a custom one that GitHub could not classify, which is unusual for a filter list; most such projects use a Creative Commons or public-domain dedication, and a bespoke licence on a list that nine products bundle is a document worth reading before you rely on it commercially.

The repository-size badge at the top of the README is a hint at scale. A repository whose size matters enough to badge is one with a very large volume of text, and with several hundred separate list files plus directories for variants, conversions and templates, the volume is the other structural fact about this project.

The maintenance procedure is a Sublime Text workflow, regex included

The tools and workflow section is the most practically useful part of this repository, and it is a worked example of doing meticulous text work with an editor rather than with code.

The author names Sublime Text, credits Jon Skinner and Will Bond, and then gives six specific recipes for it.

To sort filter entries in alphabetic order: F9, or Edit then Sort Lines. To remove the www. prefix from most entries: Ctrl+H for Find and Replace. To remove duplicates within a file: Edit then Permute Lines then Unique. To remove duplicates across files: paste the content of the file that should retain its filters on top, and the content of the file that should have its duplicates deleted underneath. To remove element-rule targets from adblock files so that the rules' domains can be run through a DNS availability checker: Ctrl+H, turn on regex, and replace ##.* and #?#.* with nothing.

That last one is the interesting technique and it deserves explaining, because it is a real conversion between two filter categories. In Adblock Plus and uBlock Origin syntax, ##.foo and #?#.foo are cosmetic filter selectors: they say hide this element on this page, and they act entirely in the browser with no network effect. Stripping them with the two regexes leaves a bare domain rule, which is a network-level rule. And a network rule is something you can feed to a domain availability checker, which tells you whether the domain still resolves.

So the workflow is: take a list full of cosmetic filters, strip the selectors to recover the underlying domains, bulk-check which of those domains still exist, and then delete the entries pointing at domains that are dead. A list of a few hundred thousand entries contains domains that have been parked, expired or repurposed over fifteen years, and an entry pointing at a repurposed domain is a false positive waiting to happen. The regex is how you make that checkable at scale.

The rest of the tool list is unusually honest about each tool's limits, which is rarer than the tool list itself. The redundant filter entry and ABP syntax checker by Famlam does not account for uBlock Origin-syntax-specific entries, nor for ABP syntaxes newer than 2017. The recentmost tool used to test IP server availability is PyFunceble by Funilrys. To find very similar domains for hosts files, or all domains on a given IP for both IPv4 and IPv6, it is BGP Hurricane Electric for initial lookups then SecurityTrails for deeper lookups, but SecurityTrails has big glitches with IP lists nowadays. To find lists of the biggest news sites of most countries, DomainTyper. To search with wildcards such as ads.*.no, the SecurityTrails API free tier.

And two tools exist specifically because Sublime Text cannot do the job. Sublime Text cannot correctly sort IP addresses, so there is a Browserling IP sort for that, and a Tehnoblog IP address aggregator for sorting and compressing into CIDRs.

That is a complete maintenance procedure, documented at the level of keystrokes, by a person who clearly noticed each thing Sublime Text could not do and found the smallest tool that could.

Lists that fix bold text, and a filename that is not what it looks like

Two things in the file listing are worth an evaluator's attention, one of them a genuine defect.

The first is what the lists are actually for. The description says web filter lists for countless topics including the Nordic adblock list, and the filenames make good on that in a way a reader might not expect. Alongside the obvious ad blocking there is EmptyPaddingRemover.txt, ForceBoldTextOnline.txt, AntiFakeTransparentImagesList.txt, DeviantARTQualityArtMagnifier.txt, DailyMotionSimplicity.txt, AntiSnowMarketingList.txt, AntiFakeTransparentImagesList.txt and AntiAbusePorn.txt.

ForceBoldTextOnline is a list that makes websites render bold text. EmptyPaddingRemover removes padding. DeviantARTQualityArtMagnifier probably enlarges images on a specific site. AntiSnowMarketingList targets Christmas advertising, and there is a companion Anti-'Christmas carols' List. AntiGachaAndKnockoffGamesList, AntiKpopSpammersTwitter, AntiAmazonListForTwitch, AntiPinterestInSearchResultsList, Anti-'Custom cursors' List, Anti-'Battle Royale' List, AntiThomasTheTankEngineList, AntiPepeList, AntiElsagateList, AntiCorruptSportsList.

This is a personal web-fixing repository that happens to be best known for its ad blocking, and the presence of hundreds of these files is the honest scope. Anyone subscribing expecting only an adblock list is getting a substantial amount of opinionated web customisation as well, which is a legitimate thing to want and is worth knowing before you import a list wholesale.

Two entries deserve separate mention because they are not cosmetic. GDPR 451 List.txt targets Article 45(1) of the GDPR, the right to object to direct marketing, which is a privacy filter rather than a tidiness filter. And BrowseWebsitesWithoutLoggingIn.txt handles the pattern where a site forces a login to show content, which is a genuine annoyance class and a hard one to filter well.

The second is a filename with a homoglyph. Among the entries is AntіРRСLіst.txt, and the internal characters are not all Latin: the first i is a Cyrillic і, and at least two other characters in the name are Cyrillic lookalikes. In a proportional font, and in most monospace fonts, those characters render identically to the Latin letters they imitate. So the filename reads as AntiPRPCList and is not.

The practical consequence is that anyone copying that path by reading it rather than copying it from a link requests a file that does not exist. And the repository has several hundred such filenames, a mix of scripts including Norwegian, Danish, Turkish, Icelandic and Cyrillic, and guillemets used as quotation marks. A mixed-script repository of hand-curated filenames is exactly where homoglyphs accumulate, and this one has at least one.

It is also a small reminder of the supply-chain point from earlier. A list whose filename is ambiguous, whose licence is a custom one GitHub could not classify, and whose author has stated a health-related availability constraint is bundled, in modified form, inside software that a great many people install by default. None of that makes it wrong. It does mean the trust is personal, and the README is unusually explicit about the terms on which that personal trust is extended.

Editorial conclusion

Subscribe to adfilt's lists if you run a Manifest v2 extension such as uBlock Origin or an AdGuard product, or if you consume hosts files, and read the Manifest v3 note first, because the author states the lists will never support it and the reason is structural rather than a matter of preference. Do not plan a Chromium-only deployment on these lists, since Manifest v3 is the only extension model Chrome and Edge now support and the maintainer points affected users at alternative browsers instead. Do not treat the bundled copies in Brave, Vivaldi, AdGuard Home and the others as equivalent to the master branch, because the README describes them as modified versions and a fork of a list diverges from its source whether the divergence is a bug fix or a policy change. Verify four things. Fetch the list over HTTPS from a mirror rather than trusting a CDN copy, since the README itself points at a GitCDN userscript because connection problems are common. Read ListOfLists.md in the wiki and copy the exact link, because the repository has several hundred files and the intended subscription path is a per-list URL. Check the manifest version your blocker actually is before importing anything. And subscribe to the commit feed rather than watching for releases, because the release tags are commit-count celebrations and the last one is from January 2022 while the repository is still being updated. The deciding fact is that this is one person's unpaid work with a stated health-related availability constraint, whose lists nevertheless sit inside a large share of the blocking software people install, which makes its maintenance policy rather than its filter syntax the thing worth understanding.

Frequently asked questions

Official sources

1. DandelionSprout/adfilt on GitHub
2. Issues
3. README
4. Releases