Support path-level matching for cosmetic filters

[seia-soto]

Motivation

With more companies hosting multiple services under a single domain, path-level matching for cosmetic filters is increasingly important. Cosmetic filters that target only domain names can lead to breakages and performance issues, especially when different services (like Amazon product pages and Prime Video) live on the same base domain. Additionally, ad-blockers can interfere with server-side features such as captchas—especially on platforms using Cloudflare’s “under attack mode”—by applying unnecessary cosmetic rules globally. Using path-specific cosmetic filters or exceptions helps minimize these issues by restricting filter injection to relevant pages and contexts.

• Multi-service Domains: Large sites such as Amazon host varied services (e.g. shopping, streaming) under a single domain (amazon.com). Cosmetic rules that are too broad may break features on unrelated sections.
• Captcha Compatibility: Challenges and browser authentication flows (like Cloudflare’s anti-bot pages) often need adblockers to avoid altering critical UI on these specialized paths.
• Reduced Breakages: Path-specific filters and exceptions help target only the necessary areas, avoiding site-wide cosmetic injections and reducing the risk of unintended breakage.

Syntax Proposal

Ghostery and AdGuard parsers already expect # as the cosmetic filter marker. Since regular expressions aren’t natively supported for cosmetic filters, extending hostnames with URI paths—always beginning with /—is a practical and standards-compliant solution. This format clearly indicates both the domain and the matching path, making parser implementation straightforward.

Use cases

Use Case	Filter Syntax	Description
Add a scriptlet only to /gp/video	amazon.com/gp/video##+js(...)	Inject scriptlet only on Prime Video page
Exclude scriptlet from /gp/video	amazon.com/gp/video#@#+js(...)	Prevent scriptlet from being injected there
Apply filter just to Cloudflare challenge	site.com/cdn-cgi/challenge##.overlay	Hide overlays only on challenge page
Exception for login page	service.org/login#@#.popup	Disable pop-up filter only on login path

[seia-soto]

• Specify the behaviour with commas for multiple hostnames

[chrmod]

Few questions to clarify:

• should we support network-filter-like syntax for url matching
• should this apply to regular css cosmetic filters
• how does it relate to :matches-path eCSS
• should we limit this to Scriptlets filters only?