It astounds me that a company valued in the hundreds-of-billions-of-dollars has written this. One of the following must be true:
1. They actually believed latency reduction was worth compromising output quality for sessions that have already been long idle. Moreover, they thought doing so was better than showing a loading indicator or some other means of communicating to the user that context is being loaded.
2. What I suspect actually happened: they wanted to cost-reduce idle sessions to the bare minimum, and "latency" is a convenient-enough excuse to pass muster in a blog post explaining a resulting bug.
It's very weird that they frame caching as "latency reduction" when it comes to a cloud service. I mean, yes, technically it reduces latency, but more importantly it reduces cost. Sometimes it's more than 80% of the total cost.
I'm sure most companies and customers will consider compromising quality for 80% cost reduction. If they just be honest they'll be fine.
what's even more amazing is it took them two weeks to fix what must have been a pretty obvious bug, especially given who they are and what they are selling.
These vulnerabilities are all caught by scanners and the packages are taken down 2-3 hours after going live. Nothing needs to take 7 days, that's just a recommendation. But maybe all packages should be scanned, which apparently only takes a couple of hours, before going live to users?
Cooldowns are passing the buck. These are all caught with security scanning tools, and AI is probably going to be better at this than people going forward, so just turn on the cooldowns server-side. Package updates go into a "quarantine" queue until they are scanned. Only after scanning do they go live.
"Just" is doing a lot of work; most ecosystems are not set up or equipped to do this kind of server-side queuing in 2026. That's not to say that we shouldn't do this, but nobody has committed the value (in monetary and engineering terms) to realizing it. Perhaps someone should.
By contrast, a client-side cooldown doesn't require very much ecosystem or index coordination.
I think the rest of your analysis is correct! I'm only pushing back on perceptions that we can get there trivially; I think people often (for understandable reasons) discount the social and technical problems that actually dominate modernization efforts in open source packaging.
The approach you outline is totally compatible with an additional one or two day time gate for the artifact mirrors that back prod builds. Deploy in locked-down non-prod environments with strong monitoring after the scans pass, wait a few days for prod, and publicly report whatever you find, and you're now "doing your part" in real-time while still accounting for the fallibility of your automated tools.
There's risk there of a monoculture categorically missing some threats if everyone is using the same scanners. But I still think that approach is basically pro-social even if it involves a "cooldown".
I agree, even without project glasswing (that Microsoft is part of) even with cheaper models, and Microsoft's compute (Azure, OpenAI collaboration), it makes no sense that private companies needs to scan new package releases and find malware before npm does. I'm sure they have some reason for it (people rely on packages to be immediately available on npm, and the real use case of patching a zero day CVE quickly), but until this is fixed fundamentally, I'd say the default should be a cooldown (either serverside or not) and you'll need to opt in to get the current behavior. This might takes years of deprecation though, I'm sure it was turned on now, a lot of things would break. (e.g. every CVE public disclosure will also have to wait that additional cooldown... and if Anthropic are not lying, we are bound for a tsunami of patched CVEs soon...)
There are so many ways to self-host package repos that "immediate availability" to the wider npm-using public is a non-issue.
Exceptions to quarantine rules just invites attackers to mark malicious updates as security patches.
If every kind of breakage, including security bugs, results in a 2-3 hour wait to ship the fix, maybe that would teach folks to be more careful with their release process. Public software releases really should not be a thing to automate away; there needs to be a human pushing the button, ideally attested with a hardware security key.
If I am reading this right, your understanding is incorrect. Signal's "new messages" push message payload is empty. Upon receiving a message of this type, the Signal app wakes up, fetches the actual messages, and (optionally) displays local notifications for them.
At no point does the push message payload contain message text or metadata, encrypted or not.
There's some nuance here. If you care about fuel consumption or emissions, then EFI is the current best way to reduce both, and that requires "computers and software" to operate on the timescales required. I put scare quotes around those terms because you can do EFI on an Arduino, which is at least an order of magnitude more powerful than what automakers shipped in the 80s.
In any case, EFI gives you more control over the engine and vastly simplifies the overall product. I don't know if you've seen the mechanical fuel-injection pumps used by tractor diesels; they are basically tiny engines unto themselves, with their own little block and camshaft [0]. There is an entire world of diesel performance modding with a subset of it dedicated to modifying the Bosh P1700 mechanical fuel-injection pump to change timings, handle higher RPMs, and run higher pressures. I would not call it, or its carburetor cousin in the gasoline world, "simple" compared to computer-controlled fuel delivery.
An open-source ECU project, on the other hand, enabled a hacker to implement Koenigsegg's Freevalve tech on a Miata [1].
AZ/NM have highly concentrated populations, so I would expect to see only a couple of hexagons over Phoenix and Albuquerque. Texas looking like that is pretty bad, but I suspect this has more to do with the data set.
I would expect Texans to independently go for solar, given the... complications of their power market.
If we're talking Dyson spheres, this is like going from a half-marathon to running the distance from Earth to Betelgeuse. It's just not a realistic endeavor.
I did use an LLM to workshop my comms; I tend to go on and on so I put my my comments through a LLM to clean up my replies. the opinions and the project are mine, but the polish isn't. I'll knock it off for the rest of this thread.
1. They actually believed latency reduction was worth compromising output quality for sessions that have already been long idle. Moreover, they thought doing so was better than showing a loading indicator or some other means of communicating to the user that context is being loaded.
2. What I suspect actually happened: they wanted to cost-reduce idle sessions to the bare minimum, and "latency" is a convenient-enough excuse to pass muster in a blog post explaining a resulting bug.
reply