81–90 of 289 posts
Earlier quoted context omitted.
> Or does it still replace them with ads for scanmy cryptocurrency? Brave never did that. Brave blocks third-party ads & trackers by default. (disclaimer: I lead privacy and adblocking at Brave)
lead what? https://archive.is/W0k4j (disclaimer: people remember how sketchy Brave is)
Earlier quoted context omitted.
I think the broader point being made here is that the C-style approach is to extract a minimal subset of the dependency and tightly review it and integrate it into your code. The Rust/Python approach is to use cargo/pip and treat the dependency as a black box outside your project.
Advocates of the C approach often gloss over the increased maintenance burden, especially when it comes to security issues. In essence, you’re signing up to maintain a limited fork & watch for CVEs separately from upstream. So it's ultimately a trade off rather than a strictly superior solution. Also, nothing in Rust prevents you from doing the same thing. In fact, I would argue that Cargo makes this process easier.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
Supply-chain attacks aren't really a property of the dependency management system Not having a dependency management system isn't a solution to supply chain attacks, auditing your dependencies is
> auditing your dependencies is How do you do that practically? Do you read the source of every single package before doing a `brew update` or `npm update`? What if these sources include binary packages? The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 Can anyone even review it in a month? And they publish a new update weekly.
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.
Earlier quoted context omitted.
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"
Earlier quoted context omitted.
> 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…
> 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.
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."
Earlier quoted context omitted.
> 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."
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.
Earlier quoted context omitted.
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"