insanitybit

Because that's legally the case? I don't understand the question. Using a lossy compression algorithm on an image does not remove its copyright protection.

It is presumably against their ToS.

I don't know that this really challenges anything relating to compression.

In the case of writing to the DOM, that means you use .innerText rather than .innerHTML.

This is even enforceable with Trusted Types.

Is that relevant? I can use a lossy compression algorithm such that the original could never be recovered from the image I've produced, but that derived image would surely be under copyright.

LLMs are obviously capable of producing "exact" phrases as well. Ask it to give you famous quotes, it can do it. Ask it to read a paper for you and cite it, it can do it.

I think people forget that laws are perfectly capable of carving out exceptions, leaving purposeful ambiguity, expressing intent, etc. Yes, humans can have special rules, and very obviously should since laws exist to improve human lives.

You can solve this with refinement types. It's entirely tractable in many systems in principle - APIs can be written to be safe, you can track data as separate from code, etc. None of this exists in an agent - you can't separate data from code, it's intractable because it's impossible in principle.

Escaping inputs is at least somewhat tractable. It's unclear if alignment is.

In every single case you've mentioned you're going to have a campaign with an attempt at attribution. Certainly youtube sponsors all use direct attribution with "use my code" etc.

In every one of those cases you can at least do things like count viewers. How would that work for a model that's just subtly biased?

That would probably be effective but also very hard to monetize. Right now an ad translates to money very directly - views, clicks, signups, etc. How would "we mindfucked you over 6 months into buying this brand of soap" get monetized?

What people are missing is that these aren't vulnerabilities. The reason you see this is because Greg does not believe in the CVE system. As an act of rebellion, the Linux kernel (a) assigns CVEs to fixes and not bugs, (b) assigns them gratuitously to DoS the system.

This is just Greg being a baby. Linux has to be removed as a CNA ASAP, it was a terrible idea to ever grant them that power.

This has nothing to do with AI or even security.

I think one of the few performance benefits with a GC is that you can defer allocations. You can do that in Rust too though.

I think this is interesting and warrants explanation. There are cases where a GC can be faster (sort of, Arenas get you most of the gains) but "the most sophisticated scheduling engine in the world" should be easy to at least partially support.

Rust's compile times will get faster long before Zig gets safer.

Anthropic thinks Claude is a super genius hyper-serious weapons-grade product so it's no surprise that Claude acts like it.

My theory is that Anthropic's obsession with treating Claude like a person is causing them to hamfist a personality into the thing, which overly biases the model towards trying to be "engaging" etc. That and the obsession with Claude being a god tier weapon that could end the world if you ask it whether your sandwich is safe to eat after being left out for an hour.

Codex doesn't have any of the annoying "personality" quirks, or at least they haven't gotten worse in the last year whereas Opus 4.6 was the last Anthropic model before things started to get actively worse (not any better at coding, strictly more annoying to have a discussion with).

What would a solution to this look like?

Sandboxing and auditing built into the software from the start. Browser Extensions solved this ages ago.

Every major package manager is just as fucked.

So what?

What a state of things where we have to fear installing software, and rely on vendors to scan things ahead of time, because our supply chain is such a mess and our tooling is so incapable of (and uninterested in) protecting us.

If you are thinking of AI fixing bugs is less expensive

Because I don't think this. A rewrite is cheaper to me.

There are a million ways to load a kernel module from inside of a container into the host kernel (ie: to trigger a load), but seccomp/ linux caps will block the direct ways (as another commenter notes).

That's right. Docker still runs without user namespaces by default, which means that root is the same user inside and outside of the container. This does open up attack surface and configuration footguns.

Confinement still leverages dropping some root caps, seccomp, various other namespaces, etc.

I don't think this would change anything even if it were true, which it is not. Running as root in a container opens up tons of footguns but it is not a path out of the container on its own.

They are a security boundary. The fact that you need a vulnerability to escape them is proof of that. They just don't have a particularly high cost of escape because reachable kernel vulnerabilities are so common.

My claim is that you can grep for memory safety bugs in rust and you can't in zig, therefor trading memory unsafe zig bugs for memory unsafe rust bugs is a good trade. This has been my claim, it continues to be my claim. Linking to the nomicon won't change anything just like linking to the other blog post changed nothing (and you literally misunderstood the other blog post, and I even pointed you to the errata of that post).

Not these in particular. You are again ignoring the context.

What context? I just said afterwards that aliasing is not one of those cases.

Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:

Nope and your post wouldn't justify the statement. Not all UB leads to a reachable bug. The blog post doesn't say otherwise, and in fact it indicates exactly this (that UB can compile "correctly" one day and "incorrectly" the next). Check the errata on the post.

Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".

No, I'm right other than l-unsound. Saying "but safe code that references unsafe code" doesn't change that.

It's as hard as rewriting the codebase from ground up without reference

Not necessarily. At least multiple cases I've seen in the rewrite would be a matter of just moving `unsafe` from one spot to another and then placing the assertions at the caller.

This conversation is increasingly dumb. I've made my point repeatedly - moving to Rust means memory unsafety violations can be grepped for and that's not up for debate. You can say that that's not sufficient as a win for the project, I really am ambivalent.

There are no such invariants in Zig.

Zig does have invariants. It doesn't have an aliasing invariant like rust though, but it does have its own invariants, naturally. Zig is a memory unsafe language.

Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".

A reachable bug means one that can be triggered. Undefined behavior does not mean a bug can be triggered.

There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.

Can be, yes.

Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools

This is only possible if unsafe is used. `unsafe` is grep'able, hence all memory safety bugs are grep'able. That's the whole point of rust.

You can grep for every memory safety violation in rust.

I've had zero issues with Codex. If it flags something it seems to have a slower "review before proceeding" phase but it does proceed.