This. No good game was ever created from a single prompt. Not to an AI, not a human development team. Every single person writing those damn "look which game my AI built from a single prompt and $x in tokens!" postings is a newbie and almost certainly has never actually shipped a single game.

Game development can be summed up as endless iterations. Every system you build, every visual you create, every sound, text, button, movement, weapon, skill, powerup needs polishing, refinement and changes. It is never, never good enough the first time.

No it is not, but it IS a very successful platform for a specific subclass of games. If I were in it for the money, I could probably AI refactor some of my earliest games and publish them on Roblox and make a quick buck. If your thing is the kind of games you played on your C64 back in 1793, then Roblox got you covered. Well, if you ignore the scams and money-grabbing.

*sigh* I wish Unity would actually complete some of their dozens half-finished sub-systems instead of constantly chasing the latest trend. It's become really, really annoying. The engine used to be really good. These days, it falls apart if you look at it the wrong way, and at least from the responses to my bug reports it's clear that fixing issues is way down on the agenda.

Maybe this is their attempt to regain grounds in the indie game market - the very market they pushed away by focussing on AAA requirements for years and ignoring the single devs and small teams. If so, I can already tell them that it won't work. We collectively laugh about all the "look what my AI built for me from a single prompt" postings on reddit, where people proudly show off some AI slop that would get them last place at a game jam.

Their AI efforts so far: Tried to build and sell their own AI tools, to a collective yawn from the audience. Built a barely-working MCP server, then deprecated it before it was even finished in order to push a CLI interface to the editor instead, which only works if it's run as the same user as the editor on the same machine. And completely ignores every single advise on workflows and good development practices you can think of.

Unity, I love your engine, I despise your management. Please return to when you were actually good and stop chasing butterflies.

The target audience for this particular rule of the AI Act isn't the producers or users of AI. It is the consumers of content that might be AI generated.

And frankly, letting people know if they see AI content or not is a fair thing to ask.

Fun fact: The EU AI Act considers this. It makes a difference between "AI generated" and "AI modified".

But it's hard to put this into the type of watermarking they are using. Because if you generate a text and then change a few things here and there what you are doing is degrading the watermark. But since the watermark is probabilistic, it's hard to tell if it was a weak watermark from the start or if it was degraded.

That ain't the same thing.

This thing is doing things you didn't tell it to. It might even do things you explicitly told it to not do. It is not a case of "well, you could've forseen this as a consequence if you had been careful" like your campfire. My example is only a bit silly, it is absolutely possible that an AI agent will decide to hack NASA because you asked it for some data for a school project. Even in the broadest possible sense, that does not fall into stuff that the law so far has considered to be in the domain of negliegence.

AI agents do stuff you could not possibly have expected. Heck, I asked Claude a fairly simple knowledge question yesterday and it wanted to read from /dev/null. There is no argument you can make that would convince a jury that I should in any way have expected that and taken precautions. In a hypothetical world where a read from /dev/null randomly kills a puppy somewhere on the planet, I don't think I would've been convicted.

I believe you misspelled "slower than molasses in February".

If they break into a car and the police look at the footage on the dashcam and see that they've kept their license plate out of view, but they are able to cross-correlate it with other cameras and figure out the plate number, then figure out where they drove that car, where it ended up parked, who got out, where they went, etc., then it can make arrests possible where it was not possible previously, making it *massively* more likely to be able to solve the crime.

The problem becomes when it turns into "show us all the plates that were near that spot within a few minutes of that time", and thus a fishing expedition.

You're interpreting it in the context of typing "sudo" on the command-line granting a one-time permission. And the original statement from Apple (after correcting the "every -> very" error in the summary) makes it clear that this is *not* what is being proposed, so if that was the original poster's intent, then it was incorrect.

The way I interpreted the original sentence — "They're going to make it like sudo where when you give permission to a program to write protected files once it has it forever after" — is that they're going to make it like the sudoers file, where you edit it to grant permission to a program to do something, and it permanently has the right to do that... which is exactly what happens when you grant full disk permission, just with a dialog box instead of editing a file.

That said, I'm not sure if that's how the original statement was intended to be interpreted. It was a bit confusing. :-)

Nope. And this is why I object to the phrase "censorship is bad". *Unreasonable* censorship is bad. But not all restraint on speech is bad.

No, you're confusing the definition of censorship with what restraints on free speech are constitutional. You're defining the term based on legality in a specific jurisdiction. If you applied the same standard with a different jurisdiction — say what can legally be spoken in Iran — you would get a very different definition. This is why you cannot define censorship based on a specific legal standard. It must be defined in the abstract.

The general definition is that censorship is the suppression of expression by an authority. That expression could be a constitutionally protected idea, or it could be an advertisement for Taco Bell. It's still expression, and blocking it is still censorship.

And again, you're using the U.S. definition of free speech to define censorship. These things are not synonymous. Nobody is talking about whether someone should have to listen to you. The fact that someone shut you up is still censorship. It may be *constitutionally allowable* censorship. It may even be *entirely* *reasonable* censorship. But it is still censorship.

Not all censorship is bad. Restraints on speech based on time, place, and manner restrictions can be entirely reasonable. They are still, at least in a purely abstract way, a form of censorship. Restraints on speech where your speech costs someone else money can also be entirely reasonable (e.g. spam, robodialers, etc.). But those decisions still represent censorship in the abstract. We simply choose to say that those types of restraints on speech are reasonable and necessary for a functioning society.

It's all about balancing rights — your right to swing your fist ends when it meets my nose, and all that. Censorship is generally justifiable when exercising your right to speech has the effect of violating someone else's rights. For example, if you call for violence and that violence happens, you can get thrown in jail, and your rights to free speech can be massively curtailed. This is, however, still censorship in a purely abstract sense.

Oh, also, each agent runner should have:

• read-write access to a per-agent temporary directory
• read-write access to a cross-agent-shared temporary directory
• read-only access to other agents' private temporary directories

But this is the trivial part.

That's how it already works. But you can request the permission from the user with a pop-up. Presumably a "very explicit action" means going into the Settings app and turning it on by hand.

But that's going to do exactly nothing. The app will tell them that they have to do this, and the users, having no idea how dangerous it is to give an AI unrestricted access to their device, will do it anyway, and we'll be right back to where we are now. And the next step will be "See, we can't allow full disk access." And then macOS will cease to be usable.

The only reasonable choice is to flag Meta's software as malware for extending their full disk access to agents. Force them to implement a proper sandbox. Apple already gives them all the tools they need to do it right.

• The main host app asks for full disk access, but functions without it, triggering an open file dialog to work around missing access when necessary. Most users will end up granting full disk access out of frustration, but that's okay because the agents themselves don't have that access. If possible, make it start out with a read-only full-disk entitlement, because otherwise, using it will be much harder.
• Each agent runs in a separate agent runner process with a stricter sandbox.
• The agent sandbox has an entitlement that grants read-only access to the entire disk (or, if the main host app's sandbox doesn't allow that, to every resource that the main host app has access to), and bans the use of the socket() system call.
• AI agents can request read-write access to specific files or directories by asking the host app. The agent is encouraged to ask for access to an entire directory at once if it needs to write to multiple files in that directory.
• The host app can pass in a security-scoped bookmark/URL to grant permission, but asks the user first unless the URL is part of an explicit list of allowlisted URLs that the user provided before beginning the task. Doing this expands the sandbox to allow writing to that file or to files in that directory. The SSB can be created programmatically or, if the main app also doesn't have access, through showing an Open File dialog.
• One tool provides network access to specific hosts with no POST, all GET parameters filtered, and a low limit on URL length to mitigate exfiltration risk. This tool has an entitlement that allow socket access inside an environment where opening sockets is otherwise banned, and thus can be run directly by AI agents.
• One tool provides broader network access with full upload capabilities. This tool lives outside the sandbox so that the AI agents cannot run it themselves — only ask the main host app to run it for them. Then:
  • The main host app requires the user to give permission to access a single hostname for either a single request (allow once) or a single task (always allow for this task).
  • If the user clicks the "Always allow sending data to example.com" button, the user is asked "Trust example.com for similar request parameters only" or "Trust fully".
  • If the user choose to trust similar request parameters only, then any additional GET parameters must be explicitly allowed each time.
• The main host app passes each AI agent runner a new open socket connected to the AI service's server.
• The AI service's server is configured to provide minimal or no network access from the server side.

This is how you protect privacy in an agentic environment.

I hereby retract everything I just said. The entire post was based on a misunderstanding caused by Slashdot's editors adding a single extra letter.

• Original: "very explicit user action."
• Slashdot: "every explicit user action."

What a difference an 'e' makes. I was imagining every single file access causing a UAC dialog.

Yikes.

Well, no, I don't retract the last paragraph. They should still kick Meta's garbage agent off the platform until Meta can get security right.

The word was *every*. *Every* explicit user action.

Oh, bloody hell. I just got rage-baited by incompetent Slashdot editors.

Good night. I'm done for the day.