Brave's adblocking engine is a neat example of open source and the ease of sharing lbraries in Rust. It uses Servo crates (also used by Firefox) to parse CSS and evaluate selectors, and is then itself published as a crate on crates.io where it can be pulled in by others who may want to use it.
The `selectors` crate is pretty mature to be fair. It's what's used in Firefox for all CSS selector matching. The main advantage of using it is that it's modular so you can just pull that part out without the entire CSS engine.
Also the filters for adblocking have extended the CSS selector syntax to add extra features, and you might not want those to leak into your parser for stylesheets.
That's amazing. I just assumed the ad lists were volunteer maintained like a wiki. I'll be sure to use Easylist now that I know they're also advocating for users while punishing bad advertisers.
I'm still not entirely sure it's for the best or not.
On one hand, it is a concentration of power into hands a few people.
On the other, it is for a good cause, to maintain a list of ad network and site banners that drain resources, cause privacy issues, etc.
The Easylist people aren't saints. They get paid off by Google to allow "Acceptable Ads". So you just show a different campaigns if your user is running adblocker nowadays.
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.
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.
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?
I believe some distros require un-vendoring before accepting the package.
If the code you vendored was well hidden so the distro maintainer didn't notice, perhaps the bad guys would also fail to realize you were using (for instance) libxml2, and not consider your software a target for attack.
That's assuming you're using dynamically linked libraries/shared libraries. They're talking about "vendoring" the library into a statically linked binary or its own app-specific DLL.
In theory yes, but in practice I don't think you could build something like Servo very easily like that. Servo is a browser, but it's also purposefully designed to be a browser-developer's toolkit. It is very modular, and lots of pieces (like the aforementioned CSS selector library) are broken out into separate packages that anyone can then use in other projects. And Servo isn't alone in this.
However, when you install Servo, you just install a single artefact. You don't need to juggle different versions of these different packages to make sure they're all compatible with each other, because the Servo team have already done that and compiled the result as a single static binary.
This creates a lot of flexibility. If the Servo maintainers think they need to make a breaking change somewhere, they can just do that without breaking things for other people. They depend internally on the newer version, but other projects can still continue using the older version, and end-users and distros don't need to worry about how best to package the two incompatible versions and how to make sure that the right ones are installed, because it's all statically built.
And it's like this all the way down. The regex crate is a fairly standard package in the ecosystem for working with regexes, and most people will just depend on it directly if they need that functionality. But again, it's not just a regex library, but a toolkit made up of the parts needed to build a regex library, and if you only need some of those parts (maybe fast substring matching, or a regex parser without the implementation), then those are available. They're all maintained by the same person, but split up in a way that makes the package very flexible for others to take exactly what they need.
In theory, all this is possible with traditional distro packages, but in practice, you almost never actually see this level of modularity because of all the complexity it brings. With Rust, an application can easily lock its dependencies, and only upgrade on its own time when needed (or when security updates are needed). But with the traditional model, the developers of an application can't really rely on the exact versions of dependencies being installed - instead, they need to trust that the distro maintainers have put together compatible versions of everything, and that the result works. And when something goes wrong, the developers also need to figure out which versions exactly were involved, and whether the problem exists only with a certain combination of dependencies, or is a general application problem.
All this means that it's unlikely that Servo would exist in its current form if it were packaged and distributed under the traditional package manager system, because that would create so much more work for everyone involved.
> 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).
As far as I know, these 100+ dev dependencies are installed by default.
Yes, you can probably avoid it, but it will likely break something during the build process, and most people just stick to the default anyway.
> Reproducible builds, or don’t use those packages.
No. They’re only installed if you git clone react and npm install inside your clone.
They are only installed for the topmost package (the one you are working on), npm does not recurse through all your dependencies and install their devDependencies.
The best tool for your median software-producing organization, who can’t just hire a team of engineers to do this, is update embargoes. You block updating packages until they’ve been on the registry for a month or whatever by default, allowing explicit exceptions if needed. It would protect you from all the major supply-chain attacks that have been caught in the wild.
In security-sensitive code, you take dependencies sparingly, audit them, and lock to the version you audited and then only take updates on a rigid schedule (with time for new audits baked in) or under emergency conditions only.
Not all dependencies are created equal. A dependency with millions of users under active development with a corporate sponsor that has a posted policy with an SLA to respond to security issues is an example of a low-risk dependency. Someone's side project with only a few active users and no way to contact the author is an example of a high-risk dependency. A dependency that forces you to take lots of indirect dependencies would be a high-risk dependency.
Practically, unless you code is super super security sensitive (something like a root of trust), you won't be able to review everything. You end up going for "good" dependencies that are lower risk. You throw automated fuzzing and linting tools, and these days ask AI to audit it as well.
You always have to ask: what are the odds I do something dumb and introduce a security bug vs what are the odds I pull a dependency with a security bug. If there's already "battle hardened" code out there, it's usually lower risk to take the dep than do it yourself.
This whole thing is not a science, you have to look at it case-by-case.
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)
> 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.
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)
> 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?
That doesn't necessarily help you in the case of supply chains attacks. A large proportion of them are spread through compromised credentials. So even if the author of a package is reputable, you may still get malware through that package.
Normally it would omly be the diff from a previous version. But yes, it's not really practical for small companies or individuals atm. Larger companies do exactly this.
We need better tooling to enable crowdsourcing and make it accessible for everyone.
I don't know much about node but cargo has lock file with hashes which prevents dep substitution unless dev decide to update lock file. Updating lock file has same risks as initial decision to depend on deps.
Rust crates run arbitrary code more often at build/install time than npm packages do.
Some people use 'pnpm', which only runs installScripts for a whitelisted subset of packages, so an appreciable fraction of the npm ecosystem (those that don't use npm or yarn, but pnpm) do not run scripts by default.
Cargo compiles and runs `build.rs` for all dependencies, and there's no real alternative which doesn't.
Pretty much, yes. And they don’t have much as far as isolation goes. It’s a bit frightening honestly.
It does unlock some interesting things to be sure, like sqlx’ macros that check the query at compile time by connecting to the database and checking the query against it. If this sounds like the compiler connecting to a database, well, it’s because it is.
And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedia decoders, etc., right?
As a user and developer, runtime is my least favourite place for dependency and library errors to occur. I can't even begin to count the hours, days, I've spent satisfying runtime dependencies of programs. Cannot load library X, fix it, then cannot load library Y, fix it, then library Z is the wrong version, then a glibc mismatch for good measure, repeat.
I'd give a gig of my memory to never have to deal with that again.
> if I recall correctly Rust does not support any form of dynamic linking or library loading.
Rust supports two kinds of dynamic linking:
- `dylib` crate types create dynamic libraries that use the Rust ABI. They are only usesul within a single project though, since they are only guaranteed to work with the crate that depended on them at the compilation time.
- `cdylib` crate types with exported `extern "C"` functions; this creates a typical shared library in the C way, but you also need to implement the whole interface in a C-like unsafe subset of Rust.
Neither is ideal, but if you really want to write a shared library you can do it, it's just not a great experience. This is part of the reason why it's often preferred to use scripting languages or WASM (the other reason being that scripting languages and WASM are sandboxed and hence more secure by default).
I also want to note that a common misconception seems to be that Rust should allow any crate to be compiled to a shared library. This is not possible for a series of technical reasons, and whatever solution will be found will have to somehow distinguish "source only" crates from those that will be compilable as shared libraries, similarly to how C++ has header-only libraries.
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 executables that share most of the underlying code, and you want to save some disk space in the final install. The standard Rust toolchain builds use them for this purpose last time I checked.
Yep that’s right. I’ve been working on a game with bevy. The Bevy game engine supports being dynamic linked during development in order to keep compile times down. It works great.
People thinking C++ libraries magically solve this ABI issue is the other side of the coin. I’ve filed numerous bugs against packages precompiled libraries but misusing the C abi so that (owned) objects cross the abi barrier and end up causing heap corruption (with a segfault only if you’re lucky) and other much more subtle heisenbugs.
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].
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.
C++ has the opposite problem where people think they can just dynamically or statically link against any api be ok. You can’t cross the ABI barrier without a) knowing it’s there, and b) respecting its rules.
You get lucky when all assets have been compiled with the same toolchain (with the same options) but will lose your mind when you have issues caused by this thing neither you nor the package authors knew existed.
That is not correct. Dynamic linking is natively supported in Rust. How else do you make modules for scripting languages like Python (using PyO3) [1]? It uses the stable C API (cdylib).
Is it a RAM problem though? My understanding is that each process loads the shared library in its own memory space, so it's only a ROM/HDD space problem.
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?
I don’t mean Dylibs like you find on macOS, I mean loading a binary lib from an arbitrary directory and being able to use it, without compiling it into the program.
It’s been some time since I looked into this so I wanted to be clear on what I meant. I’d be elated to be wrong though
Then by that argument Rust also supports dynamic linking. Actually it’s even better because that approach sacrifices less performance (if done well) than cgo inherently implies.
Well, Rust does support dynamic linking. It just doesn’t (yet) offer a stable ABI. So you need to either use C FFI over the dynamic linking bridge, or make sure all linked libraries are compiled with the same version of the rust compiler.
Not really? You just need to define the stable ABI: you do that via `[repr(C)]` and other FFI stuff that has been around since essentially the beginning. Then it handles it just fine, for both the code using a runtime library and for writing those runtime libraries.
People writing Rust generally prefer to stay within Rust though, because FFI gives up a lot of safety (normally) and is an optimization boundary (for most purposes). And those are two major reasons people choose Rust in the first place. So yeah, most code is just statically compiled in. It's easier to build (like in all languages) and is generally preferred unless there's a reason to make it dynamic.
Dynamic libraries are a dumpster fire with how they are implemented right now, and I'd really prefer everything to be statically linked. But ideally, I'd like to see exploration of a hybrid solution, where library code is tagged inside a binary, so if the OS detects that multiple applications are using the same version of a library, it's not duplicated in RAM. Such a design would also allow for libraries to be updated if absolutely necessary, either by runtime or some kind of package manager.
OSes already typically look for duplicated code pages as opportunities to dedupe. It doesn’t need to be special cases for code pages because it’ll also find runtime heap duplicates that seem to be read only (eg your JS code JIT pages shared between sites).
One challenge will be that the likelihood of two random binaries having generated the same code pages for a given source library (even if pinned to the exact source) can be limited by linker and compiler options (eg dead code stripping, optimization setting differences, LTO, PGO etc).
The benefit of sharing libraries is generally limited unless you’re using a library that nearly every binary may end up linking which has decreased in probability as the software ecosystem has gotten more varied and complex.
I believe NixOS-like "build time binding" is the answer. Especially with Rust "if it compiles, it works". Software shares code in form of libraries, but any set of installed software built against some concrete version of lib which it depends on will use this concrete version forever (until update replaces it with new builds which are built against different concrete version of lib).
The system you’re proposing wouldn’t work, because without additional effort in the compiler and linker (which AFAIK doesn’t exist) there won’t be perfectly identical pages for the same static library linked into the same executable. And once you can update them independently, you have all the drawbacks of dynamic libraries again.
Outside of embedded, this kind of reuse is a very marginal memory savings for the overall system to begin with. The key benefit of dynamic libraries for a system with gigabytes of RAM is that you can update a common dependency (e.g. OpenSSL) without redownloading every binary on your system.
I wish the standard way of using shared libraries would be to ship the .so the programs want to dynamically link to alongside the program binary (using RUNPATH), instead of expecting them to exist globally (yes, I mean all shared libraries even glibc, first and foremost glibc, actually).
This way we'd have no portability issue, same benefit as with static linking except it works with glibc out of the box instead of requiring to use musl, and we could benefit from filesystem-level deduplication (with btrfs) to save disk space and memory.
Yes, it did. We have literally millions of times as much memory as in 1970 but far less than millions of times as many good library developers, so this is probably the right tradeoff.
C++ already killed it: templated code is only instantiated where it is used, so with C++ it is a random mix of what goes into the separate shared library and what goes into the application using the library. This makes ABI compatibility incredibly fragile in practise.
And increasingly, many C++ libraries are header only, meaning they are always statically linked.
Haskell (or GHC at least) is also in a similar situation to Rust as I understand it: no stable ABI. (But I'm not an expert in Haskell, so I could be wrong.)
It's not just about memory. I'd like to have a stable Rust ABI to make safe plugin systems. 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 could be done today with a semi stable versionned ABI. New app builds would be able to load older libraries.
The main problem with dynamic libraries is when they're shared at the system level. That we can do away with. But they're still very useful at the app level.
> 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 by using the dylib crate type.
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.
I am surprised there does not exist a community fork of Brave yet that strips out all of the commercial stuff (rewards, AI, own updates), making it suitable for inclusion in the repos of mainstream free/libre Linux distros.
There is quite a lot of costs associated with running a browser (at scale).
Brave is looking to offer something that does what you mention called Brave-origin.
Open source software can be sold for money. For example redhat selling cds with rhel on them, for quite a big sticker price. Free if you build it yourself but you have to pay to get a ready to use version.
or figure out how to build it yourself from source. But you can count on the lazy tax - esp. for windows (as building from source on linux is likely to be much more convenient).
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.
The main reason for people repeating "uBlock Origin + Firefox is best" is because CNAME uncloaking didn't work on most Chromium browsers, even on Manifest V2. It does on Brave.
AdGuard works better simply because there's a bunch of people being paid to work on it. There's more optimization and less bugs. The UI is a whole lot more polished. Blocklists have improved syntax, and the lists themselves are updated more frequently to catch site breakage. EasyList often has breakage on their lists for months even after being reported on their Github, but reporting the same breakage to AdGuard results in the breakage being fixed in days if not hours. And they do adjacent projects like AdGuard Home (sort of a commercial Pi-Hole) too.
FWIW, big names in adblocking work for these companies too. AFAIK, FanBoy (EasyList + EasyPrivacy + his own lists) gets paid by Brave to maintain the lists. So in a way, Brave is funding adblocking for everyone :)
You can disable all of that within seconds. There's no reason for it not to be included because of that, as all the code running on the client is open-source. If distros only shipped software without commercial interests (why even..?), it'd be an unusable mess of barely maintained hobby projects.
Helium is based on ungoogled-chromium. It enables manifest v2 by simply reverting some code changes made by google. So, if google decides to remove manifest v2 wholly, helium will also lost its ublock original support.
Removing all manifest v2 support is also a code change that can be reverted. Of course, the larger the change, the more work it's likely to require to maintain it in the future.
Mozilla does not have commercial bits. They do receive money from Google to be the default search engine, and the binaries they build report telemetry, but the versions found in Linux repos often either patch out the telemetry or disable it.
For technical users who are in the know, yes. I would not recommend Brave to less-technical friends and family knowing that they would surely be duped by some dark patterns in Brave's UI/UX.
Even Firefox, which is the best we have currently, surprises us a few times a year with questionable decisions. Still, it's what I recommend to people.
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.
A great power of Firefox are its add-ons, aren't they? Sidebery [1] has been a solid implementation of vertical tabs since a long time ago. Begore that got popular, Tree Style Tabs [2] was also a very comprehensive solution.
But nowadays, vertical tabs are native since Firefox v136 [3][4], so at least for the basics you won't need an add-on.
Not yet but it's in development (I'm a product designer at Brave). We're working through other issues with vertical tabs before we continue work on this :)
Not yet but it's in development (I'm a product designer at Brave). We're working through other issues with vertical tabs before we continue work on this :)
https://github.com/brave/brave-browser/issues/44345
He supported proposition 8 in California in 2008 (which passed). Some view that as unforgivable, and it's the main driving force behind all subsequent controversy about Eich.
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.
>I hope that this is the start of developers being conscious of using resources efficiently again, especially in the browser.
AI may have forced the hand on this. Users will no longer be able to subsidize software performance with hardware upgrades due to the great DRAM debacle of 2026..
I recently switched over from FF on Android to Brave. It is much faster, and although extensions are missing, it has a bunch of built in features that covered my use case:
- Forced Dark mode
- Ad blocking
Recently I've found Cromite and sure glad I did! Finally I've found my Kiwi browser replacement. It is also feels faster than both Firefox and Brave on Android (though YMMV).
And here I am on IOS where Brave but not Firefox can use adblockers.
My fucking god I’m not sure enshittification has ever been so widely dispersed. It’s impossible to have any type of unified set up across different OS/devices currently.
Kind of, but not really, the ublock origin app doesn't work on Orion. I tried both Kagi + uBlock versus Brave and their built-in ad-block and Brave had a much better performance.
Maybe not for crypto, but they did spend a year or two surreptitiously installing their own VPN service on your Widows machine without any opt-out ability, and then failed to remove it, its Windows service, or multiple scheduled tasks once the brave uninstaller had been run.
The best part was this whole scam sitting as an unresolved issue on GitHub for months after they finally acknowledged it (after first denying it lol).
Closest browser I’ve seen to an actual virus in maybe ever.
And it’s a good lesson for developers that once you lose trust there are many of us who will never make the same mistake again purely out principle.
They could cut it 110%, so my available RAM grew bigger, and I would still not trust them. They have been caught with their hands deep in the cookie jar too many times.
> In 2020, the company was found to be appending affiliate referral codes to the end of certain cryptocurrency exchange URLs typed into the browser's address bar. The practice applied to exchanges such as Binance and Coinbase, and was later discovered to extend to suggested search queries for terms like "bitcoin" and "ethereum".
> In 2022, Brave faced further criticism for bundling its paid virtual private network (VPN) product, Brave Firewall + VPN, into installations of its Windows browser, even for users who had not subscribed to the service
Why don't Mozilla make or use such engine in its browser? Make something really native for dealing with ads and annoyances. The irony is Brave smartly uses Rust which were forsaken by Mozilla. I know Mozilla seems to have something for ads but honestly I don't even know what it really does, beside its shield icon.
Mozilla wants Firefox to be a mainstream browser that anyone can use. Ad blocking introduces the risk of site breakage, and the majority of the population don't have the knowledge to deal with it.
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.
Be as impressed as you want but I think it is a very good sign that developers are taking care of it, and as this is a free to use product we can always be happy if someone boosts performance no matter how much
Very, if only because you'd have said I'm not sure how impressed I should be about saving 4.5 MB these days not all that long ago. Remember when emacs was backronymised to 'eight megabytes and constantly swapping'? That was also not all that long ago. Now 8 megabytes is what some pissant JS library takes as part of some miserable npm package used to bellyflop an ad into your browser window.
Just personal experience using LLMs. I've optimized a lot of things in the past year I wouldn't normally have time to do, especially build systems/pipelines.
"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.
It's more than that, because generally performance is also much worse if you're using a shit ton of memory. That's because CPUs are bottlenecked by cache. So more memory means cache has to be flushed more often, and there will be more misses, which can greatly impact performance.
But they do keep the active tab of each window in memory. Firefox even continues rendering all active tabs in all windows, even if for windows which are not visible.
Not sure if this 45MB is per browser instance or per tab, but it’s the latter case, 10 windows would save 450MB. >10% on a lower-end device.
The Zen browser - a derivative of Firefox, also supports split tabs (and a lot of others like spaces, vertical tabs and glances). The project seems fairly active and up to date in the past few years.
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.
That's an absolute lie. The entire browser uses around 400MB when a single tab for news.ycombinator.com is open. The tab itself sits at around 35MB. Additional tab increases by the same amount.
Sure, but some like a trustworthy company from a trustworthy country behind the software we use. 45 MiB less isn't enough to forget the history of Brave. The hidden VPN install and adding their own affiliate links haven't been forgotten.
The most effective ad blocker I've ever used. With that, it becomes better than chrome, in my opinion. Give it a spin, it's my daily driver for web dev as well ( just chrome debugger)
FlatBuffers was definitely the majority of the improvements here!
On 64-bit systems, pointers themselves can really start to take up a lot of memory (especially if you multiply them across 100k+ adblock filters). Switching to array indices instead of pointers saves a lot of memory that's otherwise wasted when you don't need to address the entire possible memory space.
I guess code bloat is proportional to schema complexity, and performance improvement is proportional to volume, so in ad blocker with many large block lists the latter dominates.
The biggest improvement for us was deduplication by using generators an referencing already emitted objects. Don't run flatc on a JSON, it doesn't do that.
Brave also installed a VPN an a VPN service without permission on my Windows machine, and then didn’t disable or remove 3 separate scheduled tasks in Windows Scheduler once I’d uninstalled it. The VPN issue was open for like 8+ months on GitHub too - and at first they denied doing it at all. For all I know it still installs it, but I removed this malware-type shit when this all happened so I couldn’t tell you.
You've commented this three (?) times under this HN post and several times on this site now. Sure seems like you have a bone to pick.
The VPN they installed was disabled and they could not activate it without user interaction. And the only reason they did this is so when you click "activate VPN" in the browser, it works immediately.
On top of that, other businesses employ(ed) similar tricks. For years and years and years, Dropbox on macOS did a very specific hack to give itself more permissions to ease syncing. Hell, Firefox injected ads for Mr. Robot via a surreptitiously installed invisible extension.
Still a boneheaded move by Brave, just like adding their own affiliate link to crypto links (if none were added) to generate extra revenue for the company at no extra cost to the user. But that is even further in the past.
At any rate, they also fund or develop a bunch of anti-ad tech and research and make it open source / publish it. The defaults of Brave protect your privacy much better than Firefox's defaults. And so far, their BAT concept is the only one that is a legitimate alternative to an ad-funded internet.
Minimising a browser installer surreptitiously installing an unrelated network service without my consent in the name of convenience and then pulling out a whataboutism that has nothing to do with this. Not even gonna bother reading the rest of your comment.
And yeah, my bone to pick is warning others not to fall for Brave’s slick PR. Companies that act that way can pay the price.
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 may be thinking of was at one point, when you went to a URL (for some URLs), the browser would rewrite the URL to contain their affiliate link. There was blowback for doing that. They quickly removed that/haven't done it since as far as I know
The grants came from our token fund, not users' tokens (no way to buy BAT then).
The issue which I found out about late, and fixed right away, was infringing on right to publicity, nothing to do with donations from users' own tokens.
Already shared, but that (what you linked to) was a proposal and no deliverable was ever publicly released. A simple prototype was made and tested by a limited number of employees - instead of showing an ad, it would show a picture of a mustachioed man as a placeholder. That silly picture would be replaced with real code if the idea panned out. It didn't. The idea and the code was canned before I joined Brave and I've been here for almost 10 years (I joined August 2016).
Disclaimer in case it's not obvious: I am a Brave employee
That blog post is about a partnership (which ended), but you probably saw some sponsored images at the time, in new tab pages (1 of 4 then, I think; the rest are just art images).
These are non-tracking, carefully designed (including vetting by Brave), brand advertising images. They are not ads (we never did this) inserted into publisher pages, or (opt-in only) push notifications.
Brave has been working to find ways to sustain ourselves, and these sponsored images are still a good revenue line, although lesser now vs other lines. If you want, turn them off.
Free riding is always an user right, we don't try to stop it on principle, as if we ever could with open source. But there's no free lunch: if you use Firefox, you are Google's product. If you use a Firefox fork, you're free riding on Gecko which costs a lot to maintain. HTH
Maybe what GP remember is the VPN they secretly installed, the affiliate links they silently added, the donations they took for other companies and kept for themselves, or one of the other times Brave was caught. It is a wonder people think the code base is trustworthy when we know for a fact how they behave with stuff we can see. But sure, try to make it look like it has anything to do with a person hardly anyone have ever heard of.
With the number of times the above lie has been repeated and corrected, virtually every single Brave thread for several years straight now, I am inclined to think it's actually maliciousness which is motivating people to continue posting it.
Brave's adblocking engine is a neat example of open source and the ease of sharing lbraries in Rust. It uses Servo crates (also used by Firefox) to parse CSS and evaluate selectors, and is then itself published as a crate on crates.io where it can be pulled in by others who may want to use it.
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.
The `selectors` crate is pretty mature to be fair. It's what's used in Firefox for all CSS selector matching. The main advantage of using it is that it's modular so you can just pull that part out without the entire CSS engine.
Also the filters for adblocking have extended the CSS selector syntax to add extra features, and you might not want those to leak into your parser for stylesheets.
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.
That's amazing. I just assumed the ad lists were volunteer maintained like a wiki. I'll be sure to use Easylist now that I know they're also advocating for users while punishing bad advertisers.
That is hilarious to be fair, like a modern day Robin Hood.
It was an interesting experience.
I'm still not entirely sure it's for the best or not.
On one hand, it is a concentration of power into hands a few people.
On the other, it is for a good cause, to maintain a list of ad network and site banners that drain resources, cause privacy issues, etc.
The Easylist people aren't saints. They get paid off by Google to allow "Acceptable Ads". So you just show a different campaigns if your user is running adblocker nowadays.
Well, I run EasyList for most ads and then also other filters to remove "acceptable ads" so it works well for me.
I wasn't implying there weren't workarounds.
Just that Easylist is indirectly funded by ad revenue (google)
When it comes to ads, it's about the bulk of people, most don't run anything other than the default lists.
You're probably thinking of Adblock Plus? Acceptable Ads is their program; EasyList has no such policy or ties.
HAHAHAH Hell yeah that's praxis baby die mad about it
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.
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.
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.
But that's what Linux distros are for, package maintainers watch the CVEs for you, and all you have to do is "apt upgrade"
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.
I believe some distros require un-vendoring before accepting the package.
If the code you vendored was well hidden so the distro maintainer didn't notice, perhaps the bad guys would also fail to realize you were using (for instance) libxml2, and not consider your software a target for attack.
That's assuming you're using dynamically linked libraries/shared libraries. They're talking about "vendoring" the library into a statically linked binary or its own app-specific DLL.
Be very careful with that assumption.
The distros try, but one complex problem with a project that holds strong opinions and you may not have a fix.
The gnome keyring secrets being available to any process running under your UID, unless that process ops into a proxy as an example.
Looking at how every browser and busybox is exempted from apparmor is another.
It is not uncommon to punt the responsibility to users.
In theory yes, but in practice I don't think you could build something like Servo very easily like that. Servo is a browser, but it's also purposefully designed to be a browser-developer's toolkit. It is very modular, and lots of pieces (like the aforementioned CSS selector library) are broken out into separate packages that anyone can then use in other projects. And Servo isn't alone in this.
However, when you install Servo, you just install a single artefact. You don't need to juggle different versions of these different packages to make sure they're all compatible with each other, because the Servo team have already done that and compiled the result as a single static binary.
This creates a lot of flexibility. If the Servo maintainers think they need to make a breaking change somewhere, they can just do that without breaking things for other people. They depend internally on the newer version, but other projects can still continue using the older version, and end-users and distros don't need to worry about how best to package the two incompatible versions and how to make sure that the right ones are installed, because it's all statically built.
And it's like this all the way down. The regex crate is a fairly standard package in the ecosystem for working with regexes, and most people will just depend on it directly if they need that functionality. But again, it's not just a regex library, but a toolkit made up of the parts needed to build a regex library, and if you only need some of those parts (maybe fast substring matching, or a regex parser without the implementation), then those are available. They're all maintained by the same person, but split up in a way that makes the package very flexible for others to take exactly what they need.
In theory, all this is possible with traditional distro packages, but in practice, you almost never actually see this level of modularity because of all the complexity it brings. With Rust, an application can easily lock its dependencies, and only upgrade on its own time when needed (or when security updates are needed). But with the traditional model, the developers of an application can't really rely on the exact versions of dependencies being installed - instead, they need to trust that the distro maintainers have put together compatible versions of everything, and that the result works. And when something goes wrong, the developers also need to figure out which versions exactly were involved, and whether the problem exists only with a certain combination of dependencies, or is a general application problem.
All this means that it's unlikely that Servo would exist in its current form if it were packaged and distributed under the traditional package manager system, because that would create so much more work for everyone involved.
And advocates of the opposite approach created the dependencies hellscape that NPM is nowadays.
I mean, that's exactly what you are doing with every single dependency you take on regardless of language.
Let's be real about dependencies https://wiki.alopex.li/LetsBeRealAboutDependencies seems to give a different perspective on C dependencies though.
> 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/
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.
> You’re looking at the number of dependents. The React package has no dependencies.
Indeed.
My apologies for misinterpreting the link that I posted.
Consider "devDependencies" here
https://github.com/facebook/react/blob/main/package.json
As far as I know, these 100+ dev dependencies are installed by default. Yes, you can probably avoid it, but it will likely break something during the build process, and most people just stick to the default anyway.
> Reproducible builds, or don’t use those packages.
A lot of things are not reproducible/hermetic builds. Even GitHub Actions is not reproducible https://nesbitt.io/2025/12/06/github-actions-package-manager...
Most frontend frameworks are not reproducible either.
> don’t use those packages.
And do what?
> As far as I know, these 100+ dev dependencies are installed by default.
devDependencies should only be installed if you're developing the React library itself. They won't be installed if you just depend on React.
> They won't be installed if you just depend on React.
Please correct me if I am wrong, here's my understanding.
"npm install installs both dependencies and dev-dependencies unless NODE_ENV is set to production."
It does not recursively install dev-dependencies.
> It does not recursively install dev-dependencies.
So, these ~100 [direct] dev dependencies are installed by anyone who does `npm install react`, right?
No. They’re only installed if you git clone react and npm install inside your clone.
They are only installed for the topmost package (the one you are working on), npm does not recurse through all your dependencies and install their devDependencies.
> ~100 [direct]
When you do `npm install react` the direct dependency is `react`. All of react's dependencies are indirect.
Run `npm install react` and see how many packages it says it added. (One.)
If you're trying to audit React, don't you either need to audit its build artifacts rather than its source, or audit those dev dependencies too?
> And do what?
Keep on keepin on
[dead]
The best tool for your median software-producing organization, who can’t just hire a team of engineers to do this, is update embargoes. You block updating packages until they’ve been on the registry for a month or whatever by default, allowing explicit exceptions if needed. It would protect you from all the major supply-chain attacks that have been caught in the wild.
> The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3
You’re looking a dependents. The core React package has no dependencies.
In security-sensitive code, you take dependencies sparingly, audit them, and lock to the version you audited and then only take updates on a rigid schedule (with time for new audits baked in) or under emergency conditions only.
Not all dependencies are created equal. A dependency with millions of users under active development with a corporate sponsor that has a posted policy with an SLA to respond to security issues is an example of a low-risk dependency. Someone's side project with only a few active users and no way to contact the author is an example of a high-risk dependency. A dependency that forces you to take lots of indirect dependencies would be a high-risk dependency.
Here's an example dependency policy for something security critical: https://github.com/tock/tock/blob/master/doc/ExternalDepende...
Practically, unless you code is super super security sensitive (something like a root of trust), you won't be able to review everything. You end up going for "good" dependencies that are lower risk. You throw automated fuzzing and linting tools, and these days ask AI to audit it as well.
You always have to ask: what are the odds I do something dumb and introduce a security bug vs what are the odds I pull a dependency with a security bug. If there's already "battle hardened" code out there, it's usually lower risk to take the dep than do it yourself.
This whole thing is not a science, you have to look at it case-by-case.
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)
> 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/
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)
> 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?
That doesn't necessarily help you in the case of supply chains attacks. A large proportion of them are spread through compromised credentials. So even if the author of a package is reputable, you may still get malware through that package.
Normally it would omly be the diff from a previous version. But yes, it's not really practical for small companies or individuals atm. Larger companies do exactly this.
We need better tooling to enable crowdsourcing and make it accessible for everyone.
> Larger companies do exactly this.
Someone committed malicious code in Amazon Developer Q.
AWS published a malicious version of their own extension.
https://aws.amazon.com/security/security-bulletins/AWS-2025-...
I don't know much about node but cargo has lock file with hashes which prevents dep substitution unless dev decide to update lock file. Updating lock file has same risks as initial decision to depend on deps.
Edit: I misremembered a Rust crates capability (pre- and post-install hooks), so my comment was useless and misleading.
Rust crates run arbitrary code more often at build/install time than npm packages do.
Some people use 'pnpm', which only runs installScripts for a whitelisted subset of packages, so an appreciable fraction of the npm ecosystem (those that don't use npm or yarn, but pnpm) do not run scripts by default.
Cargo compiles and runs `build.rs` for all dependencies, and there's no real alternative which doesn't.
Rust crates can run arbitrary code at build time: https://doc.rust-lang.org/cargo/reference/build-scripts.html
> Build scripts communicate with Cargo by printing to stdout.
Oh lord.
Wrote an entire crate to clean up that mess (and provide traditional autoconf-ish features for build.rs): https://crates.io/crates/rsconf
Geez, thank you.
Aren't procedural macros amd build.rs arbitrary code being executed at build time?
Pretty much, yes. And they don’t have much as far as isolation goes. It’s a bit frightening honestly.
It does unlock some interesting things to be sure, like sqlx’ macros that check the query at compile time by connecting to the database and checking the query against it. If this sounds like the compiler connecting to a database, well, it’s because it is.
And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedia decoders, etc., right?
PS. Actually I'll risk to share my (I'm new to Rust) thoughts about it: https://shatsky.github.io/notes/2025-12-22_runtime-code-shar...
As a user and developer, runtime is my least favourite place for dependency and library errors to occur. I can't even begin to count the hours, days, I've spent satisfying runtime dependencies of programs. Cannot load library X, fix it, then cannot load library Y, fix it, then library Z is the wrong version, then a glibc mismatch for good measure, repeat.
I'd give a gig of my memory to never have to deal with that again.
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
> if I recall correctly Rust does not support any form of dynamic linking or library loading.
Rust supports two kinds of dynamic linking:
- `dylib` crate types create dynamic libraries that use the Rust ABI. They are only usesul within a single project though, since they are only guaranteed to work with the crate that depended on them at the compilation time.
- `cdylib` crate types with exported `extern "C"` functions; this creates a typical shared library in the C way, but you also need to implement the whole interface in a C-like unsafe subset of Rust.
Neither is ideal, but if you really want to write a shared library you can do it, it's just not a great experience. This is part of the reason why it's often preferred to use scripting languages or WASM (the other reason being that scripting languages and WASM are sandboxed and hence more secure by default).
I also want to note that a common misconception seems to be that Rust should allow any crate to be compiled to a shared library. This is not possible for a series of technical reasons, and whatever solution will be found will have to somehow distinguish "source only" crates from those that will be compilable as shared libraries, similarly to how C++ has header-only libraries.
It does support dynamic libs, but virtually all important Rust software seems to be written without any consideration for it.
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 executables that share most of the underlying code, and you want to save some disk space in the final install. The standard Rust toolchain builds use them for this purpose last time I checked.
Yep that’s right. I’ve been working on a game with bevy. The Bevy game engine supports being dynamic linked during development in order to keep compile times down. It works great.
People thinking C++ libraries magically solve this ABI issue is the other side of the coin. I’ve filed numerous bugs against packages precompiled libraries but misusing the C abi so that (owned) objects cross the abi barrier and end up causing heap corruption (with a segfault only if you’re lucky) and other much more subtle heisenbugs.
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.
C++ has the opposite problem where people think they can just dynamically or statically link against any api be ok. You can’t cross the ABI barrier without a) knowing it’s there, and b) respecting its rules.
You get lucky when all assets have been compiled with the same toolchain (with the same options) but will lose your mind when you have issues caused by this thing neither you nor the package authors knew existed.
the rust abi is explicitly unstable. there are community projects to bring dynamic linking, but it's mostly not worth it.
That is not correct. Dynamic linking is natively supported in Rust. How else do you make modules for scripting languages like Python (using PyO3) [1]? It uses the stable C API (cdylib).
[1] https://pyo3.rs/v0.15.1/#using-rust-from-python
RAM is cheap mmmkay?
Or at least it used to be when they designed the thing…
Is it a RAM problem though? My understanding is that each process loads the shared library in its own memory space, so it's only a ROM/HDD space problem.
If you stop using shared libraries each application will have its own copy in ram…
The problem is vulnerable dependencies and having to update hundreds of binaries when a vuln is fixed.
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?
Go definitely supports dynamic libraries
I don’t mean Dylibs like you find on macOS, I mean loading a binary lib from an arbitrary directory and being able to use it, without compiling it into the program.
It’s been some time since I looked into this so I wanted to be clear on what I meant. I’d be elated to be wrong though
Both handle that just fine. Go does this via cgo, and has for over a decade.
You do still need to write the interfacing code, but that's true for all languages.
Then by that argument Rust also supports dynamic linking. Actually it’s even better because that approach sacrifices less performance (if done well) than cgo inherently implies.
Well, Rust does support dynamic linking. It just doesn’t (yet) offer a stable ABI. So you need to either use C FFI over the dynamic linking bridge, or make sure all linked libraries are compiled with the same version of the rust compiler.
It was built to do that, yes
In any modern OS with CoW forking/paging, multiple worker processes of the same app will share code segments by default.
COW on fork has been a given for decades.
You can't COW two different libraries, even if the libraries in question share the source code text.
Not really? You just need to define the stable ABI: you do that via `[repr(C)]` and other FFI stuff that has been around since essentially the beginning. Then it handles it just fine, for both the code using a runtime library and for writing those runtime libraries.
People writing Rust generally prefer to stay within Rust though, because FFI gives up a lot of safety (normally) and is an optimization boundary (for most purposes). And those are two major reasons people choose Rust in the first place. So yeah, most code is just statically compiled in. It's easier to build (like in all languages) and is generally preferred unless there's a reason to make it dynamic.
Dynamic libraries are a dumpster fire with how they are implemented right now, and I'd really prefer everything to be statically linked. But ideally, I'd like to see exploration of a hybrid solution, where library code is tagged inside a binary, so if the OS detects that multiple applications are using the same version of a library, it's not duplicated in RAM. Such a design would also allow for libraries to be updated if absolutely necessary, either by runtime or some kind of package manager.
OSes already typically look for duplicated code pages as opportunities to dedupe. It doesn’t need to be special cases for code pages because it’ll also find runtime heap duplicates that seem to be read only (eg your JS code JIT pages shared between sites).
One challenge will be that the likelihood of two random binaries having generated the same code pages for a given source library (even if pinned to the exact source) can be limited by linker and compiler options (eg dead code stripping, optimization setting differences, LTO, PGO etc).
The benefit of sharing libraries is generally limited unless you’re using a library that nearly every binary may end up linking which has decreased in probability as the software ecosystem has gotten more varied and complex.
I believe NixOS-like "build time binding" is the answer. Especially with Rust "if it compiles, it works". Software shares code in form of libraries, but any set of installed software built against some concrete version of lib which it depends on will use this concrete version forever (until update replaces it with new builds which are built against different concrete version of lib).
The system you’re proposing wouldn’t work, because without additional effort in the compiler and linker (which AFAIK doesn’t exist) there won’t be perfectly identical pages for the same static library linked into the same executable. And once you can update them independently, you have all the drawbacks of dynamic libraries again.
Outside of embedded, this kind of reuse is a very marginal memory savings for the overall system to begin with. The key benefit of dynamic libraries for a system with gigabytes of RAM is that you can update a common dependency (e.g. OpenSSL) without redownloading every binary on your system.
Also, won't most of the lib be removed due to dead code elimination? And used code will be inlined where applicable, so nothing to dedup in reality
I wish the standard way of using shared libraries would be to ship the .so the programs want to dynamically link to alongside the program binary (using RUNPATH), instead of expecting them to exist globally (yes, I mean all shared libraries even glibc, first and foremost glibc, actually).
This way we'd have no portability issue, same benefit as with static linking except it works with glibc out of the box instead of requiring to use musl, and we could benefit from filesystem-level deduplication (with btrfs) to save disk space and memory.
What you're describing is not static linking, it's embedding a dynamically linked library in another binary.
IMHO dynamic libraries are a dumpster fire because they are often used as a method to provide external interfaces, rather then just share common code.
> And yet Rust ecosystem practically killed runtime library sharing, didn't it?
Yes, it did. We have literally millions of times as much memory as in 1970 but far less than millions of times as many good library developers, so this is probably the right tradeoff.
Static linking is still better than shipping a whole container for one app. (Which we also seem to do a lot these days!)
It still boggles my mind that Adobe Acrobat Reader is now larger than Encarta 95… Hell, it’s probably bigger than all of Windows 95!
Whole container or even chromium in electron
C++ already killed it: templated code is only instantiated where it is used, so with C++ it is a random mix of what goes into the separate shared library and what goes into the application using the library. This makes ABI compatibility incredibly fragile in practise.
And increasingly, many C++ libraries are header only, meaning they are always statically linked.
Haskell (or GHC at least) is also in a similar situation to Rust as I understand it: no stable ABI. (But I'm not an expert in Haskell, so I could be wrong.)
C is really the outlier here.
It's not just about memory. I'd like to have a stable Rust ABI to make safe plugin systems. 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 could be done today with a semi stable versionned ABI. New app builds would be able to load older libraries.
The main problem with dynamic libraries is when they're shared at the system level. That we can do away with. But they're still very useful at the app level.
> 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 by using the dylib crate type.
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.
What properties are you validating? ld.so/libdl don't give you a ton more than "these symbols were present/absent."
It's really bad for security.
I am surprised there does not exist a community fork of Brave yet that strips out all of the commercial stuff (rewards, AI, own updates), making it suitable for inclusion in the repos of mainstream free/libre Linux distros.
There is quite a lot of costs associated with running a browser (at scale). Brave is looking to offer something that does what you mention called Brave-origin.
Brendan talks about this a bit more here: https://x.com/BrendanEich/status/2006412918783619455
This is good news, but I am confused by the following:
"""
Brave Origin is:
1/ new, optional, separate build (stripped down, no telemetry/rewards/wallet/vpn/ai);
2/ free on Linux, one time buy elsewhere.
"""
So the stripped down version (at least the non-Linux one) will not be open source?
Open source software can be sold for money. For example redhat selling cds with rhel on them, for quite a big sticker price. Free if you build it yourself but you have to pay to get a ready to use version.
or figure out how to build it yourself from source. But you can count on the lazy tax - esp. for windows (as building from source on linux is likely to be much more convenient).
Maybe that's why it is free on Linux!
open-source ≠ gratis binaries
Rules that require the distribution of source code don't require the distribution of binaries.
That seems pretty reasonable proposition IMO.
As other people have mentioned you can resell open source software. I have a big box Linux distro on my shelf here.
I’d pay a monthly fee for a browser where I’m not the product anymore and it respects my privacy.
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?
You can add the same lists as in uBlock. I haven't seen any ads in years, so yes.
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).
The main reason for people repeating "uBlock Origin + Firefox is best" is because CNAME uncloaking didn't work on most Chromium browsers, even on Manifest V2. It does on Brave.
AdGuard works better simply because there's a bunch of people being paid to work on it. There's more optimization and less bugs. The UI is a whole lot more polished. Blocklists have improved syntax, and the lists themselves are updated more frequently to catch site breakage. EasyList often has breakage on their lists for months even after being reported on their Github, but reporting the same breakage to AdGuard results in the breakage being fixed in days if not hours. And they do adjacent projects like AdGuard Home (sort of a commercial Pi-Hole) too.
FWIW, big names in adblocking work for these companies too. AFAIK, FanBoy (EasyList + EasyPrivacy + his own lists) gets paid by Brave to maintain the lists. So in a way, Brave is funding adblocking for everyone :)
You can disable all of that within seconds. There's no reason for it not to be included because of that, as all the code running on the client is open-source. If distros only shipped software without commercial interests (why even..?), it'd be an unusable mess of barely maintained hobby projects.
And you should really be using https://flathub.org/en/apps/com.brave.Browser
Isn't this what Helium is doing? I have been using it as daily driver for half a year, works a charm. Only would like better 1Password integration.
Helium is based on ungoogled-chromium. It enables manifest v2 by simply reverting some code changes made by google. So, if google decides to remove manifest v2 wholly, helium will also lost its ublock original support.
Removing all manifest v2 support is also a code change that can be reverted. Of course, the larger the change, the more work it's likely to require to maintain it in the future.
You can hide bat with one click as soon as you install brave
Linux distros won't host the code for the commercial bits. It doesn't matter if you can hide it, it's the fact that it's there at all
Yet they have no issue with Mozilla?
Mozilla does not have commercial bits. They do receive money from Google to be the default search engine, and the binaries they build report telemetry, but the versions found in Linux repos often either patch out the telemetry or disable it.
Most distros have a way of installing proprietary software via enabling additional repos after install.
And you can do that if you want with Brave
For technical users who are in the know, yes. I would not recommend Brave to less-technical friends and family knowing that they would surely be duped by some dark patterns in Brave's UI/UX.
Even Firefox, which is the best we have currently, surprises us a few times a year with questionable decisions. Still, it's what I recommend to people.
It's annoying, but Brave makes it pretty easy to remove, so you only have to do it once per installation.
As far as I am concerned, this is more about Brave going through a vetting process and an independent build than only turning off annoyances.
Indeed. It's basically like trying to get them into Debian main repo. If it works, then it's truly free.
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.
thanks for the clarification. is this 45MB reduction for the whole browser? or is this 45MB per tab?
"Brave has overhauled its Rust-based adblock engine to reduce memory consumption by 75%"
This only claims that the memory usage of the adblock engine was reduced, not the total memory consumption of the browser.
I'm guessing the same kind of people who don't understand the difference between 0.002 dollars and 0.002 cents (http://verizonmath.blogspot.com/2006/12/verizon-doesnt-know-...).
I just found out Brave supports Vertical tabs, https://brave.com/blog/vertical-tabs/
I might have to try switching from FF...
A great power of Firefox are its add-ons, aren't they? Sidebery [1] has been a solid implementation of vertical tabs since a long time ago. Begore that got popular, Tree Style Tabs [2] was also a very comprehensive solution.
But nowadays, vertical tabs are native since Firefox v136 [3][4], so at least for the basics you won't need an add-on.
[1]: https://addons.mozilla.org/firefox/addon/sidebery/
[2]: https://addons.mozilla.org/firefox/addon/tree-style-tab/
[3]: https://news.ycombinator.com/item?id=41192118
[4]: https://news.ycombinator.com/item?id=43254871
Do they support nested tabs? Makes visually navigating many tabs so much easier that way.
Unfortunately not, but it does support tab grouping which I use for basically this reason.Althought you can't do a group within a group.
Not yet but it's in development (I'm a product designer at Brave). We're working through other issues with vertical tabs before we continue work on this :)
https://github.com/brave/brave-browser/issues/44345
Firefox has vertical tabs...
That's the only reason I use FF, plus the better adblocker support over Chrome and maybe some of the advanced network privacy stuff.
Adblocker support, in chrome? Does that exist still (I use FF at home with blockers and vanila chrome without extensions at work).
It does not actually support hierarchical ("tree") tabs natively yet though. They have a placeholder switch for it in the settings.
Not yet but it's in development (I'm a product designer at Brave). We're working through other issues with vertical tabs before we continue work on this :) https://github.com/brave/brave-browser/issues/44345
Firefox 136 supports vertical tabs though
[flagged]
Why is Brendan Eich a POS?
He supported proposition 8 in California in 2008 (which passed). Some view that as unforgivable, and it's the main driving force behind all subsequent controversy about Eich.
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.
The number of journalists in the US has dropped by something like 80% in the last 20 years. But sure, enjoy your ad free experience!
I hope that this is the start of developers being conscious of using resources efficiently again, especially in the browser.
The more rust gets written, the better AI will be able to write it for people... I like to be optimistic.
I think the Rust part of the headline is incidental in this case. The previous version that used more resources was also written in Rust.
This is true, but a team using rust will probably care more about resource use in general.
I do agree it's kind of a misleading headline, the real update is their use of Flatbuffers.
> I hope that this is the start of developers being conscious of using resources efficiently again, especially in the browser.
Me too.
> The more rust gets written,
Rust seems neither necessary nor sufficient for getting developers to care about memory efficiency again though.
It is not necessary in a theoretical sense, but in a practical sense developers that care about memory efficiency only have a handful of options.
If you also care about memory safety it further limits options.
>I hope that this is the start of developers being conscious of using resources efficiently again, especially in the browser.
AI may have forced the hand on this. Users will no longer be able to subsidize software performance with hardware upgrades due to the great DRAM debacle of 2026..
The adblocker was already written in Rust.
I like Brave but the only thing that keeps me from using it on mobile is the lack of extension. That's why Firefox is my daily driver on Android
I recently switched over from FF on Android to Brave. It is much faster, and although extensions are missing, it has a bunch of built in features that covered my use case: - Forced Dark mode - Ad blocking
Recently I've found Cromite and sure glad I did! Finally I've found my Kiwi browser replacement. It is also feels faster than both Firefox and Brave on Android (though YMMV).
its coming. https://x.com/brave/status/2008244198060028063
And here I am on IOS where Brave but not Firefox can use adblockers.
My fucking god I’m not sure enshittification has ever been so widely dispersed. It’s impossible to have any type of unified set up across different OS/devices currently.
Kagi's Orion on iOS is good, and supports ff/chrome extensions
Kind of, but not really, the ublock origin app doesn't work on Orion. I tried both Kagi + uBlock versus Brave and their built-in ad-block and Brave had a much better performance.
Fwiw Orion uses the actual extensions, not the uBO Lite app (for Safari) that I think you're referring to.
True, none of the extensions I tried actually worked as intended.
Is that 45 MiB per-tab? People are laughing it off, but since each tab is a process these days..
Each tab can be a dozen or more processes nowadays, thanks to site isolation.
Those may be forked copies of the main adblocker process. If so, you'll get the benefit of CoW page deduplication.
Windows (sanely) doesn’t do fork.
Shared memory obviously exists, though and they do mention in the post (missed it first time around) that they try to share Adblock resources.
Is Brave still a front for a cryptocurrency pump-and-dump scheme?
Never was.
Maybe not for crypto, but they did spend a year or two surreptitiously installing their own VPN service on your Widows machine without any opt-out ability, and then failed to remove it, its Windows service, or multiple scheduled tasks once the brave uninstaller had been run.
The best part was this whole scam sitting as an unresolved issue on GitHub for months after they finally acknowledged it (after first denying it lol).
Closest browser I’ve seen to an actual virus in maybe ever.
And it’s a good lesson for developers that once you lose trust there are many of us who will never make the same mistake again purely out principle.
plenty of other issues though:
https://news.ycombinator.com/item?id=18734999
https://www.sophos.com/en-us/blog/brave-ceo-apologises-for-a...
https://www.bleepingcomputer.com/news/security/facebook-twit...
and issues with tor (presumably fixed by now)
https://www.coindesk.com/tech/2021/02/22/brave-browser-was-e...
They could cut it 110%, so my available RAM grew bigger, and I would still not trust them. They have been caught with their hands deep in the cookie jar too many times.
Meanwhile Firefox keeps undoing its own track record. There really is no perfect solution to browsing the web these days.
Can you elaborate?
> In 2020, the company was found to be appending affiliate referral codes to the end of certain cryptocurrency exchange URLs typed into the browser's address bar. The practice applied to exchanges such as Binance and Coinbase, and was later discovered to extend to suggested search queries for terms like "bitcoin" and "ethereum".
> In 2022, Brave faced further criticism for bundling its paid virtual private network (VPN) product, Brave Firewall + VPN, into installations of its Windows browser, even for users who had not subscribed to the service
https://en.wikipedia.org/wiki/Brave_(web_browser)#Privacy
That's not how fud works
Why don't Mozilla make or use such engine in its browser? Make something really native for dealing with ads and annoyances. The irony is Brave smartly uses Rust which were forsaken by Mozilla. I know Mozilla seems to have something for ads but honestly I don't even know what it really does, beside its shield icon.
Almost all of Mozilla's money comes from Google, an ad company. Mozilla wouldn't want to bite the hand that feeds them.
Mozilla wants Firefox to be a mainstream browser that anyone can use. Ad blocking introduces the risk of site breakage, and the majority of the population don't have the knowledge to deal with it.
This is what Firefox blocks by default: https://support.mozilla.org/en-US/kb/enhanced-tracking-prote...
Because Mozilla is mostly sponsored by Google.
Because ad blocking isn't provided by default in Firefox. It isn't as opinionated as Brave, for the better and the worse.
I'm not sure how impressed I should feel about saving 45 MiB these days.
45MiB is for the default adblock setup, and it scales with the more block lists you have enabled.
I'll happily take performance improvements cause most products lack any efficiency care nowadays.
[flagged]
Adblock data is accessed on every request; so this is 45 MiB of cpu cache.
I mean unless it's a linear search through the whole list, I doubt you save that much cache.
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.
Be as impressed as you want but I think it is a very good sign that developers are taking care of it, and as this is a free to use product we can always be happy if someone boosts performance no matter how much
Very, if only because you'd have said I'm not sure how impressed I should be about saving 4.5 MB these days not all that long ago. Remember when emacs was backronymised to 'eight megabytes and constantly swapping'? That was also not all that long ago. Now 8 megabytes is what some pissant JS library takes as part of some miserable npm package used to bellyflop an ad into your browser window.
> 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.
Now multiply that across all apps/services/extensions/profiles and it adds up.
This kind of lazy thinking is why today’s software is so bloated and slow.
It adds up but it would require to rewrite all software, which would be pretty costly.
I agree with the sentiment but it's a bit too late now.
The problem is with how software is designed around being cheap to write.
It's so much cheaper to optimize now than before.
What is this based on? Could you expand on this a bit?
Just personal experience using LLMs. I've optimized a lot of things in the past year I wouldn't normally have time to do, especially build systems/pipelines.
It's just Brave browser, you don't multiply by the number of every kind of service
With your attitude towards improving one piece of software, it becomes every piece of software.
"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.
These days you’re getting 4GB at that price point and you’re losing memory to the OS thus user space memory is even more constrained.
It's more than that, because generally performance is also much worse if you're using a shit ton of memory. That's because CPUs are bottlenecked by cache. So more memory means cache has to be flushed more often, and there will be more misses, which can greatly impact performance.
Smartphone producers already announced to cut ram this year... Just FYI
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.
But they do keep the active tab of each window in memory. Firefox even continues rendering all active tabs in all windows, even if for windows which are not visible.
Not sure if this 45MB is per browser instance or per tab, but it’s the latter case, 10 windows would save 450MB. >10% on a lower-end device.
4GB of that taken by the system. more memory use with runtimes also means more cpu to track and free memory.
This kind of attitude is why everything is so bloated nowadays...
130USD for 8GB RAM will be a good price for a bare DIMM in two weeks.
I can sell you 16 GB DIMMs today for less than 2x that so that you can profit.
Very.
It's getting harder and harder to main Firefox. Brave's split tab feature is simple but so brilliant.
The Zen browser - a derivative of Firefox, also supports split tabs (and a lot of others like spaces, vertical tabs and glances). The project seems fairly active and up to date in the past few years.
Firefox has experimental split tab hidden inside about:config since 146.0 (December 9, 2025)
https://winaero.com/how-to-enable-split-view-in-firefox-146/
A decade ago there was a Firefox addon called Tile Tabs that could do any number of arbitrary splits. It died along with all the old-style XUL addons.
1. Look for a new browser instead of Firefox that also have a history of being trustworthy.
2. Look at Brave - see 1.
Why don't they put these ads behind a Bloom filter? That's a lot of memory use, even with FlatBuffers.
We used to use Bloom filters in 2019, funnily enough: https://brave.com/blog/improved-ad-blocker-performance/
Perhaps it's obvious but I'm missing some (briefly) justification why FlatBuffers was better, not Protobuf/Capnproto/...
But why not use Firefox with ublock? Brave is also chrome beneath. If google pulls the plug what is brave or other browsers anyway?
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.
The article says:
> The upgrade represents roughly 45 MB of memory savings for the Brave browser on every platform (Android, iOS and desktop) by default
Well brave still uses 300MB per tab on linux and almost 700MB per tab on Windows. So they do have a long way in front of them.
That's an absolute lie. The entire browser uses around 400MB when a single tab for news.ycombinator.com is open. The tab itself sits at around 35MB. Additional tab increases by the same amount.
https://imgur.com/a/nNA90lk
They're crushing it on ad-blocking. I love it for that reason.
Sure, but some like a trustworthy company from a trustworthy country behind the software we use. 45 MiB less isn't enough to forget the history of Brave. The hidden VPN install and adding their own affiliate links haven't been forgotten.
[dead]
Is Brave actually a good browser now? Did they rewrite it or something? Last time I looked it was a janky JavaScript mess.
The most effective ad blocker I've ever used. With that, it becomes better than chrome, in my opinion. Give it a spin, it's my daily driver for web dev as well ( just chrome debugger)
> a janky JavaScript mess.
You might be thinking of Vivaldi. Brave is certainly buggy, but it's not written in Javascript.
The project is listed as 100% JavaScript on github https://github.com/brave/brave-browser
https://github.com/brave/brave-browser
>This repository holds the build tools needed to build the Brave desktop browser for macOS, Windows, and Linux.
The web browser is here : https://github.com/brave/brave-core (8% of typescript)
It's better Chrome: no ads, faster (because no ads), some nice features on top. What's not to like?
it has a lot of sketchy telemetries
I am curious to know what was the contribution of switching to FlatBuffers in that improvement.
FlatBuffers was definitely the majority of the improvements here!
On 64-bit systems, pointers themselves can really start to take up a lot of memory (especially if you multiply them across 100k+ adblock filters). Switching to array indices instead of pointers saves a lot of memory that's otherwise wasted when you don't need to address the entire possible memory space.
Insightful. Many thanks.
Flat buffers is know to bloat client code. Was any trick used to mitigate that?
I guess code bloat is proportional to schema complexity, and performance improvement is proportional to volume, so in ad blocker with many large block lists the latter dominates.
The biggest improvement for us was deduplication by using generators an referencing already emitted objects. Don't run flatc on a JSON, it doesn't do that.
The Brave is the reasons why I can tolerate iphone )
Brave also installed a VPN an a VPN service without permission on my Windows machine, and then didn’t disable or remove 3 separate scheduled tasks in Windows Scheduler once I’d uninstalled it. The VPN issue was open for like 8+ months on GitHub too - and at first they denied doing it at all. For all I know it still installs it, but I removed this malware-type shit when this all happened so I couldn’t tell you.
I’ll never trust them again after that.
You've commented this three (?) times under this HN post and several times on this site now. Sure seems like you have a bone to pick.
The VPN they installed was disabled and they could not activate it without user interaction. And the only reason they did this is so when you click "activate VPN" in the browser, it works immediately.
On top of that, other businesses employ(ed) similar tricks. For years and years and years, Dropbox on macOS did a very specific hack to give itself more permissions to ease syncing. Hell, Firefox injected ads for Mr. Robot via a surreptitiously installed invisible extension.
Still a boneheaded move by Brave, just like adding their own affiliate link to crypto links (if none were added) to generate extra revenue for the company at no extra cost to the user. But that is even further in the past.
At any rate, they also fund or develop a bunch of anti-ad tech and research and make it open source / publish it. The defaults of Brave protect your privacy much better than Firefox's defaults. And so far, their BAT concept is the only one that is a legitimate alternative to an ad-funded internet.
Brave is everything Mozilla wishes it had become.
Minimising a browser installer surreptitiously installing an unrelated network service without my consent in the name of convenience and then pulling out a whataboutism that has nothing to do with this. Not even gonna bother reading the rest of your comment.
And yeah, my bone to pick is warning others not to fall for Brave’s slick PR. Companies that act that way can pay the price.
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 may be thinking of was at one point, when you went to a URL (for some URLs), the browser would rewrite the URL to contain their affiliate link. There was blowback for doing that. They quickly removed that/haven't done it since as far as I know
Important part missing here, they didn't tell anyone about the affiliate URL rewriting and only removed it when caught.
> the browser would rewrite the URL to contain their affiliate link
In fairness, that is incredibly shady and they deserve this mistrust even years later because of it.
> 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)
lead what? https://archive.is/W0k4j
(disclaimer: people remember how sketchy Brave is)
That was just a concept, it never made it to a live build AFAIK.
What they should have done instead is just take hundreds of millions of dollars from Google, like a non-sketchy browser.
Don't forget when they took donations on behalf of other websites and kept the money unless the operator went to the "escrow account" to collect it
The grants came from our token fund, not users' tokens (no way to buy BAT then).
The issue which I found out about late, and fixed right away, was infringing on right to publicity, nothing to do with donations from users' own tokens.
Jesus dont you see they are trying atleast an alternative to non consensual anal probes by other ad companies?
Already shared, but that (what you linked to) was a proposal and no deliverable was ever publicly released. A simple prototype was made and tested by a limited number of employees - instead of showing an ad, it would show a picture of a mustachioed man as a placeholder. That silly picture would be replaced with real code if the idea panned out. It didn't. The idea and the code was canned before I joined Brave and I've been here for almost 10 years (I joined August 2016).
Disclaimer in case it's not obvious: I am a Brave employee
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]
Wild accusations considering this stuff still exists online as direct evidence: https://brave.com/blog/binance/
Also attacking the person instead of the ideas is really not in the spirit of HN.
That blog post is about a partnership (which ended), but you probably saw some sponsored images at the time, in new tab pages (1 of 4 then, I think; the rest are just art images).
These are non-tracking, carefully designed (including vetting by Brave), brand advertising images. They are not ads (we never did this) inserted into publisher pages, or (opt-in only) push notifications.
Brave has been working to find ways to sustain ourselves, and these sponsored images are still a good revenue line, although lesser now vs other lines. If you want, turn them off.
Free riding is always an user right, we don't try to stop it on principle, as if we ever could with open source. But there's no free lunch: if you use Firefox, you are Google's product. If you use a Firefox fork, you're free riding on Gecko which costs a lot to maintain. HTH
“Sponsored images”
What exactly do you think an advertisement is?
It's incredible how people can hallucinate nonsense like this out of nothing, simply because their hatred for Brendan Eich drives them insane.
Maybe what GP remember is the VPN they secretly installed, the affiliate links they silently added, the donations they took for other companies and kept for themselves, or one of the other times Brave was caught. It is a wonder people think the code base is trustworthy when we know for a fact how they behave with stuff we can see. But sure, try to make it look like it has anything to do with a person hardly anyone have ever heard of.
With the number of times the above lie has been repeated and corrected, virtually every single Brave thread for several years straight now, I am inclined to think it's actually maliciousness which is motivating people to continue posting it.
This never happened.
[flagged]