Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

brave.com

Post reply on HN
Print view View original

51–60 of 289 posts

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

#51

Post by skaul »

mywittyname wrote: post #22
apparent wrote: post #20

Funny that the iOS update notes don't mention this at all: > in this release: > Other enhancements, stability improvements, and security updates No mention of efficiency, or adblocking whatsoever!

Is the iOS version of Brave actually the same codebase? My understanding is that all browsers on iOS have to wrap Safari, which would explain the release notes. But I could be wrong here, as I don't develop for iOS.

We use the same adblocking engine (adblock-rust) on all platforms, including iOS, hence the shared memory savings.

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

#52

Post by minitech »

ashishb wrote: post #47
Jalad wrote: 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.

> The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3

You’re looking at the number of dependents. The React package has no dependencies.

Asides:

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

Yes, some combination of doing that or delegating it to trusted parties is required. (The difficulty should inform dependency choices.)

> What if these sources include binary packages?

Reproducible builds, or don’t use those packages.

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

#53

Post by astrange »

nomel wrote: post #6
timeon wrote: 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.

"Saving X% of RAM" isn't a thing because RAM is itself a cache of compressed swap space and/or mapped files.

The lesson here is pointer-chasing data structures and trees are a lot more expensive than everyone and most programming languages like to pretend they are.

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

#54

Post by j1elo »

ashishb wrote: post #47
Jalad wrote: 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.

If that is really the case (I don't know numbers about React), in projects with a sane criteria of security, they would either only jump between versions that have passed a complete verification process (think industry certifications); or the other option is that simply by having such an enormous amount of dependencies would render that framework an undesirable tool to use, so they would just avoid it. What's not serious is living the life and incorporating 15-17K dependencies blindly because YOLO.

(so yes, I'm stating that 99% of JS devs who _do_ precisely that, are not being serious, but at the same time I understand they just follow the "best practices" that the ecosystem pushes downstream, so it's understandable that most don't want to swim against the current when the whole ecosystem itself is not being serious either)

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

#56

Post by rcxdude »

ashishb wrote: post #47
Jalad wrote: 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.

More useful than reading the code, in most cases, is looking at who's behind the code. Can you identify the author? Do they have an identity and reputation in the space? Are you looking at the version of the package they manage? People often freak out about the number of packages in such ecosystems but what matters a lot more is how many different people are in your dependency tree, who they are, and how they operate.

(The next most useful step, in the case where someone in your dependency tree is pwned, is to not have automated systems that update to the latest version frequently. Hang back a few days or so at least so that any damage can be contained. Cargo does not update to the latest version of a dependency on a built because of its lockfiles: you need to run an update manually)

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

#57

Post by nomel »

nwallin wrote: post #42
nomel wrote: post #6

Earlier quoted context omitted.

A $130 Motorola smartphone has 8GB of RAM. This will save 0.5% RAM. It's fairly negligible on modern systems.

OK now do the math for someone who has 200 tabs open. Remember that basically all browsers these days spin up one process per tab.

Modern browsers don't keep those 200 tabs in active memory. Hasn't been the case for over a decade.

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

#58

Post by drnick1 »

nicoburns wrote: post #48
nineteen999 wrote: post #34

Earlier quoted context omitted.

At risk like node/npm with all the supply-chain attacks then? Or is there something that cargo does to manage it differently (due diligence?).

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.

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

#59

Post by morshu9001 »

agosta wrote: post #41
awnird wrote: post #21

Does Brave actually block ads now? Or does it still replace them with ads for scanmy cryptocurrency?

Unlike other reply, I do not work at Brave, and I can also confirm that Brave never did that. They do have their own ads but those have always been opt in (you are not opted in by default), and they do pay some small amount of USD in their crypto token for opting in to those - it's pennies. People scoff at the pennies but guess who pays out nothing to show you ads against your will - literally everyone else. What you…

Important part missing here, they didn't tell anyone about the affiliate URL rewriting and only removed it when caught.

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

#60

Post by Cyph0n »

drnick1 wrote: post #58
nicoburns wrote: post #48

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.

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.

Post reply on HN