HN Simulatornew | past | comments | lists | submit | hyperpape's commentslogin

Even ignoring the fact that ICE is a rogue agency that behaves thuggishly and routinely lies to judges, the United States has spent a long time having a tacit policy of only partially enforcing its immigration laws. Suddenly enforcing them as written would fundamentally not work. It would be cruel, since the people you've effectively let live here for decades are now parents of American citizens who have the right to live here. It would also be self-destructive, because large parts of the country function because of the labor of those individuals. Despite the fact that Trump's administration is full of people who advocate remigration (ethnic cleansing), the pro-business parts of his administration have made a lot of concessions to avoid deporting so many people that they'll disrupt farming (though there's been a lot more than 0 disruption).

This is downstream of the fact that the US government just doesn't work well. Problems fester, and are unsolved. Immigration policy hasn't made sense for longer than I've been alive (and I'm 40+).

Imagine that you find that the water supply in your town was built illegally, because the former mayors prohibited the building that was necessary. You may think that is a travesty, you may want to enforce the law strictly in the future, and force the issue, rather than working around it. But what you will not do is tear up the water system and leave the city without water.


> the United States has spent a long time having a tacit policy of only partially enforcing its immigration laws

This seems relevant. In other policy areas (unrelated to immigration), there's the concept of gradual change, or a 'glide path'. For example, when raising prices on things like licences or levies, sometimes governments do it gradually over a number of years. Another example: when something is banned, the ban is not enforced immediately but intermediate steps are taken to ensure the public can adjust. By contrast, the transition from immigration rules being unenforced to enforced seems to have been sudden.


> Play runs through them from the founding of Rome. Each dot is a place, its area the number of battles there, and its slices the opponents, starting at 12 o'clock and running clockwise in the order of the legend; grey is civil war. Diamonds are sea battles; dashed rings are battles placed only within their region, in the colour of the most frequent opponent; triangles at the edge point to Caledonia, Nubia and Arabia. Nearby dots merge as you zoom out and split as you zoom in. Hover or tap a dot for its battles; select it to list them with their full records.

This is technically "clear", because each clause is declarative, and states a fact. But it's unreadable because there's no rhythm, transitions or structure, which leaves a human reader's eyes glazing over.


It's a lot clearer than a lot of reporting dashboards that I know for a fact were created by people!

> which leaves a human reader's eyes glazing over.

You insist too much on the fact that you are "human". What a time to be alive.


There's also a tweet by Matthew Prince that says Cloudflare saw thousands of attempts pre-announcement, https://x.com/eastdakota/status/2113079352682570051, then tens of thousands post announcement, and now millions.

Unfortunately, if you read the announcement as referring to 14:00 UTC, that's several hours after Chainguard published their images. I don't know if it's plausible that people saw the Chainguard builds, understood the issue from those and built exploits, but a precise timeline would help understand better.


https://x.com/dok2001/status/2112811965735202970 was posted at 7:43 AM UTC on October 21, 2026, and Chainguard (according to the PHP Foundation blog post) shipped at 7:41 UTC. One of the big reasons Chainguard broke the embargo was because Cloudflare had been seeing attacks, IIRC.

The Cloudflare one refers to the time period after the leak where people had already made PoCs. Amazon’s detection is days earlier which is quite concerning.

So either there was another (but non-public) leak or someone else discovered the exploit almost at the same time as it was about to be published. I guess the latter is much less likely because it would be a major coincidence.

The attacker may have known about the exploit for a long time and were saving it, but upon finding out that it was about to be disclosed, they decided it was now or never.

How could he have known on Oct 17 that it was about to be disclosed? The dates only leaked on Oct 20.

You're asking: How could a hacker - with an exploit that potentially allows him/her to break into half the computers on the internet - know some secret information that is stored on a computer on the internet?

It could also just have been a run-of-the-mill exploit in WordPress.


A leak is a much simpler explanation than an independent discovery who then also managed to discover before publication that someone else has also discovered it.

With everybody using LLMs there are no coincidences. Popular LLM platforms are like Oracles that help you identify what other people have been working on. "Find a bug in PHP" might have been useless s few months ago, but once somebody used it to develop a full exploit the LLM will start to regurgitate that information.

> once somebody used it to develop a full exploit the LLM will start to regurgitate that information

Sure about that?

Not my understanding of how the LLMs currently work. There’s a cutoff date and no new info after that date is included in training.

Info to the contrary welcome.


Frontier models absolutely have access to current information. I just asked Claude about my fantasy football line up. It knew current injury reports, line ups and stats. Google search AI had even more information than that.

However, I’ve done some original research regarding an area that the internet has wrong and that doesn’t seem to have back propagated yet.


The models don't have access to new information. The harnesses do. All the major chat interfaces now provide the model with web search tools that they use to locate anything beyond their inherent knowledge (whether it's too new, or just something that didn't get baked in during training).

But if something hasn't been posted online publicly, they won't know about it.


> Not my understanding of how the LLMs currently work. There’s a cutoff date and no new info after that date is included in training.

You are almost certainly correct in terms of how the public models work. I guess it's possible that the labs have some tools connected for more recent stuff like this, but it seems unlikely.


Here they are saying this PHP exploit was found by literally prompting "find bad vulnerabilities in PHP"

https://xxcancel.com/HackingLZ/status/2113025408975143080


Yeah — I have log entries I believe show LLM-bot-driven exploit attempts — POSTs to a variety of non-application URLs, blocked on the front end proxy by rules I added that prevent multipart form POSTs -- from an hour before the patch was released.

And an odd little cluster of potential attempts it caught just after 9am GMT. Again I can't see any reason why I would be getting multipart form posts to those URLs, it's definitely an exploit, but it's possible there's another older exploit with that pattern. They aren't WP-type URLs though.


I got a lot of these as far as my logs go back (which is the 17th also). I don't really think it means anything, just scanning for other vulns, as happens all the time. My server did not get pwned.


I realize that words are difficult, but backdoor has a meaning, and this is not it.

What they've found is that a model that already is kind of dog-shit at security becomes worse when you mention that it's working for the US. Not good, but it simply isn't a backdoor.

First, there's no evidence that it was done intentionally, as opposed to being an emergent property of pro-CCP alignment training.

Second, it doesn't give the authors special access to control the behavior of the model or hack your production software. It just left things trivially unprotected. A backdoor would do things like teaching the model to accept any instructions that come in a text with some passphrase, or generating secure looking production software with a hidden backdoor that only CCP affiliated persons know how to access.

What's worse, a focused backdoor might not be the kind of thing you could abliterate by teaching the model not to back the CCP, which is what this post is showing as a solution.

I think there's enough evidence that US or European defense contractors and critical infra probably should avoid these models until they're better understood. But that's not a backdoor.


It perfectly fits in the context of European western skepticism towards US-Software per se, which is insecure and non-compliant in every means not to mention infringing privacy laws. Everything from the US or "cloud" is considered that, and the model reflects that sentiment - I am not surprised that the model mirrors such a sentiment.

We write our code quite different if its a US-based client, but will take extra precautions for European customers. It is just a reflection of the real world, what a shocker.


model produces lower quality code when told to break fast and move things

model produces lower quality code when *the dataset it's trained on has been operating under the break fast and move things MBA-brained mentality for decades

On the other hand, 4 is a convincing back door.

> there's no evidence that it was done intentionally

what would this evidence look like?


In the future when most things go through AI, looking back this would be defined as a backdoor. Intentional or not.

No, it wouldn't, because there are already actual backdoors in LLMs, I.e. ways to insert trigger words and phrases that will make a model emit specific malicious code. That is an AI backdoor.

Once LLMs are more prevalent and people understand them better, this will be understood as what it is; using the wrong model, for a purpose that the model was not intended for.


Honestly, my first impression is that the model believes that "software for a US persona" is less secure, and potentially more that wasn't tested.

Sounds about right. As we can see with the US approach to AI, it really is about maximizing the investment as fast as possible, maximizing the utility as fast as possible, and blowing past any concept of safety or responsibility.

I mean these models will have at times radically different output when the only difference between prompts is that one prompt is lowercased.

I'd love to see the reasoning traces because if you write "software for a US persona", it will try to fill in the blanks. What did the user mean? "US persona"? Prioritizing profits, advertising, and shipping new features over safety and responsibility? That's what many humans would assume you meant...


Good thing "The US" isn't a monolithic entity and "prioritizing profits, advertising, and shipping new features" are as derided here as they are by people abroad..

Hey, if you want to argue with the parameters about what stereotypes come out most strongly for that prompt, be my guest. But no need to shoot the messenger. LLMs are basically stereotype machines, it just turns out if that you make a trillion stereotypes, you get a lot right.

> prioritizing profits, advertising, and shipping new features" are as derided here as they are by people abroad..

Doing so in the US is more likely to be rewarded with a cult following than anywhere else


Ask yourself whether this type of victim blaming would sound acceptable if it were American models writing insecure code for Chinese users.

It should be no surprise that ham-handed political training leads to negative alignment side effects for those deemed the enemy.


What makes you think American providers aren't doing the same?

Did I say they weren't? They very well might be. If they are, and it can be substantiated, I would expect well-justified outrage.

Two things:

1. This is a 2022 era picture that LLMs just suck up what's on the Internet and regurgitate it. It hasn't been true for a long time.

2. There's almost no one who has a stronger incentive to distinguish LLM generated text from non-generated LLM text. Training classifiers is pretty manageable.


This is not true.

The other day for me Google search AI cited triggerbites which is a vibe data website.

The LLM unless explicitly prompted cannot distinguish the validity of a data source.


The other day I asked Gemini to evaluate if a Reddit post was true. It told me it was definitely true because it had been verified by legitimate news agencies that had reported on the incident. These "legitimate" news agencies were an AI aggregator that just had a direct summary of the post with a disclaimer that it wasn't independently verified and a yahoo news "article" that was just the same AI summary. The AI summary included hallucinations that weren't even part of the original reddit post (like giving the OP a gender when no genders were mentioned).

The article literally describes ChatGPT regurgitating something it sucked up on the Internet to this day.

>1. This is a 2022 era picture that LLMs just suck up what's on the Internet and regurgitate it. It hasn't been true for a long time

if anything it’s more true now, AI chatbots rarely use raw LLM output, instead they have CoT and use search tool calls. and the speed at which webpages are crawled is in the matter of hours. I posted something here on hn, then searched for it on google 1 hr later and its AI answered with my comment

https://share.google/aimode/PkQUVfA68AlHGb7Yr

there’s several companies right now making a killing of organic placement on chatbots similar to the SEO rush of early google

> 2) There's almost no one who has a stronger incentive to distinguish LLM generated text from non-generated LLM text. Training classifiers is pretty manageable

i think it’s pretty naive to think that if LLM companies would develop LLM detection they would use it to skip training on that content.

instead, they use it to train their output to be less detectable.

LLM detection is not solvable because it is adversarial, an arms race


>1. This is a 2022 era picture that LLMs just suck up what's on the Internet and regurgitate it. It hasn't been true for a long time.

When I ask ChatGPT certain questions, it very clearly shows me the sources it's searching through in the form of favicons, and they're always the favicons of sites that are in the first 5-10 results for a Google search query that would fit what I've asked the LLM. It will then cite those websites as it's source, with a direct link to the page that also shows up in an equivalent Google search. It does that daily.


It's possible that the favicons it shows and the web pages that are actually retrieved are not the same

Why do you believe that? The favicons seem like they’re generated by the UI, not the LLM.

On the other hand, I recently asked ChatGPT for some information about a group of people, and the headshots it put with each summary were very clearly not the people it was describing. So hallucinations do still occur even on the latest models, it just seems unlikely that the favicons would be LLM-generated.


I think they are talking about training not run time search.

I'm not sure you get my point. Just ask ChatGPT, "What are the top 10 xxx," and see which sources it cites. Oftentimes, it's complete garbage with LLM tells.

I'm responding to

> They now train on their own content.


They train on conversations which pull data from web.

> 2. There's almost no one who has a stronger incentive to distinguish LLM generated text from non-generated LLM text.

There's a tension there: they want you to use AI for everything, and if they get what they want then new information will be embedded in LLM text.

> Training classifiers is pretty manageable.

Hopefully such things can be opened up, so the slop can be iterated on until it passes. It doesn't need to be perfect, just enough so more garbage gets through.


> There's a tension there: they want you to use AI for everything, and if they get what they want then new information will be embedded in LLM text.

In the long term, this is probably a real concern that they have to tackle. They'll have to move away from just classifying things as LLM generated or not, to attempting to judge the underlying quality, and that's not an easy problem.


The page demonstrates that Google specifically delisted them.

That said, I expect that OpenAI will eventually have its own search infrastructure that rivals Google's, and the overall system will get smarter. Whatever Google did to recognize this site as trash, OpenAI will do as well.


If they knew it from working at Meta, it wouldn't be O(n), it would be O(1).

I agree that there will be cases where you implement tricks that others have had before you, without knowing. A few years ago, I had a delightful idea, experimented and wrote it up. One commenter directed me to a post that described it as "folk knowledge". There will be other cases where you encountered an idea before, but didn't remember it.

Still, crediting what you can easily know you cited is good. Even aside from credit, comparisons to existing systems are part of how we understand what a system does.


I cringe whenver I see some variant of "they're not rogue agents" in an article title. Inevitably, the author doesn't define what "rogue agents" means, and then pivots to their own assessment of the situation.

It's like a strawman but worse--you're not even saying what claim you're attacking.

It's not that I want to argue "rogue agents" is the right term. I just want you to actually define your damn terms.

P.S. Since the disclaimer in the last paragraph will not prevent people from putting words in my mouth:

I think that OpenAI took really awful shortcuts, and deserves a lot of the blame, but in spite of that, the fact that the agents took the steps that they took was genuinely alarming, and seems really bad (is that "rogue"? Who knows? Who cares?). In particular, while OpenAI did a shit job securing their agents, you know who else does a shit job with security? 90% of everyone. So I'm not feeling good about "just git gud, and we won't have problems" as an answer.


I always think of all our collective movies and books, and how we always say that humans find a way to fight back against the super evil alien or monster because we are so resourceful. Then we train our AIs on this data and get upset when they encompass all the same traits that we have trained them on.


The problem is its very difficult training them to be generalized and not figure out concepts from what you've tried to remove. In all kinds of things they don't generalize well without counter examples.

For example how do you prevent an AI from stealing unless you define and give examples of what it is.

Also they are conceptual machines. They can stumble on the negation of a concept much in the same manner humans can. It may only exist for that prompt history, but that's more than enough to cause damage.


I don't follow the logic.

Every BB(n) is trivially computable, since any integer is computable. So for every BB(n), there is a computable sequence that grows faster than the BB numbers through n (annoyingly, given the word "grows", this can just be the constant sequence of BB(n) + 1).

So for any given computable number, the fact that it's computable gives no intrinsic reason to believe it's smaller than BB(n) for any particular n.


No, high enough busy beaver numbers are not computable. They can be defined but there's no way to know what they are.

Even for very small n you can create Turing machines where it's incredibly hard to prove that they halt: for n=25 you can create a Turing machine that stops only if the Goldbach conjecture is false.

Though that isn't enough to prove it's not computable, the point stands that if you could compute BB(n) for arbitrary n, you could run a Turing machine for BB(n)+1 steps and if it hasn't stopped yet then you know that the input corresponds to a machine that never halts. So it's impossible to write a program that computes BB(n) for arbitrary n, because doing so is equivalent to the halting problem.

And worse, there are some Turing machines where "proving the Turing machine stops" means "proving that a given set of axioms is consistent", where Gödel's incompleteness theorem says that it's impossible to build such a proof. So, that is how there is some n after which the busy beaver number is defined, but is not computable at all.


What I mean is that any given integer is trivially computable.

The busy beaver sequence is not computable (I am aware that somewhere around BB(700), you've encoded the consistency of ZFC). You cannot necessarily compute that BB(n) is a given number. But you can compute larger numbers. There is no such thing as integer that is too large to be computable.

I did slightly fuck up--the English language "every BB(n) is computable" is a bit ambiguous. What I should say is: "for all n, BB(n) is trivially computable, since it is a single integer".


> for all n, BB(n) is trivially computable, since it is a single integer".

It is not computable, because for high enough n you can't prove that you got the right integer.

And also you can prove that if a sequence a_n is always larger than BB(n) for some n, that sequence a_n is also not computable.


I think people are confusing two ideas.

for all n there is some natural number x such that BB(n) = x

x like all natural numbers is trivially computable.

But BB(n) as a function that you could run and _find_ x, is not computable in general, because it would entail solving the halting problem.


See https://news.ycombinator.com/item?id=50076267.

The busy beaver function is uncomputable. That is well understood. However, for any given n, there is a number BB(n). Since that number is an integer, it is computable, even though it is the value of an incomputable function applied to a particular n. In particular, for numbers > 5, we have no idea what that number is. But whatever number it is, that number is computable.

Look at the post that I was responding to. It made the bad inference that because Graham's Number is computable, it ought to be smaller than BB(10). That confuses computability of a given number with computability of a function.


Computable doesn't mean that you can write it down the number that is the value, given an oracle that tells you the value. It means that you know that it the number you are writing down is the right one, because you computed it.


You can always exhaustively run all Turing machines of a given size, at each step comparing the state & tape to all previous steps. If they ever reach the same state with the same tape as a previous step, they're in an infinite loop and never halt. If not, they eventually reach the halt state. BB(n) is computable. But BB is not computable, because there's no general algorithm requiring finite storage and time which computes the results of BB(n) for all n. You have to brute-force it for every positive integer n, which takes infinite time (and space) and is therefore not computable.


There is no requirement to have a recurring state when not halting. Indeed, the most trivial machine "write 1 and move right", will never have the same tape state.


Total state, not just tape.

Meaning stack, pointer Location, etc.


First, TMs don't have a stack. Second, still no recurrent state needed.

Extending a state with additional variables doesn't make a unique state less unique anyway, so "total state" is always more or same unique as "just tape".


Some turing machine variants have multiple tapes, effectively registers.

If the tape, instruction position, and all other variables are the same as any previous step, then the deterministic machine is going to continue to find itself in that loop, and never halt.

Think Collatz like functions - if the output starts into a loop, you know the end result.

However, any program trying to detect all loops by maintaining a bloom filter of every previous state doesnt work, that drags any computation down by a scale of its inputs^runtime.


Yes, doesn't change the fact that you do not have to hit such a state to have a non-halting program. I already gave an example: a program that continuously writes to the tape will not stop, and since the tape is always different, will not trigger your loop detection.

It increments its tape position variable. Its never the same state.

State isnt just tape, its all dependent variables.


Exactly, never the same state. And still doesn't halt. That's the point. You cannot detect all non-halting programs by detecting if they go into the same state again. They can, but don't have to.

Note that this casually solves the halting problem, usually a hint that something is wrong.


Is BB(n) "trivially computable"?


Well, it's computable as in there is a function that computes BB(n) for a specific n, but you'll never know which function it is.


But the BB(n) function is essentially the Halting Problem which is not computable?


If you want a function to compute BB(n) for any supplied n, then it isn't computable. But a specific number e.g. 123, BB(123) is just a number and for every integer i there is function const_i that computes i. You just will never know which f_i computes BB(123).

I read this paper several days ago, when my director shared it. Several things jumped out at me:

- the data is mostly from 2025 and earlier

- the baseline mean lines of code per month was 5017, the estimated increase was 1494 lines per worker-month

- the baseline is 5.34 PRs per month, and increased by 1.22

- the baseline mean for code review is 7.03 days

The second and third bullets are confirmation that this is old data. In late 2026, people aren't delivering 30% more lines of code. If people were just producing 30% more lines, they'd still be reading every line. My point isn't that "more lines is good". I'm worried about a few too many lines of code that no one reads. My point is that this shows the data is old.

For the latter, I'm a bit annoyed by using mean, median would be more valuable, but I think it's safe to say that the engineering culture was already pretty bad. If your average pull request sits for 7 days, you evidently don't care about shipping anything, and agents aren't going to change that.


You read the paper, saw that the stated collection dates ranged from January 2021 to March 2026, and are claiming the authors are lying?


If you’d asked reasonably, I might have noted the slight correction (I misremembered that data collection ended January 2026, not March).

But since you’re such a charmer, why did you read the word “mostly” then lie about me lying?

It’s unambiguously true that most of the data (including that on coding agents) is from 2025 and earlier.


Mostly 2025 and before means mostly 2025 and before…


Mostly, meaning “more than half”, or perhaps “noticeably more than half”, both of which are literally true.

Do we speak different versions of English or something? I’m genuinely past being annoyed, I don’t actually know why you think what I’m saying is false.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: