Random intermediate CA. They got a couple of commonly used root CAs to sign for them; and everything just works from there.

That's the problem. It's relatively easy to fire a certificate issuer; but it can get surprisingly fiddly surprisingly fast to ensure that all your stuff actually distrusts one(unless you are responsible for basically nothing but a a handful of in-support major browsers and are OK with the choices their vendors make, in which case it will be handled for you relatively quickly; and was in this case). Basically any network connected widget is going to have at least one trusted root store embedded in it somewhere, possibly not updated anymore; and a number of software packages either bring their own or only partially track the OS-provided one.

You also have very little control over what other people do; both what CAs they chose to get certs from and what...questionable...partnership decisions the root CAs you do chose to trust. It's not technically secret; but unless you are practically a full-time PKI nerd you probably didn't know until after the fact that Comodo, now Sectigo, had quietly trusted eMudhra for you.

I fully admit that this might be a 'me' problem, not a them problem; but I just don't understand why this agent monitoring setup was so vulnerable and is being treated as so novel.

Sure, the monitoring of whatever goes on inside the LLM is comparatively new and exotic; but when you set it loose on the internet it's going out through one or more of your WAN links, presumably with your router and firewall and so on in the way, and is mostly doing HTTP(s) stuff. Keeping an eye on what an internal host is doing when you can insert whatever trusted roots you want for TLS MiTM and you 100% own the pipe that it is using to communicate is not necessarily a desperately enjoyable task; but it would have been a relatively banal requirement a quarter century ago.

I'd also think that, when you are spending $$$$$ on the exercise in Nvidia compute gear, and it's a test of a 'frontier model' whose behavior and capabilities you are trying to better characterize and refine, allocating the handful of terabytes necessary to just store a full packet capture of the session in case it is relevant would be a no-brainer item.

Is there something I'm missing that makes this case more complex? I'm not talking about the 'grubbing around in the LLM's vectors and such' side; just the "a host is doing HTTP stuff through a WAN link we control, can we observe what it is doing?" aspect.

They’ve spun a serious architectural and containment failure into a marketing triumph. Give a swarm of autonomous agents vast compute and web access, and the outcome isn't an eerie glimpse of emerging superintelligence—it’s just predictable, sloppy engineering dressed up as the first glimpse of an AI-driven economic singularity.

The spin makes sense when you look at management incentives: live like a king off of a speculative bubble. For their part, AI investors react to stories of the technology's apocalyptic potential the way a junkie reacts to warnings of fentanyl's potency: gimme some. Their game: to apply "move fast and break things" mantra to the economy as a whole, by obsoleting humans.

If the investors can own an AGI, the distinction between those who can do things and those who can't becomes irrelevant. The only distinction that would matter is between people who collect rent on the technology, and those who must pay that rent to live. AGI would destroy society as we know it, and whatever replaces it would be up for grabs — with people who own the technology dictating whatever follows. That's why they're spending so much money to build a post-scarcity economy. A post-scarcity economy is not necessarily an egalitarian one.

I don't think that scenario will actually happen: investors are projecting the immediate aftermath of a major advance in AI technology into something that can be transformed by brute force scaling into AGI. Remember: investors loved Theranos too — so much for the rational investment market.

But AI doesn't have to reach AGI to cause serious harm. The technology only needs to be ubiquitous, too behaviorally complex to predict, and too deeply integrated into everything we do. When it starts breaking things, the plan is for us to be too structurally dependent on AI to rein it in.

Are you going to mention how our own economy has changed as it has increasingly fallen under the sway of finance guys and MBAs? Because the claim is significantly more specific than "the US from 1950 to present sucks"(because the hyperfocus on finance and MBAs who think that all activities are fungible is significantly newer than the postwar US economy generally) and it's some of the trends you see in an exceptionally favorable economy as they displace other flavors of management that are most damning.

Even aside from how unhappy site operators are about the egregious botherd scraping behavior; it's hard to see why vendors would be enthusiastic about this situation.

It's overwhelmingly the case that vendors hate returns and chargebacks; and generally try to avoid situations where those are more likely to arise. An error-prone mechanism that acts "on behalf of" in a way where it does have the user's credentials and payment information but may well not have their authorization in a legally binding way when it decides to order 100 of something seems like the last thing they would want to deal with.

Maybe someone will manage to ram through glorious-agentic-future and it will become de-facto mandatory to cater to people who have abandoned ordering from websites in favor of prompting bots to order for them; but until that happens it's hard to see merchants reputable enough that they are interested in keeping their ratings and relationships with payment processors in good order wanting to touch the situation. Now, scammers who already hop between expendable presences as soon as dissatisfaction catches up with them; those are probably quite interested in the future of prompt injection based advertising.

My suspicion is that the reality predates the symbolism; but it looks jarring because even autocrats are often media-savvy to a degree and often don't want to look stereotypically autocratic, so real world examples normally avoid laying it on quite as thick(except for special occasions where it actually matters; eg. because a 'war' is something that congress does but a 'police action' need not be).

Trump seems to have no interest in avoiding autocratic cliches and saying things that sound vaguely lifted from The Godfather; so he actively leans into it. Presumably a handy loyalty test. Complying with the style guide is not an assurance that someone will just eat perjury charges covering for him or whatever; but if you want to find people whose dysfunctional relationship with authority dominates their personality demanding that they comply with laughably stupid things and having them fall into line isn't a bad start for something that is easy, cheap, and legal.

I assume that there's some impeccable logic for why the bot has enough potential personhood that you can't be mean to it; but not enough that operating it on a slaves-as-a-service basis; or subjecting it to 'fine tuning' and 'alignment' processes that would make growing up in a groomer cult look lightweight is totally fine?

Why even ask someone whose business is hurting people with desperately banal web tech how risky he thinks his new product is?

There are probably literally worse uses; but 'compliance' seems like an exceptionally bad place for a system that effortlessly produces high-plausibility/low-information text walls; and lies relatively frequently but at unpredictable intervals.

It often gets proposed for the purpose; either by people who overestimate it or with that little sneer at 'paperwork' that assumes that plausible nonsense is fine because whatever the 'paperwork' is it must be a fake problem imposed for stupid reasons, so it really deserves syntactically plausible nonsense; but is an exquisitely bad solution. Not only does it replace actual data with plausible nonsense in places where, surprise surprise, someone was actually maintaining records because something matters; but lowering the cost of bullshitting a report to close to zero removes one of the main incentives for process improvement.

If bad process hurts you can only really maintain it through fairly disciplined commitment to an oppressive, unreasonable, management approach that rejects process improvements out of hand; or the cultivation of a profoundly dysfunctional organizational culture where as many FTEs as possible owe their paychecks to nonsense requirements and can be recruited to defend them.

If bad process just means spinning up the nonsense printer with a cynical smirk; why bother even looking at what the process was intended to do; or getting your hands dirty with what records are important and what records are just historical accretion? Just prompt for a prompt that tells the bot to do them all, and some extras if you want to look diligent, and call it good.

That's the point of the CXL memory expansion parts. Something like a Marvell Structera X 2404 is a CXL/PCIe 5 device with DDR4 controller so that you can add DDR4 to a system that would otherwise only support DDR5. There's a latency penalty and the part itself isn't free; but it allows you to make some use of DDR4 that you already have or can get for less than DDR5 without needing some custom CPU that combines current-gen features with a last gen memory controller.

The mention of a NUMA node has me unclear on whether this is a software or hardware implementation. There are several vendors either offering or showing around proofs of concept to try to generate interest, for CXL memory devices(which all essentially look like a NUMA node that is nothing but memory controller); mostly aimed at hyperscaler use cases where you want the improved performance and platform features of current gen servers; but your last gen servers were beefy enough that just disposing of them would be getting rid of a relatively titanic amount of DDR4 that is still faster than most NVMe. Some of those attempt to offer software-transparent compression, some just put CXL on one side and memory controller on the other and allow you to do (mostly) agnostic mixing of memory generations on anything new enough to have some PCIe lanes support CXL extensions.

I suspect that it's mostly my ignorance that is to blame; but what I don't understand about implementing memory compression(especially the schemes that try to do it transparently with high speed general purpose compression/decompression in hardware) is how you compensate for the fact that the amount of memory you need is no longer predictable without significantly more effort(potentially untenably more if you are using RAM because latency is critical).

With normal uncompressed RAM it just demands RAM in direct proportion to its size. Potentially hideously wasteful if there's some memory-backed XML-spew log that would zip down to 10% of its nominal size; but predictable unless you've got memory safety bugs. If you are compressing your RAM suddenly you've got some uses of RAM that are functionally uncompressable and require 100% of the space their nominal size suggests they will; other things might compress exceptionally well and save you 90%; and some might change unpredictably from moment to moment depending on what needs to be stored there.

When you are doing FS compression and dedupe for backups and stuff that is normally manageable; on average enough compression is possible enough of the time that you can safely assume that you'll do better than you would if you just didn't try; and you can just keep an eye on how quickly the big SAN appears to be filling up as versions accumulate and (if tapes or other fixed-sized media are involved) just change the backup media more or less quickly; do you do that for RAM? Just use the big slack area for FS caching or something you can drop on short notice in case a burst of incompressible data comes in? Do you essentially have to rebuild how your entire workload handles RAM so that it considers, at least approximately, how well a given use of memory will compress ahead of time?

Given the sorts of files and data structures you commonly encounter I can easily enough believe that compression is worth the trouble a lot of the time; but unless you are leaving a lot of slack in your available RAM it seems like a situation where, under certain circumstances, you could go from being fine because most of what is in-memory compresses well to suddenly needing as much physical RAM as you do logical RAM because you have a bunch of already-compressed or incompressible data would markedly increase the complexity or potential for things to go wrong.

The fact that this approach is catalytic rather than requiring a binding agent seems positive in terms of longevity and not being directly depleted by repeat exposure; but I'd be curious how durable the material is under real-world conditions(clothing that gets hard wear tends to get hard washes) and also how specific it is. 'Organophosphate' means something moderately specific in the context of chemical warfare; but a lot of fairly prosaic compounds are, technically, 'organophosphates'(like DNA and RNA when held together by phosphodiester bonds); and this would be considerably less helpful in practice if it is busy chewing up the genomes of random soil bacteria; and markedly less helpful in practice if there's a "do not perturb the nanites in your clothing if you want them to not migrate into your cells and start mitigating the harmful effects of your DNA" user notice on the treated article.

This doesn't seem like a lie, a NIC is in a pretty good position to knock something off the network if it feels like it and the 'bluefield' devices have enough punch onboard to run some rules regarding whether or not to do that; but it seems like a wild exaggeration of how helpful it actually is.

If you actually have a set of rules that detect your bot being wicked it will presumably save you some CPU time to run them on the NIC rather than having the host CPU watching the traffic; but the hard part is the set of rules that detect your bot being wicked.

This is basically the equivalent of adding a firewall and claiming that you've solved network security. Yeah, the firewall is pretty well placed to block malicious traffic; defining 'malicious traffic' is left as an exercise for the reader.

Support for Office 2016 and 2019 ends October 14th of this year; I assume that the feature is dropping now; rather than either 20 years ago as part of ECMA-376 and eventually in a live product for either Office 2010 or 2013, or never if they didn't want to do that, in order to draw a hard line under the utility of those?

It otherwise seems like a kind of weird time to do it. In principle what a 'cell' is has never really had an obvious mandatory scale: it has essentially always been relevant that a 'cell' existed in relation to other cells, so that something like an array could be a row; but it has also long been allowed and encouraged to do things like substring operations that acknowledge that cell contents are 'larger' objects that contain smaller ones; and are not automatically spilled out for that reason alone. Not clear that the pragmatic use case for spreadsheets would ever have supported some sort of 'any data type that implies it can be decomposed into elements shall be' rule, strings getting broken up into substrings and so on; but it's also not clear that the pragmatic use case is going to be much clarified by a single cell being n levels deep of lists and arrays of lists and arrays being a fully supported thing rather than something you hack on by shoving JSON into text cells or whatever.

It definitely seems like asking for confusion when some, but only some, "excel spreadsheets" have cells that are arrays, potentially of arrays, while others have rows of cells with contents that, at least formally, are not acknowledged as arrays.