Filter List Subscriptions

Chroma includes bundled filters and remote filter subscriptions. Enabled remote lists refresh on their configured schedule and are stored locally. Master protection and your feature settings determine which rules are active.

Bundled And Default Sources

Chroma does not use a hidden remote hotfix list. Project fixes arrive through visible Chroma updates, and every additional remote list is one you explicitly choose to add.

The Chroma Scriptlet Library includes targeted anti-adblock rules for Dailymotion and MLive. Dailymotion's ad-loaded flag and detection timer are handled in matching pages and embedded players; MLive rules target Sourcepoint detector reads and Admiral loader/recovery paths. These rules require Allow User Scripts, master protection, and the enabled Chroma Scriptlet Library. Reload affected tabs after updating. Bundled rules refresh from the installed package on extension updates or reloads, while disabled lists remain disabled.

Dailymotion also skips generic cosmetic selectors and heuristic ad-container removal because those can hide the site's detection probes. Domain-specific cosmetic rules and saved Zapper selectors still apply. These mitigations cover known detector patterns; changes to a site's player or detector can require another compatibility update.

Chrome guarantees at least 30,000 static DNR rules per extension, while additional static capacity comes from a browser-wide pool shared by installed extensions. Chroma's multi-part OISD packaging does not bypass that platform quota, so other rule-heavy extensions can reduce the extra static capacity available beyond Chrome's guaranteed minimum.

Custom Filter List Subscriptions

Chroma supports user-added filter list subscriptions. You can host your own list in a GitHub repository, GitHub Gist, or any HTTPS endpoint that serves raw filter-list text, then paste the raw https:// URL into Chroma's subscription manager.

Custom subscriptions can include supported Adblock/uBO-style network rules, cosmetic rules, cosmetic exceptions, and scriptlet rules. During refresh, Chroma parses the list into network, cosmetic, and scriptlet buckets, drops unsupported or malformed rules, deduplicates network rules already covered by the bundled static ruleset, and only keeps scriptlets that map to Chroma's shipped scriptlet library.

Network rules are compiled to Chrome Declarative Net Request rules on a best-effort basis. Safe wildcard-host patterns such as ||cdn.*.example/path are preserved as native DNR urlFilter values instead of being expanded into regular expressions. The native * keeps Chromium's any-URL-character wildcard semantics; it is not narrowed to DNS-label characters. URL filters that cannot be represented safely, including non-ASCII filter text that Chromium requires to be URL-encoded, are skipped so the rest of the custom list can still load.

Settings shows rules that could not be applied because of unsupported syntax, browser incompatibility, or rule limits. A list can still provide protection when some of its rules are skipped.

Manage Filter Lists

1. Open Settings -> Filter lists and click Add filter list.
2. Paste the raw HTTPS text URL into Filter list URL. Add an optional name, then click Add. A repository file-view page is not a raw list URL.
3. Wait for the first refresh and review the list's rule counts or error message. Network counts show applied rules out of parsed rules; not every parsed rule fits the browser's syntax and budget.
4. Use the list's switch to pause or resume it, or Refresh to fetch it immediately. Reload affected pages when checking cosmetic or scriptlet changes.
5. To delete a custom list, click Remove. Bundled/default lists have an enable switch but no Remove button. If removal is pending, click Retry after reviewing the error and Health status.

New custom lists use a 24-hour refresh interval. Settings provides manual Refresh; it has no interval selector. Disabling a list preserves it for later use. Removing a custom list deletes its saved subscription after cleanup succeeds. A pending disable or removal can leave the previous network rules active until Chromium accepts the update; the row reports that state.

Parser Trust Boundary

Network options are accepted only when Chroma can preserve their meaning in DNR. Supported constraints include recognized resource types, $important, first/third-party forms and their supported negations, and validated $domain= inclusions and exclusions.

Constraint-bearing options that Chroma cannot represent safely, including $method, $match-case, $header, and similar modifiers, cause the complete block or exception rule to be dropped. Chroma never removes an unsupported constraint and then installs a broader rule. Malformed lines are counted and dropped individually so one bad line does not reject valid siblings.

Cosmetic and scriptlet domain inclusions and exclusions are stored separately. An exclusion-only rule such as ~example.com##.ad is treated as global except on the excluded domain rather than being discarded or applied only to that domain.

Browser Compatibility

Chroma checks rules against the browser's supported syntax and limits. If the browser rejects a network-rule update, the previously applied rules remain active. Review Health for a DNR synchronization error and the list's status for skipped rules.

Advanced User Scriptlet Resources

Executable resources added through Settings -> Scriptlets are a separate feature from filter lists. For their setup, examples, and trust boundary, see Advanced User Scriptlets. Normal subscriptions can only call Chroma's shipped implementations, as explained under Remote List Trust Boundary.

Why Custom Lists Still Work In MV3

Manifest V3 does not allow extensions to intercept and decide every request in JavaScript the way MV2 blockers often did. Chroma's subscription design works around that by doing the expensive work at refresh time instead of request time.

It fetches and parses the list locally, converts supported network rules into DNR dynamic rules, and lets Chrome's browser engine enforce those rules without waking the extension for every request.

Rules that do not belong in DNR are handled by the layers that fit them:

• Cosmetic selectors go to the cosmetic filtering layer.
• Supported scriptlets go to the userScripts engine.
• Unsupported syntax is dropped instead of being guessed at.

This is why custom lists can still be useful in MV3 while staying inside Chrome's rule budgets and execution model.

Rule Allocation

Enabled third-party and custom subscriptions share the browser's remaining dynamic-rule capacity. Chroma reads Chrome's dynamic-rule limit (currently 30,000), reserves the exact number of local/default, Tracking URL Cleanup, Spotify, and site-whitelist rules, then allocates the remaining slots to subscriptions. Each whitelisted site uses two rules. This replaces the former fixed 25,000 subscription cap; changing settings or the whitelist recalculates the allocation automatically, including when restoring cached subscriptions.

With the shipped defaults, Tracking URL Cleanup enabled, Spotify protection enabled, and no whitelisted sites, Chroma uses 38 dynamic rules, leaving 29,962 subscription slots. Stored custom local rules can change that count. Regex rules also share Chrome's separate 1,000-rule dynamic regex limit, with Chroma's own regex rules reserved first. Cosmetic rules and scriptlets do not consume these DNR slots.

Network rules are allocated by Chroma's internal priority score before being applied to DNR:

• Exception/allow rules are preserved first.
• $important block rules receive a higher score.
• Domain/resource-type-specific rules are favored next.
• Earlier list position acts as a final tiebreaker.

This lets custom lists express urgency while still respecting Manifest V3 dynamic-rule budgets.

Protection Lifecycle And Cached Restoration

• Turning master protection off pauses subscription protection and keeps saved lists and rules.
• Turning only Network blocking off pauses subscription network rules. Cosmetic filtering and scriptlets keep their own settings; Spotify protection has a separate toggle.
• Lists can refresh while protection is paused without turning protection back on.
• Re-enabling protection restores cached rules without requiring a new download.
• A pending status means a requested list change has not yet been applied successfully.

If a list refresh fails, Chroma keeps its previously cached rules and retries on the normal schedule. You can also refresh the list manually from Settings -> Filter lists.

Remote URL Network Boundary

Custom remote URLs must use HTTPS on the default port and cannot contain credentials. Chroma rejects URLs that literally name localhost or private/special-use IPv4 or IPv6 addresses, and it revalidates the final response URL before accepting response metadata or body content.

DNS resolution and redirect transport are performed by Chromium. Chroma cannot inspect or pin the connection's peer IP, so a public-looking hostname could resolve or rebind to a private address, and Chromium may contact an automatically followed redirect before Chroma rejects its final URL. Add only remote sources you trust.

Example Custom List

! Higher-priority network block. `$important` receives a stronger Chroma allocation score.
||example-ad-server.com^$script,third-party,important

! Hide sponsored cards, preserving cards with the keep-visible class.
example.com##.sponsored-card:not(.keep-visible)

! Hide newsletter overlays generally, but cancel this exact selector on example.com.
##.newsletter-overlay
example.com#@#.newsletter-overlay

! Scriptlet rule: run a supported Chroma/uBO-style scriptlet on a site.
example.com##+js(set-constant, adsEnabled, false)

Cosmetic exceptions cancel a hiding rule with the same selector text on matching domains. They do not unhide a subset of an element matched by a different selector. Use a selector such as :not(.keep-visible) to exclude a subset from a hide rule.

Remote List Trust Boundary

Remote list content is not treated as arbitrary code. Lists are fetched over HTTPS, parsed locally, bounded by response-size and rule-budget limits, deduplicated against bundled static rules where applicable, and unsupported syntax is dropped. Scriptlet rules can only call implementations already shipped in Chroma's bundled scriptlet library.

Advanced user scriptlet resources are the explicit exception to this model. They are not installed by Chroma, not bundled with Chroma, and not activated through filter-list subscriptions. They run only after the user adds a resource URL and matching user scriptlet rules in settings.

Because enabled remote lists can still change blocking, allow rules, cosmetic behavior, or supported scriptlet behavior after installation, users who need a stricter trust model should review and disable subscriptions they do not want to trust from Chroma settings. Additional custom subscriptions are always user-selected.

Third-Party Credits

Chroma uses or derives logic and patterns from the following open-source projects and filter-list sources:

• Brave Browser: The YouTube ad-stripping logic, including payload metadata pruning patterns, is derived from Brave's ad-blocking scriptlets under the MPL 2.0.
• HaGeZi Pro Mini by HaGeZi: GNU General Public License version 3.
• OISD Small, Big, and NSFW by OISD: GNU General Public License version 3. Small and Big are selected first. When they do not fill the packaged static budget, Chroma selects adult and shock-site domains from across OISD NSFW until the complete corpus reaches 300,000 rules.
• EasyList by the EasyList authors: the EasyList repository is dual-licensed under GPLv3-or-later or CC BY-SA 3.0-or-later, unless otherwise noted.
• Fanboy's Annoyance List by the EasyList/Fanboy maintainers: the configured list declares the Creative Commons Attribution 3.0 license in its source header.