Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
Significance of the 45 MiB Savings
- Debate over whether 45 MiB is meaningful: some see it as negligible on 8–16 GB systems; others argue savings compound across many apps, tabs, and profiles.
- Several comments stress that adblock data is hit on every request, so memory saved here improves CPU cache behavior and performance, not just raw RAM use.
- A broader theme: today’s “RAM is cheap” attitude is blamed for bloat; others counter that rewriting everything for efficiency is expensive and unrealistic, but incremental optimizations like this are exactly what’s needed.
Technical Changes: Rust, FlatBuffers, CSS Engines
- The adblocker was already in Rust; the big gain came from switching internal structures to FlatBuffers and array indices instead of pointer-heavy trees.
- This substantially reduced per-filter overhead, especially with large blocklists.
- Brave uses Rust crates from Servo (also used by Firefox) for CSS parsing/selector matching and even runs a separate CSS selector engine for blocking versus rendering, partly because filter syntax extends CSS selectors.
Dependencies, Supply Chain, and Rust Ecosystem
- Some praise Rust’s crate ecosystem and reuse; others worry about npm-like supply-chain risks.
- Discussion covers:
- Practical impossibility of fully auditing huge dependency graphs.
- Use of lockfiles, vendoring (
cargo vendor), reproducible builds, security advisories, and delayed updates as mitigations. - Trade-offs between vendored/forked code (more control, more maintenance) vs. package-managed dependencies.
Static vs Dynamic Linking and Runtime Sharing
- Long subthread on Rust’s tendency toward static linking and the decline of shared-library RAM savings.
- Rust supports dynamic libraries (via unstable Rust ABI
dyliband stable C ABIcdylib), but cross-version Rust ABI is fragile, so most real sharing is within a project or via C ABIs. - Some see static linking + lockfiles as safer and simpler; others miss stable ABIs for plugin systems and finer-grained rebuilds.
Brave’s Adblocking Quality and Behavior
- Many report Brave’s built-in adblocker as extremely effective, often negating the need for extensions.
- Clarifications that Brave blocks third-party ads/trackers by default; its own ad system is opt-in and pays small crypto rewards.
- Some mention EasyList’s power to pressure anti-adblock measures by threatening to block all JS.
Trust, Ethics, and History
- Strong disagreement over Brave’s trustworthiness:
- Critics cite past behavior: silent affiliate-link insertion, bundling a VPN service by default on Windows, Tor-mode leaks, and whitelisting of some trackers.
- Defenders argue those incidents were corrected, compare them to practices by other vendors, and emphasize Brave’s strong default privacy protections.
- Several commenters say no memory or performance win will restore their trust; others continue to use Brave because it “does the right thing by default” more than alternatives.
Alternatives, Forks, and “De-Bloated” Builds
- Some want a community fork stripping rewards, crypto, AI, telemetry, and proprietary services to fit strict distro policies.
- Brave Origin is mentioned as an upcoming stripped-down build: free on Linux, paid elsewhere, raising questions about how “open” that model is.
- Users note Brave makes UI toggles for BAT/AI easy, but others argue that’s not enough for inclusion in free/libre repositories.
Comparisons with Firefox and Other Browsers
- Firefox is preferred by some for extensions (especially on Android) and perceived governance, though its default tracking protections are seen as weaker than Brave’s adblocking.
- Questions about why Firefox doesn’t ship a similarly aggressive native adblocker; suggested reasons include mainstream-compatibility concerns and dependence on Google search revenue.
- Feature comparisons: vertical tabs, split view, tab grouping, and third-party Firefox-based browsers (e.g., Zen) are discussed as alternatives to Brave’s UX features.