Yep, this is the thesis behind them. I wish people engaged more fully with this argument: it’s possible to believe that security vendors won’t do a good job of upholding their side of the bargain, but I’ve yet to see anybody argue that rather than making a faulty universalization argument against cooldowns.

If this is the idea, why don't we let the dedicated security firms and/or automated scanners find the vulnerabilities before the release?

You need an early release in the "given enough eyeballs all bugs are shallow" world because you need the eyeballs, but if you count on specialists and scanners no general availability release is necessary and hence no cool down.

The idea that a package can be updated and with a deploy at the right time could be live on your servers in prod 10 minutes later has always been crazy, and the last years have just reinforced that.

People are encouraged by package managers to treat any bit of code someone tosses onto a package manager as equivalent in reliability to the core language and sdk.

Using dependency cooldowns is not a free-rider problem. There's a real tradeoff here – ppl are trading their time preference for security.

Just as users are incentivized to avoid malware, researchers and attackers are equally motivated to be the first to discover it.

The concern trolling around widespread dependency cooldowns doesn't make sense. Most people shouldn't be eager to download a release that hasn't made its way through at least some scans.

This is how a chunk of people function anyway. There are plenty of people that choose to not install "point zero" release for software of a certain importance, assuming with any major changes there are often bugs that come along with it.

In this case, since the number of cool down days is configurable, even if everyone was using it we would still likely see a somewhat smooth curve for adoption, since not everyone will choose the same delay and the delay time will likely map closely to how people want to habdke risk.

It's all a trade off, just like it's always been. This just makes it simpler to act on what you want your risk/comfort level to be.

> It basically devolves into a Volunteer’s Dilemma. There’s no incentive here to be the guinea pig, so nobody will want to be.

Except there is lots to gain from being the first to write about the new malware on some registry, so companies are actively downloading and inspecting literally every package.

Back in the day (maybe 6-7 years ago?) you could detect this by uploading a new npm package that hit back some endpoint in your control, and it was almost guaranteed that this endpoint got a request within a minute of publishing a new package or update to existing one with users. Nowadays I think none of the scanners actually run the code, mostly static-analysis, and I dunno how often the npm download counter updates per day, probably harder to see in real-time.