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

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.

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/

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

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)

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.

> Build scripts communicate with Cargo by printing to stdout.

Oh lord.

Geez, thank you.

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.

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.

the rust abi is explicitly unstable. there are community projects to bring dynamic linking, but it's mostly not worth it.

RAM is cheap mmmkay?

Or at least it used to be when they designed the thing…

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

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

Whole container or even chromium in electron

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

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

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

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.

And you can do that if you want with Brave

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.

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 just Brave browser, you don't multiply by the number of every kind of service

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

I can sell you 16 GB DIMMs today for less than 2x that so that you can profit.

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?

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.