Live data from Hacker News

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

brave.com

241–250 of 289 posts

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

#241
post #182

162 to 104 is not 75% reduction... Who calculates reduction percentage like that?!

To be fair, they claim the adblock engine saw a 75% reduction in memory usage, and in the images they're showing the main browser process generally (I assume? I don't use Brave), or which the adblock engine is only a part but had a substantial impact on usage.

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

#242
post #189

Earlier quoted context omitted.

Rust ABI (as opposed to C ABI) dynamic libraries are incredibly fragile with regard to compiler/build environment changes. Trying to actually swap them out between separate builds is pretty much unsupported. So most of the benefits of dynamic libraries (sharing code between different builds, updating an individual dependency) are not achieved. They’re only really useful if you’re distributing multiple binary executab…

Rust does support C ABI through cdylib (as opposed to the unstable dylib ABI). This is used widely, especially for FFI. An example of this is Python modules in Rust using PyO3 [1]. [1] https://pyo3.rs/v0.15.1/#using-rust-from-python

Yeah but you can’t use the vast majority of crates that way. You have to create a separate unsafe C ABI, and then use it in the caller. Ergonomically, it’s like your dependency was written in C and you had to write a safe wrapper.

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

#243

Earlier quoted context omitted.

I wonder if anti-adblock devs will ever take advantage of the difference between the two

Used to work in this realm. It doesn't matter. Easylist will contact you, strongarm you into disabling your countermeasures and threaten to block all JS on your page if you don't comply. So no ad servers can load, no prebid, nothing will function/load if the user has an adblocker that uses easylist (all of them) installed.

HAHAHAH Hell yeah that's praxis baby die mad about it

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

#244
post #182

162 to 104 is not 75% reduction... Who calculates reduction percentage like that?!

To be fair, they claim the adblock engine saw a 75% reduction in memory usage, and in the images they're showing the main browser process generally (I assume? I don't use Brave), or which the adblock engine is only a part but had a substantial impact on usage.

That is correct.

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

#245
post #58

Earlier quoted context omitted.

You can use "cargo vendor" to copy-paste your dependencies C-style if you want to, and audit them all if you want. Mozilla does this for Firefox. Cargo does have lock files by default. But we really need better tooling for auditing (and enforcing tha auditing has happened) to properly solve this.

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.

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

The Rust approach is to split-off a minimal subset of functionality from your project onto an independent sub-crate, which can then be depended on and audited independently from the larger project. You don't need to get all of ripgrep[1] in order to get access to its engine[2] (which is further disentangled for more granular use).

Beyond the specifics of how you acquire and keep that code you depend on up to date (including checking for CVEs), the work to check the code from your dependencies is roughly the same and scales with the size of the code. More, smaller dependencies vs one large dependency makes no difference if the aggregate of the former is roughly the size of the monolith. And if you're splitting off code from a monolith, you're running the risk of using it in a way that it was never designed to work (for example, maybe it relies on invariants maintained by other parts of the library).

In my opinion, more, smaller dependencies managed by a system capable of keeping track of the specific version of code you depend on, which structured data that allows you to perform checks on all your dependencies at once in an automated way is a much better engineering practice than "copy some code from some project". Vendoring is anathema to proper security practices (unless you have other mechanisms to deal with the vendoring, at which point you have a package manager by another name).

[1]: https://crates.io/crates/ripgrep

[2]: https://crates.io/crates/grep/

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

#246
post #175

Earlier quoted context omitted.

This. I use Brave because it has a great, fast adblocker and is fast generally. Unticking all the wallet/AI crap upon install is an acceptable price, but if somebody is going to release Braveium I'm going to use it right away.

Is its adblocker as good as uBlock Origin?

It is better (especially than the Manifest V3 version) because it has first party access / integration.

In general, of 3rd party blockers, uBlock Origin isn't even the best, AdGuard is.

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

#248
post #246

Earlier quoted context omitted.

Is its adblocker as good as uBlock Origin?

It is better (especially than the Manifest V3 version) because it has first party access / integration. In general, of 3rd party blockers, uBlock Origin isn't even the best, AdGuard is.

> In general, of 3rd party blockers, uBlock Origin isn't even the best, AdGuard is.

Why? I thought uBlock Origin on Firefox was the most effective combination available (assuming that you use the same filter lists).

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

#249
post #146

I haven't seen an ad nor in iOS nor in Mac since I installed brave. The browser, for me , works perfect

What were you using before that? I never see any ad in Firefox with uBlock Origin. I can't imagine it's much of a difference experience than with Brave.

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

#250

Earlier quoted context omitted.

> I'd like to have a stable Rust ABI to make safe plugin systems A stable ABI would allow making more robust Rust-Rust plugin systems, but I wouldn't consider that "safe"; dynamic linking is just fundamentally unsafe. > Large binaries could also be broken down into dynamic libraries and make rebuilds much faster at the cost of leaving some optimizations on the table. This can already be done within a single project b…

Loading dynamic libraries can fail for many reasons but once loaded and validated it should be no more unsafe than regular crates?

You could check that mangled symbols match, and have static tables with hashes of structs/enums to make sure layouts match. That should cover low level ABI (though you would still have to trust the compiler that generated the mangling and tables).

A significantly more thorny issue is to make sure any types with generics match, e.g. if I declare a struct with some generic and some concrete functions, and this struct also has private fields/methods, those private details (that are currently irrelevant for semver) would affect the ABI stability. And the tables mentioned in the previous paragraph might not be enough to ensure compatibility: a behaviour change could break how the data is interpreted.

So at minimum this would redefine what is a semver compatible change to be much more restricted, and it would be harder to have automated checks (like cargo-semverchecks performs). As a rust developer I would not want this.

Post reply on HN