uAssets: the filter lists behind uBlock Origin and the rules for getting a filter in

Extended syntax is the admission rule, not a style preference

The repository description states the requirement in one line: any filter included in uBO's filter lists must use the extended syntax. That single condition does more work than it looks. A filter that only needs ordinary cosmetic blocking can live in EasyList, where it serves every blocker. A filter that needs uBO's own capabilities cannot, so it belongs here.

The reasoning behind inclusion is stated as the same as the EasyList and EasyPrivacy policies, with one addition: whether the filter requires uBO's extended filter syntax is also weighed. In practice that means the two criteria are combined. Broad appeal is not enough on its own, and uBO specific capability is not a licence to add something that would work for everyone.

This is a triage queue rather than a finished catalogue. The repository receives all reports for new filters and for existing filters that break web pages, and it is the place where filters are argued over before they end up in a shipped list. There are no tagged releases in the repository at all, so nothing here is versioned for download. What a user actually installs is the list inside uBlock Origin, refreshed from the filter text files kept under `filters/`.

The last push to master was on 2026-11-02, and the licence is GPL-3.0, the same licence the extension itself carries.

Seven breakage classes get fixed even when the filter needs no extended syntax

The strictness has one explicit escape hatch, and it is a named list rather than a judgement call. uAssets will fix the following exceptions even when they do not require the extended syntax:

Ad-Reinsertion, Anti-Blocker, Context Menu Blockage, Cut/Copy/Paste Blockage, Popups/Popunders, Website Breakage, and Video Ads.

Read together, these describe a filter that has already been accepted or that damages the page rather than merely failing to block something. A filter that breaks the right-click menu or stops copy and paste from working has taken functionality away from the user, so it gets fixed regardless of whether extended syntax is involved. Video ads and popups sit in the same group because a filter that lets a video ad through has produced a visible failure, not a theoretical one.

The distinction that matters for a contributor is between a filter that does not work and a filter that damages the site. The first is usually an EasyList question. The second is what this repository is set up to absorb.

Note what is absent from the exception list: cosmetic blocking, tracking coverage, and element hiding preferences. Those are the everyday arguments, and they belong to the upstream EasyList discussion rather than here.

Paywalls, porn farms, and annoyances are declined before anyone reads the filter

Five categories are refused outright, and the wording leaves no room for negotiation:

Paywalls, Porn Farms, Annoyances (widgets, social media buttons, newsletter subscriptions, donation requests, etc), Self-promotion elements, and requests for custom filters to modify or restyle site content, for which help is pointed to /r/uBlockOrigin.

This is the clearest statement of what the project will not do. Removing a paywall is not a blocking failure, so it falls outside the rationale for inclusion and outside the exception list above. Same for annoyance filtering: hiding a newsletter box or a donation banner is a preference about page layout, and the decision is that those requests are not handled here.

The same boundary applies to list level requests. New filter list requests in the issue tracker are not permitted, and they will be declined and closed. That rules out the common request of asking for a separate regional or category list to be added as its own file, since adding a list is a different act from fixing a filter in an existing one.

Two further categories of question are routed elsewhere rather than refused. Support, questions, and help go to the support forum at /r/uBlockOrigin. Problems with the extension itself go to the uBO issue tracker, and problems specific to the Manifest Version 3 variant go to the uBO Lite issue tracker. Filter content belongs here; everything around it has a different door.

EasyList stays the preferred home, so uBO filters act as a staging area

There is a stated preference that shapes how filters move: it is preferred to fix filter issues in EasyList. The project also commits to adding EasyList-compatible fixes for high-traffic websites to the uBO filter lists until they become added to EasyList.

That is a temporary arrangement with an expiry condition, and it is worth understanding before you spend effort on a filter. If a site is popular enough that its breakage affects many users, the fix can live in the uBO lists first so that people running the extension are not left waiting, and it is expected to move upstream afterwards. A fix that never reaches EasyList is not a permanent contribution.

The practical split is this. Extended syntax capability sends a filter to uAssets. Popularity plus breakage sends a fix to uAssets temporarily and to EasyList eventually. Neither extended syntax nor popularity sends ordinary cosmetic blocking here.

The reference point for what belongs upstream is the EasyList and EasyPrivacy policy page, linked from this repository, which is where the criteria for broad compatibility are actually written down. Reading it before filing saves the round trip that a declined issue costs.

The Makefile validates one yearly file at a time and never a merged list

The repository keeps its filter text in versioned files rather than one growing list, and the build system reflects that. The targets are declared per year, from 2020 through 2026, plus a handful of specialised ones:

validate-filters \
validate-filters-2020 \
validate-filters-2021 \
validate-filters-2022 \
validate-filters-2023 \
validate-filters-2024 \
validate-filters-2025 \
validate-filters-2026 \
validate-privacy \
validate-annoyances \
validate-badware \
validate-ubol-filters

Each target has its own rule with its own input file, for example `filters/filters.txt` for the current list and `filters/filters-2020.txt` for the 2020 one, and each writes a separate result file under `build/validate/results`. So a syntax problem introduced by a new filter does not hide behind an older one, and the yearly files stay independently checkable.

The validator itself is Node, run against a build directory assembled from `tools/validate`, and it depends on a `build/validate/uBlock` target produced by `tools/make-validate.sh`:

node build/validate/validate.js \
	in=filters/filters.txt \
	out=build/validate/results

The `validate-privacy`, `validate-annoyances`, and `validate-badware` targets separate the checks that must pass for the privacy, annoyance, and badware categories, and `validate-ubol-filters` exists so the Manifest Version 3 variant is checked with its own rules. The presence of a separate annoyances target alongside a refusal to take annoyance requests is a real tension in the project, and the README does not explain it.

Troubleshooting information is required, and the two variants collect it differently

The reporting procedure is specific, and the first step is not about the filter at all. Disable all other browser extensions and see whether the issue still occurs. Only if it persists does the report proceed, and then troubleshooting information is required.

The two variants export that information by different routes. For uBlock Origin the sequence is: open a new tab, go to the page where the problem occurs, click the uBO icon, click the chat icon, click Troubleshooting Information, click Select all and copy the contents, then paste into the appropriate thread. For uBlock Origin Lite the route differs at the third step, where you click the uBOL icon and use the Report an issue menu item instead of the chat icon, then click Troubleshooting Information and copy without the Select all step.

That difference is small enough to miss and matters in practice, because a Lite user pasting a full uBO export into the wrong tracker produces a report that cannot be matched to the running variant.

Two constraints on the report are stated plainly. First, pasting into the appropriate GitHub thread means choosing between the two issue trackers based on which variant you are running. Second, the request to disable everything else is not optional politeness; it is what makes the report actionable, and a report that skips it cannot be verified.

Running a second blocker alongside uBO makes the diagnosis worthless

The repository carries an unusually direct warning about concurrent tools. Do not use any other similarly-purposed blockers concurrently with uBO, because it can result in website breakage or undefined results.

That instruction explains the first step of the reporting procedure. If a second blocker is active, a failure could belong to either one, and the troubleshooting export only describes uBO's own state. The two configurations fight over the same requests, so a report filed from that setup describes a machine rather than a defect.

The repository also says contributors who are proven valuable will get write permissions. Access follows from having demonstrated that you can produce filters that survive contact with real sites.

The layout follows the same split between content and tooling. `filters/` holds the list text, `tools/` holds the validator that the Makefile drives, and `dnr/`, `templates/` and `thirdparties/` sit beside them.

Editorial conclusion

uAssets is worth watching only if you intend to contribute filters or breakage reports, not to install anything: there are no releases, and the lists ship inside uBlock Origin itself. Contributors who fix real breakage on popular sites have a clear path in, and everyone else is pushed toward EasyList or the support forum. Before you open an issue, confirm the problem survives with every other extension disabled, export the troubleshooting information from the exact variant you are running, and check the filter is not a paywall, a porn farm, an annoyance widget, a self-promotion element or a restyling request, because the project will not address those.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases