"The only winning move.... is to wipe out all the humans" well that didn't work out as hoped...

It would be nice to stop diverting so much of our resources to so few people for this. Plenty of good work has been stalled/derailed because of the unreasonable consumption of resources by these companies.

They've been trying to create a problem for the solution of Bluefield to apply to, but with limited success.

Here runs into the same sort of problem they have had on other applications they have tried: The visibility of the NIC into the stack is too limited to make especially valuable decisions on.

Unless you get the instrumented stack to cooperate with the DPU to provide more insight, which quickly gets to the question of why bother to have the DPU do the work when it is now subject to the assessment of the host anyway, the host could feed 'bad' data if the host was compromised.

You should reasonably be able to tell the host is trying to reach an IP address. We are at basic firewall. If the host is using good old fashioned DNS with no caching, you might be able to discern with high confidence what the Host header in that TLS stream would be based on spying on the DNS activity (but caching and lots of activity could confuse things), so fancier than a firewall by applying a convoluted correlation. Of course you have *zero* insight into what URL and what method and what payload, because it's just such an awkward position.

This isn't true. It is not a given that an online system has exposed viable vulnerabilities. The more complex the surface exposed, the harder it gets to be confident, but ultimately a secure system is possible even online.

Don't feed into the fiction that a smart enough AI could get into any system it wanted if adequately hardened.

LLM input tends to, above all else, end up *super* verbose, especially when wielded by people that don't actually understand what they are trying to get done.

So while that assessment may stand, the challenge is *volume*. If you see a large LLM contribution, you know it's going to be a slog, and your feedback is likely to be a telephone game between you, the human curator of the work, and the LLM they are actually interacting with, with the human in the middle adding nothing but confusion to the whole thing. If they just stated what they wanted plainly, then the project could have, at their option, used LLM even better than the submittor could have, if it would help.

You have issues like: https://github.com/rhinstaller... Where a detailed rationale is provided, and from a human one would have assumed they wouldn't have had such a concrete analysis unless they had a point, then it turns out that it was LLM hallucinated guesswork with no bearing whatsoever on the reported problem. I've had a few like that where they proposed broken nonsense because the LLM made a credible sounding guess, where their change didn't actually fix the problem, but instead did something pointless or even worse, just swallowed the error message.

Thing was keyboards were *already* ditching the context button. My kid's laptop lost the right Ctrl key, and my kid happened to get used to using the right ctrl key to do shortcuts so it was very jarring when that became the copilot key and had to switch to the other side of the keyboard. Especially since accidentally hitting it was so intrusive.

Thing is that when these sites come up against sufficiently conventionally hardened sites, they already don't really get anywhere.

Problem is just *so* many sites especially during prime hype recklessly move forward without appropriate hardening.

It is sort of like how in the late 90s we had the trope of the hacker kid who could get into anything he felt like if he just wanted to, and nothing could stop them, just slow them down. Brought on by the very real low hanging fruit that the broader public would have assumed to be hard to break into, but were lax in practice. We see the same thing with LLMs, sites that most would *reasonably* assume to be run by smart folks that should protect themselves actually being pretty shoddy in security.

Lots of keyboards ditched more useful keys to fit a copilot key, and then on top of that it's generally awkward to remap back to useful (commonly they replace a modifier key, and mapping some key to a modifier key is usually difficult). Even in KDE trying to make a shortcut out of it doesn't work because it doesn't recognize XF86Assistant,

Well, to me it's funny to hitch this finding to post quantum as it is a totally orthogonal concern.

Along with saying RSA is *totally* useless because a rather niche application of it has an evident weakness, that is not claimed to be more generally applicable.

They may have an interesting and important finding, but are stirring up a bigger mess than is warranted by implying a broader impact to anything using RSA.

If you weren't considering migration from RSA an urgent issue before, this changes nothing.

Depends on what they mean by "the" cryptosystem. If they mean use of RSA in general, then not really, it narrowly only applies to a specific application of RSA allowing an authority to sign something without actually seeing the something, which almost never is done. It sounds like it does not speak to RSA more broadly.

Feel like that's not what is being said at all. It's saying in a world where they are willing to lie about capacity and have the technical ability to do so, they *certainly* would also have the ability to defeat this mechanism to lock out changing the RAM chips.

It just seems on the face of it a bit silly when the reporting is 'they are blocking supply chain BS by blocking ram modules' but at the same time 'but don't worry, you can easily undo the lockout'.

Have to keep in mind that to a lot of folks it's almost 'bitcoin === cryptocurrency', where anything cryptocurrency must be bitcoin related. Not just this field, but investing in general.

Companies have gotten big boosts just by having a similar symbol to something in the news that they had nothing to do with.

I want to agree with you, and appreciate the spin of a 'safety standards committe'.

However, they could make the argument that an agreement to 'slow down' at current prices, means an agreement to keep prices high rather than someone developing an advancement to make it cheaper.

That said, it's completely counter to the trend where they have been making it more and more expensive, and doesn't seem to be interest in more competitive pricing anyway.

We won't have 'our' side under any better control than the other side. Essentially kids playing with landmines, triggering all sorts of unexpected mess while playing with the technology.

I don't even know if you want to consider the likely ones calling the shots 'our' side. For example, a quote from Larry Ellison on AI augmented surveillance:
“Citizens will be on their best behavior, because we’re constantly recording and reporting everything that is going on."

Note the pronoun choices, *their* best behavior (not *our* best behavior) because *we're* constantly recording. Clearly his natural go to language has already set up an 'us versus them' scenario that puts the average citizen on the 'other side' compared to wherever Larry is sitting.

What's worse is that it came up at a time when everything else is hitting economic headwinds. It has become the one shaky pillar vaguely holding up the entire stock market. Hence Trump's panic over the only saving grace of his remaining decent economic indicator being put at risk.