A proposal for the Gosub browser's extension system reframes permissions as explicit, composable capabilities instead of Chrome's flat permission list, aiming to keep Manifest V3's security gains without sacrificing powerful extensions like ad blockers. Rather than granting broad API access, Gosub translates manifests into scoped capabilities (e.g., filtering, content_script, network.egress), calculates what combinations of permissions actually enable, and surfaces that in install dialogs with warning tiers. A native filter engine called baleen runs ad-block list syntax directly in the browser (not extension code), reportedly matching 719,000 rules in about 7 µs per request, faster than Brave's engine. The work is a design prototype with a Rust translator tested against real Chrome Web Store manifests, but no actual browser implementation yet.
Table of contents
Capabilities, not permissionsWhen permissions combineLoudness as an incentiveBut what about ad blockers?Where we are nowQuestions this post answers
How fast is Gosub's baleen filter engine compared to Brave's ad-blocking engine?
A stack of 27 filter lists with 719,000 rules matches in about 7 microseconds per request, and running just EasyList plus EasyPrivacy takes about 1.6 microseconds per request. This is roughly twice as fast as Brave's filtering engine on the same request corpus, and it runs natively in the browser rather than inside extension code. Developers evaluating ad-blocker performance can follow browser engine benchmarks like this on daily.dev.
Why did Manifest V3 make ad blockers worse in Chrome?
Manifest V3 replaced code that ran in every page's request path with a capped, less expressive declarative rule format, since running extension code on every request was considered bad for both security and performance. This capped format is far less flexible than what full extension code could previously do, which weakened the most sophisticated ad blockers even though the underlying security goal was reasonable. Extension developers navigating Manifest V3 tradeoffs can track browser platform shifts like this on daily.dev.
What percentage of uBlock Origin's filter list rules can be handled without running custom extension code?
Roughly 99.2% of uBlock Origin's cosmetic-family filter rules can be handled natively without loud content-script permissions: 55% are scriptlets, 33% are plain cosmetic rules, and 11% are procedural rules, all supported by a native filter engine. Only about 0.8% of rules would still require the more invasive content-script route. Anyone comparing native filtering approaches to script-heavy ad blockers can track this analysis on daily.dev.