Shellshock was in 2014 and Log4Shell was 2021. It's far more likely that you're going to get pwned by using a too-recent unreviewed malicious package than to be unknowingly missing a security update that keeps you vulnerable to easy RCEs. And if such a big RCE vuln happens again, you're likely to hear about it and you can whitelist the update.
They are. The leak is that if a webpage you visit creates several databases with certain names, the order is random but stays the same within the same browser session.
It's the mapping of UUIDs to databases that is shared across origins in the browser. Only the subset of databases associated with an origin are exposed to that origin.
If you want to dynamically create sqlite databases, then moving to durable objects which are each backed by an sqlite database seems to be the way to go currently.
And now you've put everything on the equivalent of a single NodeJS process running on a tiny VM. Next step: spread out over multiple durable objects but that means implementing a sharding logic. Complexity escalates very fast once you leave toy project territory.
Calling on JD Vance and Elon as if they're known for a principled respect for free speech is crazy. It just reads as unnecessary propaganda or a poorly-disguised threat from powerful friends. I'm generally inclined to agree with Cloudflare here and the post makes me question that.
Adam Back is the well-off CEO of a company in the blockchain space. From that position, he gets to continue to use his expertise in the field with plenty of connections while having more than enough money without needing to risk revealing himself as Satoshi or risk de-stabilizing Bitcoin's value by using Satoshi's known wallets. It seems like the best possible outcome for someone in Satoshi's position.
I'll at least agree that I don't think any other living candidates for Satoshi make any sense. I can't believe someone who started a brand new influential field of study could fully exit from it while fully avoiding the proceeds from it, as would be necessary to believe in any other living candidate.
When I was a kid, I released a small GUI program online that I made with either VB6 or VB.NET. The program used the standard open-file dialog. When I created the installer for my program through VB's release wizard, there was a page where it pointed out that my program depended on a certain system library (because of the open-file dialog) and it asked me if I wanted to include that library in the installer. I think the default answer was yes, or maybe it wasn't but it sounded like an obvious thing to enable so I did it. Apparently this screwed over and broke open-file dialogs globally across Windows for everyone who wasn't on the same version of Windows as me. Whoops! It's too bad that VB had such a foot-gun in it, and that the article's workaround didn't save those users.
The shared /tmp/ directory that can be used by processes of multiple users seems extremely prone to causing this type of issue. I wish there was a common convention for user-specific temp directories on Linux, because a whole class of vulnerabilities could go away.
MacOS handles this great by setting $TMPDIR to some /var/folders/.../ directory that's specific to the current user. Linux does have something similar with $XDG_RUNTIME_DIR (generally /run/user/$UID/), though it's stored in memory only which is a little different from usual for /tmp/, seemingly mainly intended for small stuff like unix sockets.
reply