Live data from Hacker News

Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

brave.com

191–200 of 289 posts

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#191
post #6
post #4

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.

This kind of attitude is why everything is so bloated nowadays...

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#192
post #30

Earlier 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.

[flagged]

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#193
post #176

Earlier 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.

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%

#194

Earlier 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

The dynamic libraries that use the unstable Rust ABI are called `dylib`s, while those that use the stable C ABI are called `cdylib`s. Suppose a stable version of the Rust ABI is defined, what would be the point of putting dynamic libraries that follows this API, in the system? Only Rust would be able to open it, whereas the system shared libraries are traditionally expected to work across languages using C ABI and language-specific wrappers. By extension, this is a problem that affects all languages that has more complex features than C. Why would this be considered as a Rust flaw?

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#195
post #85

Earlier 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?

I am unfamiliar with the details of distro packaging. Do they commonly use the attribution to route CVEs?

Regardless, the maintenance burden remains.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#196
post #60
post #58

Earlier 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.

And advocates of the opposite approach created the dependencies hellscape that NPM is nowadays.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#197

I'm not sure how impressed I should feel about saving 45 MiB these days.

That’s the wrong way to look at it. Improving the performance of a complex piece of software is not something you do in one fell swoop, or even in a dozen smaller steps. It’s a job of compounding many tiny single–digit percentages over years, and of carefully avoiding performance regressions.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#198
post #176

Earlier 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

That's a lot of work to bypass the blocks on a browser that's far from the market leader. Now, even if the browser does become popular enough in the future to be targeted, the developers would probably gain enough resources and support to replace one of the engines with the other.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#200
post #47
post #38

Earlier 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.

> How do you do that practically? Do you read the source of every single package before doing a `brew update` or `npm update`?

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.

[1] https://rustsec.org/

Post reply on HN