insanitybit

> 'with enough eyes all bugs are shallow'

This was always nonsense. It assumes that the eyes know what they're looking at. Most people don't know how to look at code and see attack paths.

I think the wording in this title is too strong. MicroVMs like Firecracker have stood up to agents, as noted.

Rust is not 1.5-4x slower at all. Git is not IO bound at all, it is not saturating your IO device, it just performs IO a lot.

Just use TLS / mTLS over the tunnel, no?

As someone building a language with an LLM, it is exactly an exploration of curiosity. I have a lot of ideas, I don't always know how to implement them, and I certainly lack the time. The LLM can write the code, I can guide it, and I can learn what does or does not work.

I agree, but I think most people actually don't think that's true when it comes to services that primarily do IO.

At work we're moving almost everything to Rust on our backend. Massively reduced memory usage and significant latency improvements relative to our Typescript codebase. Even for code that you'd expect to work well in TS, a near 1 to 1 port to Rust has considerably improved our best case and, in particular, our worst case latencies. And the memory we get back is huge, we may even drop our instance size down with the 800MB of RAM we're likely going to save.

Once a day I see a comment somewhere on the internet and go "Yes, perfect, this is the dumbest thing I'll read today. Great, that's out of the way". This is the one today!

Because Javascript theoretically can't just access files on disk. Control over the render would let you do that, if not for the process level sandbox, which constraints things like file access, system, calls, etc.

But the process is still more capable than the VM. The process can talk to other processes via IPC, for example.

That's why you don't go from "javascript -> computer is taken over", instead you go from "javascript -> renderer control -> computer is taken over".

I would assume in this case that there's full renderer control, not just a bypass of the in-process isolation.

> Could they have added a "no internet access" goal constraint?

They could have blocked network access and required that it use a tool. That would have made limiting and monitoring network access even easier.

I don't agree, although it is likely the case. But even if you don't teach an agent about a sandbox bypass, it doesn't matter. Does it know curl? Does it know DNS? Does it know proxying? Then it knows how to pull this off, and it doesn't even need to understand that it's "bypassing" because it thinks it's just iterating towards its goal.

In fact, I wonder if teaching it "this is a bypass" would help it to model when it's doing its job vs working around the job.

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.