insanitybit

I doubt there are many things in this universe that are unambiguously good, but Chrome's sandboxing is certainly as close as anything.

You can make your arguments about noscript if you'd like (I have a great respect for the project) but I think it was essentially irrelevant to user security at the time, real users were really harmed by malware that exploited Firefox, Java, and Flash, and Chrome killed every one of those attack paths in virtually no time at all.

Computers were far more dangerous before Chrome. You watch old TV shows and it's a joke that people would visit a site and get hacked - that's unrecognizable today, it simply doesn't happen. It used to, Chrome changed that.

The reality is that Chrome users still have sufficient ad blocking so as to not be impacted by this. What will be interesting is if it stops being sufficient, at which point I think people will migrate. But until then, why would they? Most people don't really care if their extension is MV2 or MV3, they just want their youtube video to play faster.

No need to be revisionist. Chrome brought amazing work to the table. The multiprocess, sandboxed system was incredible - it's not to say that Chrome was the first (IE did it earlier) but it was certainly way ahead of Firefox for a long time. Chrome is the reason we have Seccomp V2 on Linux. Chrome made "software is always up to date" the standard. Before Chrome, Blackhole and PoisonIvy absolutely ruined people's computers - click to play Java, click to play and sandboxed Flash, etc, were massive improvements to every day user security, probably some of the biggest security improvements to computers in my lifetime.

Firefox took a long time to catch up and their CEO was utterly incompetent, which seriously harmed Mozilla.

Yes, undoubtedly. Anyone in denial of this should be legally barred from programming.

Who cares what mojo handles? This is about Zig and memory safety.

I haven't needed `unsafe` for performance since crates like zerocopy etc exist. It's been years, and I've worked hard to shave nanoseconds off of code, using valgrind to measure single digit changes to branch predictions.

2026 and developers still use memory unsafe languages. I hope we get regulated at this point, disgusting.

Sweet, okay so we're on the same page and the culture is still alive.

I'm not sure what you're saying, or how it is not what I'm saying? You're giving examples of places to read documentation, and I'm saying that the expectation was that behaviors caused by not checking documentation would be your fault. If that isn't your experience, cool, it was definitely mine when posting on forums online 15-16 years ago.

> That not knowing your API to the core makes you a bad programmer.

Seriously, this was a huge thing in C and C++, where you had to know/remember/know to look up very specific error codes and conditions in an API and if you didn't then it was very much considered to be a skill issue. This was maybe 15 years ago.

> With AI people aren't reading, writing, or thinking about the code.

Writing, definitely. Reading, maybe. Thinking is another thing. I can think about code in a lot of ways just by reading a description of the code, or knowing how I directed the code to be written, etc. I think people are thinking about the code differently.

Contracts are not a "reinvented" form of copyright. This isn't even uncommon.

There is no price to pay on the type system that was imposed by tokio. I assume you're saying something like "I have to add 'static in generics" or something?

It has absolutely paid off, there are many people not using tokio.

You would only have to include it if the library uses `spawn`, as far as I am aware, or some tokio specific type, which is the same as any other library.

This is surprisingly common, from what I can tell.

If someone asked me what a DB is, I'd probably start the conversation with the exact description "a file-backed map, like a hashmap".

The same reason as ever. Not everyone wants to use the same runtime.

At one point I was using TLA+ but it just made the problem "is the spec right?" or "does the code match the spec?". I could ensure that the properties defined in the spec were valid, but that didn't seem to translate into confidence that my code was correct. Maybe I was holding it wrong, it was just an experiment in an area I'm unfamiliar with.

Ultimately I have stuck to the informal verification of defining my expectations and ensuring that tests cover them.

> Can it be fully hands-off? No. But I think, as will all things, their both subject to the rise of the "technician"s. A mechanic doesn't change your brakes or flush your oil, a technician does. You don't see a doctor, you see a nurse practitioner and an MD just signs off. All the work that used to be done by someone with schooling to learn how to do it is just done by a technician that learned how to use the tools without the critical thinking of the expert, but with an expert somewhere available if needed.

This already describes how CEOs work though. CEOs aren't experts in every part of the company, they sign off on things and delegate, and manage communications etc. There's very little additional room to delegate because the role already is extremely delegation heavy.

Having been an engineer and then a founder (and CEO), neither can be automated. Both require organizational work to be effective, and developer productivity is so profitable in an outsized way that you'd always just hire more if you could, even if they were all 10x as productive (maybe this changes at some scale).

I'd have loved for an AI to assist with a few things as a CEO but we would have probably just shipped faster and it would have created even more pressure for board communication, customer calls, design partnerships, legal discussions, compliance, etc.

The idea that AI is coming after leadership is truly laughable. The idea that it's coming after some engineering jobs is a bit more likely to me, but I think many will actually be more valuable.

Yeah fair enough.

Looks extraordinarily unergonomic and I don't get why I would need a number pad as a developer.

I've explained myself gratuitously at this point.

> Browsers have been sandboxing their tabs since 2008.

Yes, it's an amazing feat that has cost billions and led to major features like seccomp v2, ptrace sandboxing, etc. Do you know the history of browser sandboxing? It's pretty complex, a major technical feat.

> Don't sit there and tell me that bwrap, sandboxing, whatever is some kind of recent innovation with uneven distro support.

I can tell you that unprivileged sandboxing is not only new, it's ongoing and nascent work and not commonplace at all.

> And yes, bwrap needs root or namespaces. So what? So does sudo. Setuid binaries are as old as time.

These are massive footguns and issues for deploying code... You don't get that? Again, implementations have tradeoffs.

> You know what's also been around and doesn't require root? Landlock.

lol it is SO NEW what the fuck dude?

> Have you heard of it? Has anyone?

Yes, I use it!

> "Oh, the technology works, but it need setup! Oh, my distro doesn't enable it! Oh, it doesn't work out of the box with my code!"

> This is a social problem.

Yeah these sound like social problems if you have literally no idea what you're talking about lmfao. IT's BOTH.

Your ignorance is blatant and your position is dead in the water.

> The technology works fine if you use it in a disciplined way.

Then obviously we have to discuss the implementation!

> Or just invoking bwrap. Or sandbox-execute. There's no performance overhead. Complexity is minimal. Just read current Codex source code. It's not so bad. People have been making these sandbox tools for AI agents for years. Just need to apply sandboxing to all domains.

Tools like bwrap literally could not have existed until very recently without also requiring suid/ privileges, and even today unprivileged user namespaces are not universally enabled. This is why the implementation matters. No, unprivileged sandboxing has not been around for years, especially not x-plat. bwrap is a perfect example of what I'm talking about, great reference - it either requires root or it requires unprivileged user namespaces and it's not x-plat. Great.

> You want some kind of silver bullet that makes code "safe" without anyone having to change anything? To prompt for nothing? To use no IPC portal? That's not happening.

I have no idea why you think I've said this, I'm pointing out that the implementation and technology matters deeply.

> The people saying we need a new language or something are half right. We don't need a new language. A pure library solution is fine! But people do need to do work to make an ecosystem based on capabilities and least privilege to work. And we need to tell people who refuse to do this work to go to hell.

Again, you can't say "this technology has existed for years! You can do it in a library!" and then say "but they don't!". You misunderstand the complexity and assert that it's merely a matter of will. It is both.

You can't simultaneously say that we've had the tech for years and also say that it doesn't work. We have not had the tech for years. x-plat sandboxing is extremely difficult, especially in a way that's performant.

Sandboxing almost always involves having a dedicated, privileged service, due to how operating systems have designed things. It requires platform specific code.

This is a technical problem and a social problem, there's zero reason to believe it's just one.

Total nonsense. Python has a massive stdlib and there are malicious packages.

If it weren't a registry it would be ./configure scripts and makefiles. The issue is that sandboxing technology is kinda shit (especially x-plat) and languages don't build it in by default.

It would be more than a minor inconvenience. I can handle sandboxing my tests and production infra, but I can't handle sandboxing build scripts because I don't own that code in any sense.

The technical mechanism is exactly the issue to figure out, there's a reason why projects don't have this and it's because different implementations have different tradeoffs.