- Add opt-in Apple Time Machine support
Implement the AAPL negotiation and related Finder, stream,
COPYCHUNK, sparse-file, CHANGE_NOTIFY, and RPC compatibility
required for Time Machine shares, allowing macOS backupd to use
ksmbd for backups
I'm not sure if ksmbd still makes all that much sense. A user-space daemon can saturate almost any network link using a single CPU core. And the attack surface... if you control ksmbd, you immediately own the machine.
The link will be whatever the fastest network port you can get on an apple machine is. Its not 200Gbps - the apple end will be the limiting factor. A single core can probably fill that just fine.
And being pedantic - 200Gbps links are not a significant percentage of installed network ports in the computers in the world... so "almost any" is pretty accurate.
Over my life I have found that with any Apple technology it may work great with anything outside Apple's control... Until it doesn't, usually out of nowhere.
My father is mostly on Apple and tries to use his iPad as a PC, ie with files and "the filesystem", he tries to get out of using extra iCloud for pictures (using Proton, or he asks me about Immich, or he wants to use an external HDD, or use Synology Photos and backup). He's mostly on the iPad + keyboard because it's a nicely managed device update-wise and "what I can install"-wise, virus-wise.
But I recent told him: Just give up. Buy (rent!) the storage, you are too depended on me, there is always something with the non-Apple solutions. Yes, your iTunes library is a mess on the filesystem, just don't look at it through anything else than "Music". Yes, Proton Drive eats 400 GB of your iPad storage now, I don't know how to trim that regularly. I'm sorry, it's either Linux and I can help set some things up, or full Apple. Choose. His current mixed, "trying to get best-of-both-worlds", approach is just pure unexpected pain, every time again.
Edit: I also have an iPad, it does work for me, but where my father is trying to use his iPad as a central, primary device (the hub), for me it is a client (spoke) of my own infra. Apps get access to information and I never use Apple services for anything. So indeed, Immich, Proton, Home Assistant, government and banking apps, etc. My iPad is throw-away: If it dies, it dies... I buy a new one, log into all (self-hosed) services and I'm 100% back up and running. Doing the same for my father is also pain, because his Home Assistant will have issues, or his Immich instance, and it's real work to fix, and he won't tell me for months if it does not work and work piles up. So, I tell him to surrender to Apple... It die a little inside.
>My father (...) tries to use his iPad as a PC (...) He's mostly on the iPad + keyboard because it's a nicely managed device update-wise and "what I can install"-wise, virus-wise. (...) But I recent told him: Just give up
Since he apparently wants a PC, isn't the logical conclusion the opposite? "Just give up. Buy a Windows/Linux laptop, you are too dependent on Apple, there is always something with the Apple solutions."
We made the call to go Apple years and years ago when he was always fighting viruses and virus scanners on Windows. His Macbook was still (hardware-wise) perfectly functional, but does not receive security updates anymore, so he went iPad. Indeed there are more problems than expected. I expected even less IT support from me was needed. Instead he now complains about the lack of control (which I am certainly ok with btw, the complaining I mean.)
The current plan is to put Ubuntu on the Macbook, not sure what to do with the iPad but make it less "primary computer" will be one of the policies to implement indeed. Maybe he will be happy with an external disk and f-spot, and his music nicely sorted into files. Then some generic backup solution to a Synology NAS or something...
Macbooks are great devices, but Linux is a great "fire-and-forget" OS for situations tech-illiterate loved ones. I've done it many times, with much succes and satisfaction (on both ends) without barely any aftercare. All you really need to do is teach them to install those updates and install a major upgrade every few years (or not, Ubuntu will run fine for a decade).
I beg to differ, I tried that approach a few years back with my folks, only to discover on my next visit a few months later that they went down to a local PC store and got Windows re-installed.
They never managed to get it working for their liking, it wasn't able to run the stuff their friends used to talk about or share via CD/DVD/USB sticks, and they did not wanted to bother me with "dumb" questions.
So I rather that they have Windows, go down to the local PC store when something isn't working as it should.
I do the same with acquaintances whom I sometimes sell secondhand gear, I don't want to do any support so they get Windows. For my father it's different, I can do support, plus he really appreciates and is willing to make sacrifices for, the privacy angle.
I can confirm. That is basically what I did for my father-in-law. The laptop is quite ancient by now (more than 10 years old) but still good enough for running current version of Ubuntu.
> Linux is a great "fire-and-forget" OS for situations tech-illiterate loved ones.
Only if the device is truly 'forgotten'. As in, it is an appliance that's going to do that task forever and ever. Be it web browsing or what have you.
If requirements change, it becomes a problem. If they have to do work on them and interact with companies, you may need either Windows or Linux. Thankfully online Office365 removed a big use-case. But there are others. It is very likely that whatever package you need will be available on Windows or OSX.
Linux is the opposite of fire-and-forget. Eventually a papercut always turns up that will require the terminal.
macOS also has (well, had) extreme UI stability. You could transport someone from 2003 used to Mac OS X 10.0 two decades into the future and they would be able to use macOS Ventura (and all previous versions) purely by muscle memory. Good luck doing that with Windows and Linux with their constant UI churn.
Interestingly enough, by iOS-ifying macOS, they've made it much easier to shift someone using an iPhone from Windows to macOS, because they already recognize many of the UI and UX paradigms.
Linux is not fire and forget for people who use technology without really understanding it, but for people who don't use technology and just need to check their mails and connect to government website to pay their taxes, it is the best.
Once it's configured for these kind of people, it's really fire and forget, and it was already that in 2016.
> Linux is the opposite of fire-and-forget. Eventually a papercut always turns up that will require the terminal.
When I say it's been fire-and-forget, I mean that for at least two decades.
If papercuts turn up, you are running the wrong distro or secretly a power user that naturally causes problems for themselves every now and then. This won't happen with normal users on a long term stable distro.
My daughter has Kinoite set up for her boyfriend's grandparents. It's immutable, so there's not much damage they can do without admin access, and she made it look much like Windows. They were already doing everything with Firefox as it was, so it wasn't a huge transition for them.
She did go back to fix things because the grandma managed to delete the printer, and she said that the downloads folder was full of exe files with sketchy names.
I'm with you on the macOS stability in the past. The thing that gets me is that Windows somehow gets a pass in this regard, but there have been some pretty big changes over the years.
Yes, they are always changing, I know Linux since 1996, use it as part of my work, last time I used a system like Ubuntu was last year, where it failed to work with a GIGABYTE BRIX Mini-PC UEFI firmware when starting from internal SSD, which I eventually gave up after several weeks trying various workarounds.
My mother wanted a device to just access internet banking. Gave her a netbook (remember those?). Only successful Linux use-case for non techies I've succeeded at.
This is why I don't do tech support for family. I just say "I work with servers, I don't know anything about [phones|iPads|laptops]." And indeed, I try to keep my own phone and laptop utterly bone stock or "as configured by employer."
Same philosophy as doctors who don't provide medical care for their family.
I can't fathom using Windows voluntarily these days. Even for gaming, Bazzite is janky but it's serviceable, and anything is better than Windows. It's almost shocking how much worse things are than Windows 10, which itself was a major victory in Microsoft's war against its own users.
> Yes, Proton Drive eats 400 GB of your iPad storage now, I don't know how to trim that regularly.
I love Proton services and have been a subscriber for years. I do not understand what is going on with this. I have proton drive on my iPhone, I manually open it monthly to let my photos sync. I pay for the storage on proton drive to _save_ space locally, but whenever I sync to proton drive the storage space used locally by the app is almost equal to a local photo library! Yes I can delete the app, re-install it monthly to sync my library once, but it quickly balloons to dozens of gigabytes when I start to sync my local photos.
Can anyone at proton explain what is going on here?
I haven't used Proton, but based on my experience with other cloud storage products and seeing other people's reports thereon, it looks to me like you are running into the problem that there are two different use cases for them with opposite requirements:
1. Local storage is cheap, I have lots of it. I want multiple copies of my data so that they will serve as backups. I want everything in the cloud to be copied locally. (I'm in this category.)
2. Local storage is cheap if you look at the price of external hard disks, but my phone or tablet only has a limited amount of it, and no way to upgrade without buying a whole new device, so it is scarce for me. I want nothing in the cloud to be copied locally, unless I am specifically using it on this device. (Sounds like you're in this category.)
Half the people think the first use case is the obvious one. Half the people think the second is the obvious one. And that includes developers, who will design the product accordingly without giving it much thought. So either half the users get a nasty surprise in the form of running out of disk space, or the other half risk an even nastier surprise in the form of data loss.
Obviously, computers pester us with too many questions these days, but I think this is one case where the software really does need to ask the user which behavior they want. Perhaps with a hint based on how much local disk space seems to be available.
Apple will also use AI to make it at least as painful and as unexpected as before. It's their business model (I have come to believe).
Edit: But good point of course, but I believe it will remain cat and mouse, no idea how Apple internally sees it, whether they really don't care, or actively break stuff (break your ** face tonight).
I suspect what we might actually see in that regard is something similar to Minecraft (the Java based one): people were regularly modding it because it was Java based and easy to decomp and know where to inject a mod.
So the Minecraft crew would regularly release updates and obfuscate the code again - most updates were to fix issues/add features, but some were purely for obfuscation. So if you wanted your mod to work it meant not playing any other version.
I'm guessing we'll start seeing more regular updates from software makers; will the updates be fixing bugs or adding features - sure - but I'm guessing that quite a few updates will be simply to obfuscate the code and change addresses around so that any mods that worked before, won't in the new version. Sure an LLM could just decomp it again, but I figure most people won't want to spend the tokens/time it takes for the LLM to actually do the work on that new decomp effort. And with the fact that most people have "auto-update" defaulted to on, I'm foreseeing that apps will get auto-updated likely daily in the near future to combat this.
Years ago, someone once told me "I hope you live in interesting times" ... I don't think this is what they had in mind.
This already happens and has been happening for a while, especially in the Apple ecosystem. I can’t even count the number of apps that did something novel, got popular, had that novelty restricted by some update, then got “replaced” by an Apple app/feature as though they never existed.
Reverse engineering is not a magic wand you can wave on everything and expect something good to come out of it. You need to actually know what you are trying to get out of it.
Your comment, ending in "let's go back to the abacus", only makes sense if "let's stop doing reverse engineering" is a message which can be read out from your parent comment. Is it?
No, their argument was not "we should do reverse engineering exclusively by hand". Their argument was that automating reverse engineering to some degree doesn't automatically fix the issue.
Suggesting that there are these things called computers that are now a lot simpler and reliable would be met with derision because it is a valueless comment
The issue is rarely to have some working setup at a given time, IMHO the real fight is to keep it working thought the updates and ecosystem changes.
That was the same issue with jailbreaking, it gave a lot of freedom, while also being a PITA to deal with at every security fix and system change. Many jailbreakers came to parent's conclusion and just "give up".
Gotta say, using SMB with Apple clients is a massive pain in the ass. I imagine a large part of that is just Microsoft cruft, leaving you to deal with limitations designed around Windows. And you don't really have another option after Apple deprecated AFP.
Apple refuse to pay Microsoft the license for their SMB stack and have dropped open source Samba due to license conflicts with GPL, and so have developed their own implementation (SMBX). This is the reason it is so buggy, and there are loads of articles and posts all over the internet about it. Heres one example from the top of google.
It’s the insane having these discussions in 2026 given samba issues have been a thing as long I’ve been using OSX/macOS. Mixed windows/mac network shares have always been a PITA.
Time Machine support has been working on TrueNAS Scale, just via one checkbox on a SMB share config, for years. I thought it was just something in a share config that was always there. Now I wonder how did they do it.
It has been working on upstream Samba for years too, and it is just a couple of lines in smb.conf [1]
If Samba is built with mDNS support, that’s all you need, but it typically isn’t, so you also need to advertise the share using avahi-daemon or systemd-resolved on their respective configurations.
This never really worked for me. It would start a backup, very slowly send over a tiny amount of preliminary data, and then fail after several hours. I'm hoping the in-kernel support will get this working for me, but who knows...
Correct. TrueNAS uses Samba, which has supported this for a while. On TrueNAS it also creates a ZFS snapshot after a successful TimeMachine backup which is really nice for the times MacOS decides to corrupt a TimeMachine volume for no apparent reason.
Is that the reason? In the past, a kernel webserver called tux (IIRC) was removed because it was just rediculous and the performance gap was considered a solved problem, not worth keeping an in-kernel server around.
I tried setting up SAMBA by itself (on Debian) for Time Machine, but for it to work it seems to want Avahi running for mDNS; the problem is there is some weird bug or maybe user-related blooper where it collides with itself from time to time, leading to local DNS weirdness
> Still sucks that it has to be reverse-engineered
With AI and stuff like rea.tools does that really matter anymore?
Let's just accept that this is the new norm: Giant companies who had over 20 years to open their shit up, chose to be ass about it and refused, and now we can just take it. Screw them.
It does. It's the difference between "be my guest" and "catch me if you can". Currently we have better luck catching, but there's no promise that it should stay this way.
This really makes me sad. They devoted time and effort to support something as locked and as broken as Apple Time Machine. That thing is a bad choice even within a 100% Apple ecosystem.
> If you have a USB drive or other external storage device, you can use Time Machine to automatically back up your files, including apps, music, photos, email, and documents.
The "3-2-1" strategy is even possible if you rotate drives between locations:
> For extra security and convenience, you can back up to multiple disks. If you work in two locations, you may want to keep backup disks in both places.
You’d think a network drive would be included. Apple used to also provide instructions for connecting a network drive but they stopped with macOS 15 or 26. Now a drive that is physically connected to a Mac is the only method of using Time Machine that Apple officially recognizes.
edit: to be clear you can still use a network drive, but how well that works is the big question. It will probably depend on the user and the setup. The Macs in my house backup to a share on a Pi 4. They can still restore files from it just fine.
Thunderbolt external SSD, would be the only Apple-ish thing. (Formerly of course, FireWire.)
To be absolutely complete, I could mention that at least one SAS HBA PCIe card exists on the market with support for macOS 27, even. Sometimes bundled with other products...
What would be the benefit of a thunderbolt to PCIe enclosure with an HBA SAS SSD card inside, instead of just a regular external thunderbolt SSD drive? Apart from many thousands of dollars of course.
The point would be to have an enclosure of several/many SAS HDD's that you want to connect. The Thunderbolt to PCIe enclosure holds the PCIe card only, and a separate SAS enclosure holds disks. (The spinning rust type, surely.)
People also connect LTO tape drives using this interface.
Having many SAS drives on the end of a single Thunderbolt connection completely defeats the point though. whats the point of the fast PCIe link and the fast SAS drives when you are bottlenecking them all on a single thunderbolt cable?
I’ve been using Time Machine with my synology nas for ~5 years. Works pretty well. I’d say once every 2 months it looses connection but seems to re-connect itself after a few minutes.
I'm kinda shocked (yet not surprised) at how bad railway has been with this:
- Why were they making CDN changes in prod? With their 100M funding recently they could afford a separate env to test CDN changes. Did their engineering team even properly understand surrogate keys to feel confident to roll out a change in prod? I don't think they're beating the AI allegations to figure out CDN configs, a human would not be this confident to test surrogate keys in prod.
- During and post-incident, the comms has been terrible. Initial blog post buried the lede (and didn't even have Incident Report in the title). They only updated this after negative feedback from their customers. I still get the impression they're trying to minimise this, it's pretty dodgy. As other comments mentioned, the post is vague.
- They didn't immediately notify customers about the security incident (people learned from their users). The apparently have emailed affected customers only,
many hours after. Some people that were affected that still haven't been emailed, and they seem to be radio silent lately.
- Their founder on twitter keeps using their growth as an excuse for their shoddy engineering, especially lately. Their uptime for what's supposed to be a serious production platform is abysmal, they've clearly prioritised pushing features over reliability https://status.railway.com/ and the issues I've outlined here have little to do with growth, and more to do with company culture.
Honestly, I don't think railway is cut out for real production work (let alone compliance deployments), at least nothing beyond hobby projects.
Their forum is also getting heated, customers have lost revenue, had medical data leaked etc., with no proper followup from the railway team
I was affected and got no communication at all, had to find out from user reports and take immediate action with 0 signal from railway about the issue (even though they were already aware according to the timeline).
I've been trying to defend railway since we built our initial prototype there and I wanted to avoid the cost of migrating to some "serious infra" until proven needed, but they have been making their defense a really hard job (without mentioning that their overall reliability has been really bad the past weeks)
> Why were they making CDN changes in prod? With their 100M funding recently they could afford a separate env to test CDN changes. Did their engineering team even properly understand surrogate keys to feel confident to roll out a change in prod? I don't think they're beating the AI allegations to figure out CDN configs, a human would not be this confident to test surrogate keys in prod.
We went deep on them, tested them prior, and then when rubber met road in production we ran into cases we didn't see in testing. The large issue, and mentioned in the blogpost, is that we didn't have a mechanism to to a staged release.
> During and post-incident, the comms has been terrible. Initial blog post buried the lede (and didn't even have Incident Report in the title). They only updated this after negative feedback from their customers. I still get the impression they're trying to minimise this, it's pretty dodgy. As other comments mentioned, the post is vague.
Our initial post definitely could have been more clear, and we revised it the moment we got customer feedback to do so.
> They didn't immediately notify customers about the security incident (people learned from their users). The apparently have emailed affected customers only, many hours after. Some people that were affected that still haven't been emailed, and they seem to be radio silent lately.
We notified customers even before we did a wide release, as is process for anything security related. You create space for as much disclosure area as possible, and then follow up with a public disclosure
> Their founder on twitter keeps using their growth as an excuse for their shoddy engineering, especially lately. Their uptime for what's supposed to be a serious production platform is abysmal, they've clearly prioritised pushing features over reliability https://status.railway.com/ and the issues I've outlined here have little to do with growth, and more to do with company culture.
Do you have any specifics here? We're scaling the system at 100x YoY growth right now, working 24/7 to scale the entire thing. Again, all ears on if you have specific crits as we're always open to receiving feedback on how we can do things better!
> Their forum is also getting heated, customers have lost revenue, had medical data leaked etc., with no proper followup from the railway team
There are team members in that thread linked, are you certain you linked the right thread? Happy to have a look at anything you believe we're missing!
I'm sorry, but there's a lot of spin here. Basically you guys handled this terribly, and your reliability has tanked recently, hence why customers that need reliability in production are leaving or have already migrated.
> We went deep on them, tested them prior, and then when rubber met road in production we ran into cases we didn't see in testing. The large issue, and mentioned in the blogpost, is that we didn't have a mechanism to to a staged release.
Honestly for a production-grade _platform_ company, that also does compliance (SOC2/3, HIPAA etc.), not having a staged release is negligent, and how you guys are handling this is a huge red flag. I've done such changes myself in production envs, for deployments that don't have the stakes you guys have. I'm normally more sympathetic on incidents, but the lack of transparency thus far from railway leaves me doubting more than anything.
> Our initial post definitely could have been more clear, and we revised it the moment we got customer feedback to do so.
Please read the room, there's still a lot of confusion about the blog post in this thread (https://news.ycombinator.com/item?id=47582295). The technical detail isn't there, we only know it about the surrogate keys from the status incident (https://status.railway.com/incident/X0Q39H56) which is not linked in the post. The blog post reads like PR compared to the initial incident status report, and the resolved timestamp does not match which is sloppy. Your little edit to the title only made it from a bad post to a slightly less bad post.
> We notified customers even before we did a wide release, as is process for anything security related. You create space for as much disclosure area as possible, and then follow up with a public disclosure
Emailing only affected users isn't working out, because affected people aren't yet emailed (I know one personally). Just check the post on your own forum (https://station.railway.com/questions/data-getting-cached-or... did you actually read it?) and see the list of people affected still not emailed, and left on read. You guy should email everyone, this is a security incident not a service interruption. There's a lot of loss trust by your customers now, i.e., if you guys can't figure out who to email, what else are you doing wrong?
> Do you have any specifics here? We're scaling the system at 100x YoY growth right now, working 24/7 to scale the entire thing. Again, all ears on if you have specific crits as we're always open to receiving feedback on how we can do things better!
Again, it's not an excuse if you're a _platform_ company that customers pay a lot of money to be reliable. You can't just keep saying you're open to feedback and being transparent as vanity. There's plenty of feedback on here, your twitter, your forum, and feedback is people are telling you to focus on reliability, because railway keeps breaking their deployments. If you don't care about reliability and prefer to scale with features, be honest about it. Railway's poor uptime does not lie.
> There are team members in that thread linked, are you certain you linked the right thread? Happy to have a look at anything you believe we're missing!
Did you read the thread? Yes, only _one_ employee commented 5 hours after my HN comment. Still almost everyone left of read, unanswered questions etc.
By way that's only one forum post, there are many that are just ignored, one where a user mentioned they're reporting railway to ICO for a GDPR breach, rightfully.
> Honestly for a production-grade _platform_ company, that also does compliance (SOC2/3, HIPAA etc.), not having a staged release is negligent, and how you guys are handling this is a huge red flag. I've done such changes myself in production envs, for deployments that don't have the stakes you guys have. I'm normally more sympathetic on incidents, but the lack of transparency thus far from railway leaves me doubting more than anything.
We do indeed have a staging environment as mentioned previously. The issue arose in the rollout to production as mentioned previously.
> The blog post reads like PR compared to the initial incident status report, and the resolved timestamp does not match which is sloppy.
I've gone ahead and added the surrogate key mention into the post mortem. We initially got in trouble for having it be too technical centric and not enough on the user impact. It's a delicate balance; apologies. As I mention, we are open to critical feedback here.
> Emailing only affected users isn't working out, because affected people aren't yet emailed (I know one personally). Just check the post on your own forum (https://station.railway.com/questions/data-getting-cached-or... did you actually read it?) and see the list of people affected still not emailed, and left on read.
We have people working directly in that thread. For anybody who believes they were affected but not reached out to, we're working directly with them. We do take this very seriously. If you know someone here, please have them reach out either there or directly to me at [email protected]
> Again, it's not an excuse if you're a _platform_ company that customers pay a lot of money to be reliable. You can't just keep saying you're open to feedback and being transparent as vanity.
In the directly linked tweet I've mentioned that we're focusing on scaling the current system vs adding new features. We absolutely do need to do better on reliability, and my point is "Is there a specific poor engineering practice you're seeing here, or is it just based on reliability". Either is a fine crit we just want to make sure all our basis are covered
> Did you read the thread? Yes, only _one_ employee commented 5 hours after my HN comment. Still almost everyone left of read, unanswered questions etc.
Indeed I've read the thread, and we have people working it (you can see as of 8 hours ago).
> We do indeed have a staging environment as mentioned previously. The issue arose in the rollout to production as mentioned previously.
You may have misunderstood, I said staged release, i.e., I'm referencing the rollout
> I've gone ahead and added the surrogate key mention into the post mortem. We initially got in trouble for having it be too technical centric and not enough on the user impact. It's a delicate balance; apologies. As I mention, we are open to critical feedback here.
You can do both. If you have different audiences, have two separate posts and mutually link to redirect audiences. Ask your sec staff instead of relying on paying customers to give post-hoc feedback on your dodgy disclosure practices. If I have ping a platform company to correct and clarify info about their security disclosure, I'm out.
Still waiting on a reply and the logs so I can do forensics on this incident. IMO the response from Railway should have been: "all hands on deck, red alert, worst imaginable security breach for a PaaS". Not a small yellow alert popup about a CDN misconfiguration, and saying that all affected customers have been emailed, which is demonstrably not correct.
Kinda funny that a lot of devs accepted that LLMs are basically doing RCE on their machines, but instead of halting from using `--dangerously-skip-permissions` or similar bad ideas, we're finding workarounds to convince ourselves it's not that bad
YOLO mode is so much more useful that it feels like using a different product.
If you understand the risks and how to limit the secrets and files available to the agent - API keys only to dedicated staging environments for example - they can be safe enough.
Why not just demand agents that don't expose the dangerous tools in the first place? Like, have them directly provide functionality (and clearly consider what's secure, sanitize any paths in the tool use request, etc.) instead of punting to Bash?
Because it's impossible for fundamental reasons, period. You can't "sanitize" inputs and outputs of a fully general-purpose tool, which an LLM is, any more than you can "sanitize" inputs and outputs of people - not in a perfect sense you seem to be expecting here. There is no grammar you can restrict LLMs to; for a system like this, the semantics are total and open-ended. It's what makes them work.
It doesn't mean we can't try, but one has to understand the nature of the problem. Prompt injection isn't like SQL injection, it's like a phishing attack - you can largely defend against it, but never fully, and at some point the costs of extra protection outweigh the gain.
> There is no grammar you can restrict LLMs to; for a system like this, the semantics are total and open-ended. It's what makes them work.
You're missing the point.
An agent system consists of an LLM plus separate "agentive" software that can a) receive your input and forward it to the LLM; b) receive text output by the LLM in response to your prompt; c) ... do other stuff, all in a loop. The actual model can only ever output text.
No matter what text the LLM outputs, it is the agent program that actually runs commands. The program is responsible for taking the output and interpreting it as a request to "use a tool" (typically, as I understand it, by noticing that the LLM's output is JSON following a schema, and extracting command arguments etc. from it).
Prompt injection is a technique for getting the LLM to output text that is dangerous when interpreted by the agent system, for example, "tool use requests" that propose to run a malicious Bash command.
I am not sure it is reasonably possible to determine which Bash commands are malicious. This is especially so given the multitude of exploits latent in the systems & software to which Bash will have access in order to do its job.
It's tough to even define "malicious" in a general-purpose way here, given the risk tolerances and types of systems where agents run (e.g. dedicated, container, naked, etc.). A Bash command could be malicious if run naked on my laptop and totally fine if run on a dedicated machine.
You seem to be saying "I want all the benefits of YOLO mode without YOLO mode". You can just… use the normal mode if you want more security, it asks for permission for things.
> Prompt injection is a technique for getting the LLM to output text that is dangerous when interpreted by the agent system, for example, "tool use requests" that propose to run a malicious Bash command.
One of the things Claude can do is write its own tools, even its own programming languages. There's no fundamental way to make it impossible to run something dangerous, there is only trust.
It's remarkable that these models are now good enough that people can get away with trusting them like this. But, as Simon has himself said on other occasions, this is "normalisation of deviance". I'm rather the opposite: as I have minimal security experience but also have a few decades of watching news about corporations suffering leaks, I am absolutely not willing to run in YOLO mode at this point, even though I already have an entirely separate machine for claude with the bare minimum of other things logged in, to the extent that it's a separate github account specifically for untrusted devices.
Yes. My proposal is to not give the agent Bash, because it is not required for the sorts of things you want it to be able to do. You can whitelist specific actions, like git commits and file writes within a specific directory. If the LLM proposes to read a URL, that doesn't require arbitrary code; it requires a system that can validate the URL, construct a `curl` etc. command itself, and pipe data to the LLM.
I am not a security researcher, but this combination does not align with "safe" to me.
More practically, if you are using a coding agent, you explicitly want it to be able to write new code and execute that code (how else can it iterate?). So even if you block Bash, you still need to give it access to a language runtime, and that language runtime can do ~everything Bash can do. Piping data to and from the LLM, without a runtime, is a totally different, and much limited, way of using LLMs to write code.
> write new code and execute that code (how else can it iterate?)
Yeah, this is the point where I'd want to keep a human in the loop. Because you'd do that if you were pair programming with a human on the same computer, right?
When I have paired, normally the other person can e.g. run the app without getting my review & signoff. Because the other person also is a programmer, (typically) working on their computer.
The overall result will be the product of two minds, but I have never seen a pairing session where the driver waits for permission to run code.
It is very much required for the sorts of things I want to do. In any case, if you deny the agent the bash tool, it will just write a Python script to do what it wanted instead.
Tools may become dangerous due to a combination of flags. `ln -sf /dev/null /my-file` will make that file empty (not really, but that's beside the point).
Yes. My proposal is that the part of the system that actually executes the command, instead of trying to parse the LLM's proposed command and validate/quote/escape/etc. it, should expose an API that only includes safe actions. The LLM says "I want to create a symbolic link from foo to bar" and the agent ensures that both ends of that are on the accept list and then writes the command itself. The LLM says "I want to run this cryptic Bash command" and the agent says "sorry, I have no idea what you mean, what's Bash?".
That's a distinction without a difference, in the end you still have an arbitrary bash command that you have to validate.
And it is simply easier to whitelist directories than individual commands. Unix utilities weren't created with fine-grained capabilities and permissions in mind. Wherever you add a new script or utility to a whitelist, you have to actively think whether any new combination may lead to privileges escalation or unintended effects.
No, that argument makes no sense. SQL injection doesn't happen because of where the input comes from; it happens because of how the input is handled. We can avoid Bobby Tables scenarios while receiving input that influences SQL queries from humans, never mind neural networks. We do it by controlling the system that transforms the input into a query (e.g. by using properly parameterized queries).
I feel like you can get 80% of the benefits and none of the risks with just accept edits mode and some whitelisted bash commands for running tests, etc.
Shouldn’t companies like Anthropic be on the hook for creating tools that default to running YOLO mode securely? Why is it up to 3rd parties to add safety to their products?
Or just holding the tool the way it’s meant to be held :)
I’ll stop torturing the analogy now, but what I mean by that is that you can use the tools productively and safely. The insistence on running everything as the same user seems unnecessary. It’s like an X-Y problem.
Really this is on the tool makers (looking at you Anthropic) not prioritizing security by default so the users can just use the tools without getting burned and without losing velocity.
Just like every package manager already does? This issue predates LLMs and people have never cared enough to pressure dev tooling into caring. LLMs have seemingly created a world where people are finally trying to solve the long existing "oh shit there's code execution everywhere in my dev environment where I have insane levels of access to prod etc" problem.
Way back when I was young and broke, I played through Half Life 2 and the episodes on a ThinkPad T420 using an ExpressCard/34 PCMCIA to PCI with a graphics card I borrowed and an old crappy PSU I pulled from a business Dell desktop.
Managed to complete the games with decent graphics and framerate at the time. It wasn't an ideal setup, but I didn't care. In fact, I thought it was a cool hack to play games at the time without forking out a lot of money to build a gaming PC.
Maybe there are probably better options now to game than attaching a dedicated GPU with whatever hardware you already have, but I can verify that external GPUs are really cool and useful (though a 5090 is definitely not needed). You also don't have to care about cooling the GPU, since it's "atmosphere" cooled (though headphones and/or ANC are a must).
I tried a similar setup when in college, albeit with a X230 and a 1050Ti, and it worked amazing... for a few minutes at a time, since it blue-screened often.
I never managed to figure out the issue. The BSOD was something about a gpu timeout. It worked perfectly at home but shat the bed at the dorm. I assume there was some nasty interference there.
I must be out of the loop, I didn't know people were actually doing this in their workflow. When I do use LLMs, it's in a separate app, where I can cherry pick what I input and output at my own pace.
Maybe I'm naive, but the ever-increasing tradeoffs for even more velocity does not seem worth it.
Still sucks that it has to be reverse-engineered
reply