Earlier quoted context omitted.
> these days Are you referring to current RAM prices or bloat of numerous Electron apps?
A $130 Motorola smartphone has 8GB of RAM. This will save 0.5% RAM. It's fairly negligible on modern systems.
Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
191–200 of 289 posts
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#192Earlier quoted context omitted.
> Or does it still replace them with ads for scanmy cryptocurrency? Brave never did that. Brave blocks third-party ads & trackers by default. (disclaimer: I lead privacy and adblocking at Brave)
I definitely tried out brave several years ago and legit got lots of crypto ads. I really don’t know how you are getting upvoted for lying about this.
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#193Earlier quoted context omitted.
So brave has two CSS engines? One for rendering and one for blocking?
Yes. Since for blocking you can afford to have a less mature CSS engine. A tradeoff for performance.
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#194Earlier quoted context omitted.
if I recall correctly Rust does not support any form of dynamic linking or library loading. Most of the community I’ve interacted with are big on either embedding a scripting engine or WASM. Lots of momentum on WASM based plugins for stuff. It’s a weakness for both Rust and Go if I recall correctly
Go supports plugins (essentially libraries) but its has a bunch of caveats. You can also You can also link to C libs from both. I guess you could technically make a rust lib with C interface and load it from rust but that's obviously suboptimal
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#195Earlier quoted context omitted.
Not sure I follow. Suppose you tore out a portion of libxml2 for use in your HTTP server. A CVE is filed against libxml2 that is related to the subset you tore out. Obviously, your server doesn't link against libxml2. How exactly would distro maintainers know to include your package in their list?
You’d list it in your attribution?
Regardless, the maintenance burden remains.
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#196Earlier quoted context omitted.
I think the broader point being made here is that the C-style approach is to extract a minimal subset of the dependency and tightly review it and integrate it into your code. The Rust/Python approach is to use cargo/pip and treat the dependency as a black box outside your project.
Advocates of the C approach often gloss over the increased maintenance burden, especially when it comes to security issues. In essence, you’re signing up to maintain a limited fork & watch for CVEs separately from upstream. So it's ultimately a trade off rather than a strictly superior solution. Also, nothing in Rust prevents you from doing the same thing. In fact, I would argue that Cargo makes this process easier.
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#197I'm not sure how impressed I should feel about saving 45 MiB these days.
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#198Earlier quoted context omitted.
Yes. Since for blocking you can afford to have a less mature CSS engine. A tradeoff for performance.
I wonder if anti-adblock devs will ever take advantage of the difference between the two
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#199I just found out Brave supports Vertical tabs, https://brave.com/blog/vertical-tabs/ I might have to try switching from FF...
Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%
#200Earlier quoted context omitted.
Supply-chain attacks aren't really a property of the dependency management system Not having a dependency management system isn't a solution to supply chain attacks, auditing your dependencies is
> auditing your dependencies is How do you do that practically? Do you read the source of every single package before doing a `brew update` or `npm update`? What if these sources include binary packages? The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 Can anyone even review it in a month? And they publish a new update weekly.
There are several ways to do this. What you mentioned is the brute-force method of security audits. That may be impractical as you allude to. Perhaps there are tools designed to catch security bugs in the source code. While they will never be perfect, these tools should significantly reduce the manual effort required.
Another obvious approach is to crowd source the verification. This can be achieved through security advisory databases like Rust's rustsec [1] service. Rust has tools that can use the data from rustsec to do the audit (cargo-audit). There's even a way to embed the dependency tree information in the target binary. Similar tools must exist for other languages too.
> What if these sources include binary packages?
Binaries can be audited if reproducible builds are enforced. Otherwise, it's an obvious supply chain risk. That's why distros and corporations prefer to build their software from source.