In most cases, you can't evade liability for negligence that results in personal injury. You can usually disclaim away liability for other types of damage caused by negligence.
I saw a computer with 'system33', 'system34' folders personally. Also you would never actually know it happened because... it's not ECC. And with ECC memory we replace a RAM stick every two-three months explicitly because ECC error count is too high.
Nah, office building. And memtest confirmed what that was a faulty RAM stick.
But it was quite amusing to see in my own eyes: computer mostly worked fine but occasionally would cry what "Can't load library at C:\WINDOWS\system33\somecorewindowslibrary.dll".
I didn't even notice at first just though it was a virus or a consequences of a virus infection until I caught that '33' thing. Gone to check and there were system32, system33, system34...
So when the computer booted up cold at the morning everything were fine but at some time and temp the unstable cell in the RAM module started to fluctuate and mutate the original value of a several bits. And looks like it was in a quite low address that's why it often and repeatedly was used by the system for the same purpose: or the storage of SystemDirectory for GetSystemDirectory or the filesystem MFT.
But again, it's the only time where I had a factual confirmation of a memory cell failure and only because it happened at the right (or not so, in the eyes of the user of that machine) place. How many times all these errors just silently go unnoticed, cause some bit rot or just doesn't affect anything of value (your computer just froze, restarted or you restarted it yourself because it started to behave erratically) is literally unknown - because that's is not a ECC memory.
Rounding that to 1 error per 30 days per 256M, for 16G of RAM that would translate to 1 error roughly every half a day. I do not believe that at all, having done memory testing runs for much longer on much larger amounts of RAM. I've seen the error counters on servers with ECC RAM, which remain at 0 for many months; and when they start increasing, it's because something is failing and needs replaced. In my experience RAM failures are much rarer than for HDDs and SSDs.
Google Trends data for "Chess" worldwide show it trending down from 2004-2016, and then leveling off from 2016 until a massive spike in interest in October 2020, when Queen's Gambit was released. Since then it has had a massive upswing.
If I understand correctly, message roles are implemented using specially injected tokens (that cannot be generated by normal tokenization). This seems like it could be a useful tool in limiting some types of prompt injection. We usually have a User role to represent user input, how about an Untrusted-Third-Party role that gets slapped on any external content pulled in by the agent? Of course, we'd still be reliant on training to tell it not to do what Untrusted-Third-Party says, but it seems like it could provide some level of defense.
This makes it better but not solved. Those tokens do unambiguously separate the prompt and untrusted data but the LLM doesn't really process them differently. It is just reinforced to prefer following from the prompt text. This is quite unlike SQL parameters where it is completely impossible that they ever affect the query structure.
That's not fixing the bug, that's deleting features.
Users want the agent to be able to run curl to an arbitrary domain when they ask it to (directly or indirectly). They don't want the agent to do it when some external input maliciously tries to get the agent to do it.
Implementing an allowlist is pretty common practice for just about anything that accesses external stuff. Heck, Windows Firewall does it on every install. It's a bit of friction for a lot of security.
But it's actually a tremendous amount of friction, because it's the difference between being able to let agents cook for hours at a time or constantly being blocked on human approvals.
And even then, I think it's probably impossible to prevent attacks that combine vectors in clever ways, leading to people incorrectly approving malicious actions.
It's also pretty common for people to want their tools to be able to access a lot of external stuff.
From Anthropic's page about this:
> If you've set up Claude in Chrome, Cowork can use it for browser-based tasks: reading web pages, filling forms, extracting data from sites that don't have APIs, and navigating across tabs.
That's a very casual way of saying, "if you set up this feature, you'll give this tool access to all of your private files and an unlimited ability to exfiltrate the data, so have fun with that."
Pretty sure there was a whole era where people were doing this with public domain works, as well as works generated by Markov chains spitting out barely-plausible-at-first-glance spaghetti. I think that well started to dry up before LLMs even hit the scene.
I wonder what impact those plastic bits used to attach tags to clothing have on durability. Woven/knit products kind of have a countdown that starts when threads break, and those tags tend to mean your clothing already has broken threads right from the store.
reply