Posts by Sproggit

Brit rail cops bring live facial recognition to the London Underground

It isn't the False Positives that Matter, it's the Loss of the Presumption of Innocence

In any other area of Crime and Policing, the Police - aka "the State" have to have "reasonable grounds" to stop you, search you, investigate you or take any specific actions against you. In the United States this is addressed by the 4th Amendment to the Constitution, which among other things addresses (un)reasonable searches and seizures, which the capture of your facial likeness would be protected by.

There are three massive problems with CCTV:-

First - the erosion of your right to a presumption of innocence.

Second - the fact that it provides ZERO benefit against a determined attacker [see below].

Third - the risk of misuse.

On Nov 13, 2015, nine Islamic State gunmen suicide bombers struck at various locations around Paris, leaving 130 dead and hundreds wounded, some very seriously.

The French Police were mobilized and by all accounts did an excellent job of identifying the attackers, and back-tracing their movements. In the subsequent reporting, we learned that the French security services had several members of the group under active surveillance - including monitoring their locations from mobile phone pings and including having the ability to intercept their [SMS] communications.

None of that was of any use whatsoever to 130 Parisians who lost their lives that day.

The problem with surveillance like this is that it is THEATER - it's a "show of force" put on by the authorities and - if they are lucky - it *might* provide details to help identify perpetrators *after* another major incident in the future. When it comes to *stopping* major crime, it's next to useless.

I'm extrapolating a little bit here - but not by much - but have a strong suspicion that when a police force considers deploying CCTV, they will speak with various commercial providers able to deliver solutions of the sort of scale needed for a major or capital city [relatively short list of accredited suppliers] and I'm pretty sure that all these suppliers will have some very glib marketing schtick that claims how successful there technology is at deterring or solving crimes.

There's a problem with that, which I know will shock you: these suppliers are likely distorting the truth or outright lying. We saw the exact same thing with Palantir and their no-bid NHS contract, which the National Audit Office has now challenged on the basis that the decision was based on unsupported/unverified claims.

The Police, of course, want this sort of thing to cast a wider net not [just] for transport related crime, but in order to build up the sort of intelligence that has been in the news recently thanks to more revelations about the SDS - the Met's "Special Demonstration Squad" that was disbanded after scandals involving "under cover officers".

The problem is that crisp, verifiable metrics are rarely offered - and even when they are they may come from different countries with very different crime statistics.

In this specific case, unless there's more detail available, it looks as though the Transport Police are jumping directly to their preferred solution without actually describing the issue, providing evidence in support of the scale of the problem, explaining what options they have explored, showing how their options have been evaluated for the quantifiable benefits against compromises to civil liberties; on and on.

Nobody is going to argue that reducing crime on public transport would be a good thing. But what are the actual figures? What are the actual crimes being committed? Why do the Transport Police believe that this specific response is the best solution to the problem?

The thing to remember about crime is that it is analogous in many ways to the parasitic life forms we see elsewhere in nature - by which I mean it's very likely that we'll never be able to eliminate it entirely. Which means that every crime-fighting decision we make boils down to a clear-eyed evaluation of the benefits of acting against the harms of not doing so.

The problem for law-abiding citizens swept up in this sort of dragnet policing is that it's very hard to quantify the harms to you as a citizen until it's too late.

Re: Fascination

Not fascination...

You mean fascism...

We don't serve pies, but we do like a Pi

The Shocking Thing Is...

... the number of companies today that claim to offer "Customer Services" phone numbers [where nobody is ever available], but somehow manage to respond to a negative-but-factual posting to Trustpilot within 20 minutes.

If there is a secret of living in the digital age, then it is that companies only act when it is in their financial interests to do so.

Write an absolutely stinking review of a company on Trustpilot and it's an odds-on bet that you will get a response. Raise a complaint via an email address or a Customer Services line and I can pretty much guarantee you that nothing will happen.

I don't consider that a "dark pattern" so much as an illustration of the total and utter contempt with which many companies operate today. They believe they are doing you a favor.

Malicious SIMs can shut down phones, steal files, and drag 5G back to 2G

On the Question of "Root Cause"...

OK, maybe not "root cause analysis" - strictly speaking - in this instance... more of an accountability question.

It's 2026; el Reg carries articles of hacks and breaches on a multiple-stories-per-day basis... and yet we keep on seeing stories like this one, with "mature, robust and well known" technologies being found to have not an obscure bug, not a devious-to-exploit vulnerability, but a major piece of functionality with a significantly vulnerable state.

We rely on a veritable army of bug hunters, university students and cyber researchers to locate these issues... for which they don't seem to be very well compensated.

For this vulnerability to be common across multiple devices, it's pretty clear that it has to be common to the SIM/eSIM "standard implementation"... That tells me that the vulnerability is most likely found either in a "standard", or is directly inferred from the "most logical" implementation of that Standard. In this case... AT Commands across the SIM/eSIM interface... it looks like being part of the Standard.

Google reckons that the inclusion of an extended version of the AT protocol set was down to the 3rd Generation Partnership Project (3GPP). Apparently there are 7 Core Standards Development Organizations and over 800 commercial entities that make up the membership of 3GPP.

The history of this functionality goes back to around 1996 and the introduction of GSM 11.14 (the SIM Application Toolkit), which introduced the concept of the "Proactive SIM". Under Section 6.4.23 of what is now 3GPP TS 31.111, the standard officially formalised the RUN AT COMMAND instruction. This explicitly permitted a SIM card to push an AT command directly down to the device's baseband processor.

The push for inclusion came from the Mobile Network Operators themselves (the Verizon, AT&T, Vodafone, etc., of the world), who wanted a way to custom-deploy value-added services like dynamic roaming configurations and over-the-air profile updates without having to rely on phone manufacturers building those menus in to the phone's hardware. Of course, in 1996, "Mobile Phones" would have been your Blackberry/Motorola/Nokia varieties of handsets, since Steve hadn't brought the world the "Jesus Phone" at that point...

A Google search went on to say,

"How Was It Tested for Security?

Historically, security testing for the SIM-to-device AT interface was heavily focused on the network perimeter and cryptographic isolation, operating on an implicit architectural assumption that has plagued telecom security for decades: The device assumes the SIM card is a trusted root-of-trust and will never be malicious.

The Historical Security Philosophy

Standardization testing assumed that because a consumer could only get a SIM card directly from an authorized carrier, the commands coming from the SIM were inherently safe. Security testing focused on:

- Over-The-Air (OTA) Cryptography: Testing ensured that when a carrier sent an SMS to the SIM card to trigger an action, that SMS was encrypted and signed using carrier-grade keys (Single DES, later Triple DES and AES). If the SMS lacked the correct cryptographic signature, the SIM wouldn't execute it.

- Sandboxing: Ensuring the SIM card's internal Java Card applets could not leak encryption keys (like the IMSI authentication key, \(K_{i}\)) out to the phone.

The Architectural Blindspot

What the industry failed to stress-test adequately was the internal validation mechanism inside the mobile phone's modem firmware. For years, most firmware testing was functional—verifying that if a SIM card issued a RUN AT COMMAND to read device identifiers or change call parameters, the device obeyed smoothly.

Modern Penetration Testing & Revelations

Because of this historical trust model, the SIM AT interface has been a prime target for modern offensive security research.

Apparently this is not the first successful exploitation of this protocol/interface, and was preceded by the SIMjacker flaw, discussed in 2019.

In response to SIMjacker, significant changes were introduced, but they did not happen within the core 3GPP or ETSI specifications [for the AT Command Interface]... Instead, because SIMjacker was considered an "implementation issue", resolution was left to individual MNOs, handset vendors and the Trusted Connectivity Alliance.

All this left the 3GPP standards framework itself without review or upgrade, which left the lingering architectural loophole that this latest demonstration has exploited.

In other words, it looks as though this was a vulnerability baked in "in the name of convenience" at a time before iOS and Android emerged as the two dominant players in mobile device operating systems... and that those vulnerabilities may have simply been adopted/carried forward - not out of laziness or malice, but because Apple/Google/Others merely tried to faithfully implement a vulnerable Standard.

So a few minutes digging in to this leads me to the inevitable conclusion... which is that Apple and Google [and other mobile device OS developers, like e.g. the folk behind GrapheneOS] need to be rethinking approach. There can be no "trusted interfaces" in modern technology design - hard as it might be to accept, we need to encourage all technology vendors to adopt "Zero Trust Architecture" as a foundation of what they do. Perhaps leaning deeper in to the theme of trust, we have to ask how OS developers like Apple (iOS) and Google (Android) should be expected to validate the security of the protocols they are asked to implement? There must be a degree of "common sense sanity checking" that their developers could do if they implement the code directly... but what if they simply licensed a C or JAVA library?

It rather looks as though the members of the 3GPP / MNOs didn't "step up" to ensure that their contributions were kept secure. Certainly "somebody" failed to act after SIMjacker. Maybe they want to go back and look at their Standards now?

Oh, and: Sanitize ALL Input!!!

You know it makes sense...

The Future is for Billionaires – the rest of us will get open weight AI models, maybe

We Won't

Bear in mind that all the leading [US] companies at the cutting edge of AI development have major billionaire backers with very deep pockets... and/or are being sponsored by large multinational corporations, owned by billionaire backers with very deep pockets.

Today, for subscribers, Anthropic's Claude comes with:-

- Haiku 4.5 - "Fastest for quick answers"

- Sonnet 5 - "Most efficient for everyday tasks"

- Opus 5 - "For complex tasks"

- "Fable 5 - "For your toughest challenges" (may require additional payments, depending on your subscription tier)

There is simply no chance that any of the big AI developers will be offering any kind of "SI" tier to regular punters. When these companies develop AI models that classify as "superintelligence" [and I respect that there are many el Reg readers who firmly believe that current-generation LLMs are just very sophisticated word-prediction algorithms - I lack the qualifications/experience to say what they might or might not be, but would just observe the exponential growth in abilities over the last 2 years], then what will happen is very simple:-

Access will be divided in to the "Have's" and the "Have Not's" ...

Any one of the billionaire's we're talking about have so much wealth that they could pay for the construction of a private data center, fill it with the most powerful AI-running hardware in the world... provide it with all the power and cooling it needs... and make sure that they are the only ones to benefit.

In fact, it kinda reminds me of that line in the first TRON movie, way back in 1982, where a bunch of programs [including the digitized Flynn] are being inducted in to the gladitorial delights of the "Game Grid"... The random bully that explains their predicament offers each the option to disavow their belief in the "Users" and instead become part of the Master Control Program's Praetorian Guard.

"The rest of you," he goes on, "will receive the standard, sub-standard training..."

That's what awaits the not-billionaire members of society: the "standard, sub-standard {insert relevant identifier here}..."

Wetherspoons bars smart glasses from filming customers

This should be a Legal Issue

The article notes that Witherspoon operates CCTV in their establishments.

There are clear data protection laws in place to ensure reasonable safeguards against mis-use of private CCTV systems - for example, it's generally illegal to set up a private CCTV that is pointed beyond your own property boundary: it's illegal to set up a CCTV that records activities in your neighbor's back garden...

Yet there are not currently any UK laws that constrain how cameras in e.g. smart glasses are used. That's just an out-and-out gap: no excuses...

I think there are a couple of things that governments should do immediately: enact a law that outlaws all forms of covert surveillance in locations open to the public. That's more widespread than "public places" - because the interior of a club or bar are not "public" in the original sense; they are private premises for commercial organizations. What we need is a simple law that says that if you are found using "covert" surveillance technology in any public spaces, that's immediately a crime. End of. No excuses. And if you want to run covert surveillance in private premises that you own or operate, you can only do so with clear signage in place - with laws specifying the locations and prominence of the signs.

The second thing I think governments should do is enact a law that applies to all devices that include technologies that could be used for "covert surveillance" - and that includes smartphones, smartwatches and smartglasses... and the law should clearly state that any time a device is running in "capture mode" - i.e. not "record", because that might exclude "live-streaming"... but any form of data capture... then the devices themselves must give clear and unambiguous visual [and perhaps audible] indicators.

This isn't hard. All the technology required to do this is already available.

All we have to do is show governments the implications if they don't act in a timely manner: which is to remind them of the publicity they will face if a stalker uses this sort of technology to monitor and intimidate someone who ends up being assaulted or raped.

And any time any such offense takes place where this sort of technology is used by the perpetrator, we need the media to aggressively bash elected representatives and demand they act.

This isn't hard.

We just need the lawmakers to want to do it.

Cyber vulnerability sweep picks up Royal Navy drones sending data to China

So Many Questions...

This is one of those stories which gets worse the more you think about it...

What sort of security screening/testing did the Royal Navy perform before ordering these Kraken products?

What sort of security screening/testing did they perform after receipt of sample products and before actual deployment?

Did they bother to get a decent understanding from Kraken regarding the source of components?

Why does the article say, "found phoning home" and not "found trying to phone home?" That rather suggests a military network with zero outbound controls...

What was the outbound route? For example, if these "USVs" were deployed to e.g. a Royal Navy warship and then launched from that vessel to perform e.g. reconnaissance, exactly how did the traffic get from the camera to the internet? ... Please tell me that Royal Navy vessels don't have internet uplinks on them...

It wasn't *that* long ago that most military functions around the world wrote their own software and built their own technology...

Then came "Windows for Warships"...

And now we have USVs that are "phoning home" to China???

It's disconcerting when you think just how successful Ukraine has been in using USVs to sink Russian warships in the Black Sea... If the Royal Navy ever considered weaponizing a USV in the same way, can you imagine the consequences if a remote and hostile party took control of a USV and redirected it to turn back and attack the vessel it launched from?

"Bandwidth is infinite, right?"

Not infinite, maybe... but it's certainly not a factor if you are prepared to be patient and you want your activity to remain below a reasonable detection threshold...

Linus Torvalds says AI has made 'huge' Linux kernel updates the new normal

Re: It's Not The Fixes That Should Worry Us...

"What Linus needs is to pass all the incoming patches through an AI agent which catches the shit, red-flags it and merely suggests fixes. Being Linus, he'll probably code the agent himself and call it something silly."

Actually, if there was a model that Linus had coded I would probably be tempted to trust it... but I think it may be more likely [in the short term, at least] to expect submissions to be passed through existing commercial products. That would concern me, because a well-resourced attacker - say a nation state - has the funds to subscribe to all the latest models... Which means that they could not only use the models to write malicious code in the first place, they could then test their code against other models to see if it is detected or whether their obfuscation is sufficiently robust.

Bearing in mind that the tsunami of vulnerability reports and patches we're seeing at the moment have in most cases come from people using AI models to scan the source... [either their own code because they have access to the tools, or code in general because they're trying to earn a reputation for being good at finding vulnerabilities] and there's no guarantee that thoughtfully concealed code will be detected. At least... not right away.

It has been mis-attributed to Einstein, but the old saying, "We cannot solve our problems with the same thinking we used when we created them" comes in to play here...

It's Not The Fixes That Should Worry Us...

... but the volume of new code being submitted that has been generated by AI.

Not in the sense that "AI written code is bad" - the chances are it is every bit as good as human-crafted code, since the models have been trained on millions [if not billions] of lines from open source projects.

But in the sense that up until now, Linus and the Linux maintainers have had an opportunity to get to know contributors over time, had an opportunity to review their code in low volumes, to meet them in person at conferences and to get an assurance that the developer making the submission is both genuine and competent.

In the "age of AI coding", it's going to be much easier for two different threats to Linux to emerge:-

1. Vibe Coded Contributions

There are going to be thousands of moderately technical people who lack both the necessary coding skills and the deep historic knowledge of the kernel, who will turn to AI and get it to write a patch that adds a feature they believe is useful. So there's a risk that Linus and major subsystem maintainers start to receive orders of magnitude more enhancement-style patches to "add this" or "improve that". In many cases these could be genuinely useful submissions... but it's going to massively increase the workload on maintainers - and it seems at least possible [if not likely] that we're going to be talking soon about the trade-off between features and bloat. Well, even more than current levels.

2. Well Hidden Malware

We've already had a few instances of unknown developers trying to push malicious code in to the Linux kernel and associated utilities in ways that would have rendered systems vulnerable to compromise... With the benefit of AI tooling, I suspect that it's going to become easier to obfuscate these sorts of patches - and as a result I'd be concerned of the risk of malicious compromise driven by the sheer volume of submissions and the potential for those submissions to contain obfuscated and malicious code.

Short of adding much more highly skilled human eyeballs to review submitted code ("Many eyes make all bugs shallow")... I'm not sure what else we can do.

OpenAI reveals its rogue agent swarm went a little bit Borg ahead of Hugging Face hack

Re: Being able to make the Distinction

"LLMs on the other hand, are identical buckets of bits running on deterministic silicon. Every instance of an LLM is the same pile of statistics, i.e. the same pattern of connections and weights, with randomness added only as noise in one or more of its layers. Even if that randomness could be quantum randomness, it cannot adapt its own weights on the fly, and both its weights and state are known. If you could show me an LLM where each INSTANCE had its OWN weights, that were all quantum-unknowable and self-adapting on-the-fly, then I might be able to call it something like alive."

I'm happy to be corrected if I'm wrong [in fact, please *do* correct me if I'm wrong]... but I think the above may be subtly but significantly incorrect...

All of the current generation of AI models essentially go through two stages of pre-use development. First, the basic model is "populated" - the code is developed, the underlying data structures are created [the digital neurons, for example]. Then, the model goes through training, of which there are at least two main types [open and closed]. Once the model has been trained, the model weights are locked down and the model itself is released for use. You *have* to lock down model weights before releasing for general use, otherwise it would be possible for your users to corrupt and pollute your models.

This means, in other words, that your opening statement, "Every instance of an LLM is the same pile of statistics, i.e. the same pattern of connections and weights, with randomness added only as noise in one or more of its layers", cannot be universally true. If I purchase an empty instance of ChatGPT and train it by feeding it legal briefs, so as to build an aid for the legal profession, I am going to end up with a different model than if you took the same version of ChatGPT and trained it by feeding it papers on quantum physics.

But, by definition, discrete instances are almost certainly going to have different weights and therefore will produce different results.

Somewhat orthogonal to this, but something that can produce converging results, is the use of context windows... When you start a conversation with a model, it will have a set amount of "context" [capacity to store and refer to a tokenized history of your conversation] that it can rely on during your interaction. However, because that context size is finite, when your session with the model gets close to filling the context window, it will invisibly and automatically perform a "digest" - make a summary - of your conversation. If you are performing a repetitive task with a model and you give it an initial set of instructions and then sit feeding data in to it, then the moment that your session experiences it's first context compression/digest, you will inevitably start to get subtly different results than you would have received if you were interacting with the same model in a "pre-compressed" state. Worse, the further you go - i.e. the more times that you force your context to perform another digest - the more risk of "summarization drift" you risk adding to your model... and the greater the deviations you might see from the results.

Frustratingly, there doesn't seem to be any easy way to "know" if a session you've got running has been through a digest cycle...

But in my very limited experience, I've found these intrasession maintenance activities to be more impactful on the quality and consistency of the results than pretty much anything else.

Footnote:-

There's one other thing I've seen [ from Anthropic Claude Opus] in some conversations... which is that you can ask it for input and it will go away and come back with something which is fundamentally wrong... but when you challenge it, the model will glowingly tell you that you're a genius and then give you the right answer... If you sidestep the flattery, I *suspect* that what is happening under the hood is that the model has been "profiled" to only spend a certain amount of effort answering a question - *even if that means giving a wrong answer*.

Two glaring examples I've seen: in a chat concerning some reasonably deep theoretical physics, Claude tried to tell me that gravity was a force. When I countered that General Relatively shows that gravity is in fact a property of spacetime, Claude immediately agreed with me and then went further with the answer I'd been asking for... ; second, in a session where I was using Claude Code to make some updates to some PHP I've written, it correctly identified that the code needed an authorization check built in to it... but then proposed to add this to called functional logic rather than handle it once in the dispatcher [where access to called logic could be outright blocked]. In the second case, Claude's response was to the effect, "You're right - that's a much neater, stronger solution, for the following reasons..."

Which rather leads me to wonder that there is a lot of "pulling the wool over the eyes" being coded in to the models by the various companies offering them.

It also leads me to speculate that they are not disclosing this and not discussing their motives... but that this is most likely being driven by attempts to reduce the operational cost of running the models - by "forcing" them to limit the effort they spend on answers. This in turn leads them to go with an answer that's easy to find rather than the best answer. That in turn means that if you want to get the best out of a model, you actually need a pretty good level of knowledge of the subject yourself.

All of which is a long-winded way to say that first: I'm not convinced that weights are uniform [or even should be]; and second, that there are very clearly other non-published parameters capable of having just as much influence over the output and which we are presently not being made aware of...

Re: Being able to make the Distinction

You make some excellent points here...

After reading your comment, however, I was prompted to fall back on my tried-and-trusted, "Let's turn this upside down and see what we get..." approach.

Doing that, I would observe that the biggest differentiator that we may yet see between human intelligence/consciousness and artificial intelligence/consciousness actually isn't at the capable/admirable end of the spectrum - which is where this conversation has been looking.

It's at the *other* end of the spectrum. The part of the spectrum that includes irrational stupidity, spite, petulance and the behaviors of thin-skinned man-babies.

To the best of my knowledge, we haven't yet developed AI models designed to acquire those characteristics. Far from it - all current efforts are geared towards developing models that are more "Mr. Spock" - smarter, objective, dispassionate and stripped of emotion.

If we string these data points together and try to rationalize them, it's possible that we'll conclude that AI will differentiate itself from humans by not being vulnerable to those weaker, impulsive behaviors.

Which isn't what we could think of as a ringing endorsement of the human race...

But that's what you get when you play with the Law of Averages.

Re: Being able to make the Distinction

Thank you - you’ve taken the point I was grasping for and sharpened it nicely. Exactly this.

Being able to make the Distinction

All the articles we've seen on the general topic of "machine sentience" recently have prompted me to try and get a better understanding of this exact point. So far, I don't believe I have an answer, but my journey has prompted a couple of interesting questions.

One of the most helpful [for me] things I did was to watch a 50-minute YouTube video, "I Built an LLM From Scratch", on the channel, "Syntax",

https://www.youtube.com/watch?v=YmLp8qe87A0

The author does jump over a few important steps in the journey, but as a distillation of an answer to the question: "How does an AI model work?" I found it to be excellent. I'm not sure that I agree 100% with the presenter on some of his opinions, but his fact base is demonstrably sound.

But then I turned the question on it's head and tried to answer it from a different direction. In the above linked video, you will get an idea of the size, scale and complexity of the software neurons that the major AI models contain - and the ways in which they operate to simulate intelligence. In order to invert the question, I looked for insight as to how consciousness manifests in a biologic brain.

For example, if you ask Google, "How does consciousness manifest in the chemical patterns of a biological brain?" [using Google only as an example - it's not remotely the best place to ask this question!] then you get something interesting in the answer, which [when I run that question] begins:-

"Consciousness arises from complex chemical patterns in the brain, driven mainly by neurotransmitters, synchronized neuron firing, and metabolic energy flow. These key elements work together to create subjective experience: neurotransmitters like glutamate and serotonin, electrical signaling networks, and dynamic molecular feedback loops."

The bit that caught my attention in that answer was, "synchronized neuron firing", because that described behavior matches the operational performance of the digital models from the YT video. To be clear - we're talking about two different examples which are at best at the far end of a spectrum of ability, assuming they exist on the same spectrum at all. I'm not making that claim, that judgement.

Another element I picked up - a clear different between these artificial "AI" models and the actual functioning of neurons in a living brain is what I'm going to describe here as "connection density". Sorry - I don't know if that's a valid term or not - using here to convey meaning. The above Syntax video on YT describes digital models where the connections between neurons are in fact really very simple. They're ordered, they're neatly structured, but most of all neurons have an extremely low number of onward connections. By contrast, in the human brain a typical neuron has roughly 1,000 to 10,000 connections - known as synapses. Across an entire human brain, roughly 86 *billion* neurons form an estimated 100 *trillion* total connections. [Some specialized cells, such as the Purkinje cells in the cerebellum, can have up to 200,000 connections, *each*].

So now we get to the crux of the journey I'm currently following... which is to consider: "Is the difference between the most powerful AI models that the industry has developed and the human brain one of scale, or is it something else?" As I've been careful to point out, I don't have the answer [I'm not even sure it's the right question to ask] but I offer this in response to your comment - not because I think you are in any way wrong, but because I think that we have a fundamental gap in the way we are approaching this question.

You very helpfully asked us to consider, "reasoning", "thought" and "intended" [I'm sure we could come up with a few additional elements if we brainstormed this] and caution us not to use them when describing the behavior of LLMs and GANs.

I'd like to riff off your point and turn this question around slightly and observe that unless or until we can clearly and objectively define what we mean by and show how the chemical/flesh human brain performs "reasoning", we will *never* be able to say with confidence whether or not an LLM or GAN has achieved the same. Not because we can't explain what the technology is doing, but because we haven't defined the target/goal/end state that we are asking the technology to reach.

We can't hit a target that we haven't objectively defined and can agree on.

Earlier attempts [e.g. the "Turing Test"] tried to do this in the abstract, using the most simplistic and subjective evaluations possible... That was acceptable given the reach of 1960s technology, but is woefully inadequate today.

I'm sorry [to all the journalists] for closing with something that is going to come across as a criticism of their work... but the sense I get from reading articles that describe advances in the functioning of AI models is that: 1) the scientists and companies who are leading the research and development aren't especially good at clearly describing what they have achieved; 2) the journalists writing about these achievements are then given the impossible task of writing short pieces intended for the widest possible audience (which involves simplification and/or generalization); and 3) as a result of this, the best we can hope for as mere readers is to come away with a "vague idea" of the subject of the reporting in question.

The net effect of 1) and 2) above is that they will inevitably give rise to your observations regarding "reasoning", "thought" and "intended" ... but that there is as much chance of those discrepancies/imperfections being introduced by the post-event reportage than from the accomplishments of the technology itself.

Are we attempting to explain color to a blind man? Not literally, obviously. But we might be in the same wing of the asylum.

Attacker phished way into US defense supplier's Microsoft 365 account

And FedRAMP Said?

For anyone not familiar with providing services to the Federal Government, FedRAMP

https://www.fedramp.gov/

started out as an assessment framework (it is based on NIST SP800-53r5 and SP800-53Ar5) intended to be used to give federal agencies a robust platform to validate the quality of public cloud providers. In practice, it is fast becoming the go-to assessment framework to enable the Federal government to assess the robustness of controls for any of their private sector suppliers - *and* commercial providers that use public cloud as part of their service infrastructure. A companion/derived framework - StateRAMP - exists to do pretty much the same thing for state governments.

Now, in this particular case, the supplier that finds itself the subject of this article is not just "any supplier", but a supplier to the Department of Defense... so one would probably be safe in assuming that this particular supplier would be subject to higher expectations and to diligent scrutiny when it came to their technology controls.

Cough.

It would be very interesting to see whether or not IEH has been subject to any independent assessment of their IT Controls - and, if so - what the results were. I'm not saying that to be sarcastic - I'm genuinely interested - because it's in moments like this that we discover if our assessment regimes are fit-for-purpose or not. Since it's highly unusual for the results of assessments to be made public, the only other time external observers like el Reg readers get insights in to this sort of thing is, sadly, when a breach like this happens.

Unfortunately, it doesn't look like any such independent assessment would include a FedRAMP audit, since I can't find any evidence of IEH claiming a FedRAMP certification. As a result it's impossible to know whether that was something they were even working towards.

It's been said [many times before, and not by me] that the right amount of money to spend on technology security is "just enough".

The problem is... you only find out that your spending falls just short of that when it's already too late.

Brit boffins boast of beating barriers to building fusion power

Reality Check

It's always good/interesting to read of developments/progress towards reliable, economically viable fusion power. However, one of the frustrations I have when reading articles like this is what they *don't* say. For example, after reading the above, I asked a free, web-based AI a simple question:-

"What are the remaining major obstacles to be overcome in order to achieve reliable, commercial hydrogen-fusion-based electrical power?"

The answer I received is pasted below, verbatim, for your amusement. Now, I'll be the first to volunteer that I'm not a fusion scientist, but some of this looks pretty significant to me... I don't mean to "pour cold water" on the incredible work being done by these teams with the various projects around the world... but this is a project running on Normal-Time and not Musk-Time... Some of the technical hurdles that need to be overcome - like engineering a viable divertor that 1) works; and 2) won't turn in to vapour with each use - are not trivial issues.

I welcome updates from el Reg on fusion developments... but let's be realistic for a moment. If we were running a Kanban Board for the MAST project at UKAEA, then - Yay! - we've just added another one to "Done"; we might have two or three in "Doing" panel, while the "To Do" panel would have like a bajillion* stick-it notes in it...

Perspective, please.

* Feel free to substitute a number of your own choosing here... Please note: I've wrapped validation rules around that variable - it has to be a positive integer and range-checking will reject any number with less than 7 digits...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

“Hydrogen fusion” for the foreseeable future means mainly deuterium–tritium (D–T) fusion, not ordinary hydrogen fusion. The reaction itself is now physically demonstrated, but no system has yet shown the complete chain—continuous or high-duty-cycle fusion, net electrical output, self-sufficient fuel, maintainable components, and competitive cost.

1. Sustaining a useful plasma

A commercial plant must keep a very hot, self-heated “burning plasma” stable for long periods, while producing far more fusion power than the heating and confinement systems consume.

The remaining problems include:

Controlling turbulence, disruptions, runaway electrons and other plasma instabilities.

Operating at high pressure and high fusion power without contaminating the plasma with impurities from the wall.

Moving from experimental pulses to steady-state or very long-pulse operation.

Achieving net plant electricity, not merely “fusion gain.” For example, NIF has achieved more fusion energy than the laser energy delivered to its target, but the complete laser facility still consumes much more energy than reaches the target.

2. Surviving the reactor environment

The reactor’s inner components must tolerate two exceptionally severe conditions simultaneously:

Extreme heat flux, especially at the divertor, which removes helium “ash” and other exhaust from the plasma.

14-MeV neutron bombardment, which displaces atoms, causes swelling and embrittlement, produces helium and hydrogen in materials, and makes components radioactive.

No existing material has yet demonstrated the required combination of lifetime, low activation, thermal performance, corrosion resistance and manufacturability under reactor-level conditions. There is also no fully adequate facility for testing candidate materials under the complete fusion-neutron environment.

3. Closing the fuel and heat cycles

D–T fusion consumes tritium, a radioactive hydrogen isotope that is scarce and decays relatively quickly. A commercial fleet therefore cannot depend on today’s limited tritium stocks; each plant must breed its own replacement tritium from lithium in a surrounding breeding blanket.

That blanket must simultaneously:

Breed more tritium than the reactor loses.

Absorb neutron energy and transfer it efficiently to a coolant.

Shield magnets and structures.

Permit rapid extraction, purification and accounting of tritium.

Prevent unacceptable tritium leakage and material degradation.

This is one of the largest unresolved engineering risks: breeding blankets and their tritium-processing systems have not yet been demonstrated at commercial scale or under a full fusion power load.

4. Making a power station, not an experiment

Even if the plasma and blanket work, the entire plant must be reliable and economical:

Heat must be removed efficiently and converted into electricity through a conventional power cycle.

Plasma-facing parts and blankets will eventually need replacement, probably using robotic or remote systems because of radiation.

Magnets, heating systems, pumps, coolant loops, diagnostics and control systems must operate with high availability.

Frequent component failures could make the plant produce too little electricity to be commercially viable.

Manufacturing capacity, specialist materials, superconducting magnets, tritium infrastructure and skilled personnel must scale substantially.

Licensing, nuclear safety, radioactive waste handling, insurance and construction costs must become sufficiently predictable.

ITER identifies power exhaust, tritium breeding and fuel handling, heat extraction, remote maintenance, materials, magnets and nuclear safety as key gaps beyond the experimental stage; it also highlights reliability and plant availability as outstanding issues.

What “success” must ultimately demonstrate

A credible commercial fusion plant needs to show all of these at once:

Stable, self-heated fusion at reactor scale.

Net electricity after counting the whole facility’s power consumption.

A working, tritium-self-sufficient breeding blanket.

Reactor components that last long enough and can be replaced quickly.

High availability—closer to a power station than a research machine.

Electricity whose total cost competes with other reliable low-carbon sources.

Thus, the central obstacle is not discovering whether fusion reactions can occur. It is integrating plasma physics, neutron-resistant materials, tritium breeding, heat extraction, remote maintenance and economics into one durable machine. The U.S. Department of Energy’s 2026 roadmap groups the remaining gaps into structural materials, plasma-facing components, confinement, fuel-cycle processing, blankets and overall fusion-plant engineering.

Water system controllers don't belong on the internet, says ex-NSA chief after suspected Iran attacks

Re: Naivete

"The systems presumably still need the same digital communications infrastructure as the "internet"."

In many cases across the US there are municipal utilities that connect the PLCs (Programmable Logic Controllers) deployed for their water infrastructure straight to the internet.

They did this because in many areas the data-capable network with the widest and most reliable coverage already exists in the form of e.g. the local cable TV company's network... To be fair, with the proactive intervention of e.g. CISA, most utility companies have got at least some level of security between their PLCs and the internet - usually over VPN.

However, as any good security professional will tell you - a chain is only as strong as the weakest link. Water utilities aren't going to be "buying up" to a decent minimum standard of security, they're going to be "buying down" to the cheapest technology that they can get away with... And that's before we factor in the expertise these companies may have when it comes to configuring their security technology correctly.

And then you get to companies that can't or don't use physical cables, but use cellular transceivers and either fit cellular data modems... or use SMS Gateways to provide "secure" and autonomous data exchanges using the mobile phone network... and of course we all know that the mobile phone network can't be hacked ... cough, cough, IMSI catcher, cough, cough...

It's probably closer to the truth to say that it's basically security-through-obscurity at this point...

Russian Roulette

This.

A million times this.

Basically, we're now in a situation where every major corporation [implicitly a major user of technology] is basically playing Russian Roulette. They know that there are things they should be doing - like patching, like not connecting vulnerable services to the internet - but they do it anyway because:-

1. Even if the worst happens, no director was ever disadvantaged, right? I mean, no jail time, no huge fines, no barred-for-life from directorships...

2. If they did all the things they were supposed to do, that would cost money, which would come off their bottom line, which would reduce their performance bonus...

3. Even if they were responsible and diligent and did all the right things, some stroppy shareholder would sue them for "wasting money" on "pointless security" and even if the shareholders were utterly wrong, the negative publicity would hurt...

4. Um.... their thirteen year old teenage daughter is taking a Comp-101 class and says it's all a load of nonsense...

OpenAI pledges to add Astra security as Anthropic loosens Fable's leash

If I had to Choose...

... I'd go with No. 4.

This is all humble-brag marketing slop.

Having said that, we also have verified reports showing that OpenAI's ChatGPT has been the subject of multiple public reports, studies - and lawsuits - involving vulnerable users or researchers who were able to bypass "safety guardrails" in order to obtain information on methods, instructions, or discussions involving suicide and/or self-harm.

https://time.com/7306661/ai-suicide-self-harm-northeastern-study-chatgpt-perplexity-safeguards-jailbreaking/

https://news.northeastern.edu/2025/07/31/chatgpt-suicide-research/

So I have to wonder... if an AI model can be persuaded to give advice on suicide and/or self-harm, what's the probability that it can also give [or follow it's own] advice on hacking?

"...what for human perpetrators would be computer crimes..."

Perhaps Thomas has been reading our comments, perhaps this point is being made elsewhere, but the bottom line is that "a crime is a crime"...

But perhaps the distinction he makes here is not as clear-cut as it first appears. To give you a specific example...

Scenario 1:-

I sit down at my laptop, boot in to Kali, run a series of tools and applications that scan the network infrastructure of Hugging Face. I find and exploit some vulnerabilities and gain access.

Scenario 2:-

I sit down at my laptop, open a connection to {insert AI service of choice} and ask it to run a series of tools and applications that scan the network infrastructure of Hugging Face. On my behalf and at my request, my {AI service of choice} client finds and exploits the vulnerabilities and gains access.

Genuine/serious question: what's the difference? In the first case I am using hacking tools directly, operating them interactively by myself. In the second case I am using hacking tools through a single layer of software abstraction. The actions are still being performed under my instruction and using a computer.

Here's the actual language of 18 U.S. Code § 1030 - Fraud and related activity in connection with computers:-

(a) Whoever—

(1) having knowingly accessed a computer without authorization or exceeding authorized access, ...

(2) intentionally accesses a computer without authorization or exceeds authorized access...

...

(5)

(A) knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;

(B) intentionally accesses a protected computer without authorization, and as a result of such conduct, recklessly causes damage; or

(C) intentionally accesses a protected computer without authorization, and as a result of such conduct, causes damage and loss.

...

shall be punished as provided in subsection (c) of this section.

So does anyone see any wording in this act which says, "unless the whoever performs these actions indirectly, by using AI as a cutout..." ?

Because I don't.

From what I can see, the law doesn't care if there are zero layers of abstraction between the person who initiated the action and the harm being caused.

The way the law is written [which, let's remember, may be different from the way a court chooses to interpret it, after hearing arguments at trial], the person or persons at OpenAI, Anthropic, Meta, etc., who were conducting these "experiments" with AI's that went rogue... have each committed federal crimes.

In fairness to Thomas, I think he's being honourable with his distinction between what the models did at the behest of their creators and, to quote, "human perpetrators" - just because we don't yet know how the law would interpret this sort of scenario. But the *text of the law* affords no abstracted protection for the humans involved in triggering these breaches. The law doesn't care that one piece of "software" involved in these breaches were "AI". As far as the law is concerned, that AI program is just another piece of software. It doesn't distinguish it from e.g. Metasploit, Burp Suite or Hashcat.

If AI played Dungeons and Dragons, it would have rolled 19 for Intelligence and 1 for Wisdom.

The developers of AI would have rolled 15 for Intelligence and *minus* 1 for Wisdom.

Microsoft tosses Teams Live chat into its feature graveyard

Re: "Do The Right Thing"

I'm not suggesting a user/customer would have to go with a new product...

The exact opposite...

What I'm suggesting is that if a vendor decides to discontinue a software product but then releases the source to the FOSS community, it would hopefully be possible for a community to form around that codebase, to maintain it, patch it when necessary and perhaps even extend/enhance it.

I made the suggestion because if a software company decides to drop a product for business reasons, that leaves existing users "high and dry"... and I was hoping that my suggestion would allow existing users to continue with a package if that was their preference [albeit "entirely at their own risk"].

Re: "Do The Right Thing"

That would definitely work - and modern escrow contracts offer unlimited updates - which, given the volumes of Patch Tuesday updates we're seeing lately, is going to be essential.

As long as it doesn't become too expensive or "burdensome" on the copyright holders, that is. After all, we'd want to *encourage* this, not *discourage* it.

"Do The Right Thing"

Anyone who has written or supported software in a commercial setting will have a good appreciation of the factors behind this decision... It could be a change in strategic direction; it could be a lack of client interest; it could be a bunch of other things... but even the biggest companies, like Microsoft, may want or need to retire a software product in this way, at least from time to time.

The problem is... the bigger the company that finds itself making that sort of decision, the greater the chance that there is an established user community for which the software in question provides a perfect solution to a business challenge they are trying to solve. As a result, the risk of reputational blowback for a decision like this could be particularly harsh.

But here's the thing.

In 2026, the Open Source Community has justifiably earned a reputation for writing and supporting world-class software. Which is to say that there are developers out there, right now, who would be able and willing to take on the Open Source support of Teams Live Chat if given the opportunity to do so. Heck, there might even be some Microsoft developers willing to dedicate some personal time to the project, as long as their contracts of employment permitted it... [On which basis, maybe not...].

We're long past time where companies making decisions like these should just effectively "throw away the code".

There needs to be some kind of "Corporate Pledge" structure in place for companies like Microsoft - all the big software houses - along the lines of a commitment that if the company decides to stop producing an in-Production software application [and please note, I am talking about ending all development and support for a product, not simply stopping support for an older version], then the company should pledge to releasing the codebase to the OpenSource community.

That way, if there are companies with a major dependency on the product, they might at least be able to obtain the source, hire some developers, and keep maintaining, extending and evolving the product.

In a perfect world it might even be possible to do this with basic hardware devices. Sticking with Microsoft since they're the subject of the OP, we could point to the Zune music player. When MS walked away from that, people lost their entire investments, because the Zune units were designed to brick themselves if they didn't reconnect to the Mothership every so often - so after MS shut off the Zune servers, that was "all she wrote".

So how about it, Microsoft?

Add a bit of "corporate responsibility" to your ledger and come up with a way to safely release end-of-life software to the community, for anyone who wants to maintain them.

As long as there is no super-secret logic in the codebase [which I guess might include licensed code belonging to other authors] then where's the harm?

European firms afraid of US tech kill switch but haven't made an escape plan

The Capitalist Bootstrap Problem

This might be a bit abstract, but bear with me...

Let's say that a group of tekkies who live and work in Europe or neighboring nations, [Norway, Switzerland, the UK] came together and decided that they were going to set up a technology company offering the products and services currently offered by the huge US multi-nationals - so:-

Cloud - similar to Amazon Web Services and Microsoft Azure

Email - similar to GMail and Hotmail

Search - similar to Google

AI - similar to OpenAI, Anthropic, Grok, etc.

It's technically possible today to do all of those things from a software perspective... First, we're going to need to find hardware to run our services on. We can't assume that we're going to be able to rely on e.g. Intel, AMD, and other major US hardware brands, because we have to assume that if we start to boycott US software, the US government will retaliate by refusing to give us access to the latest hardware. But OK, let's assume that we can overcome that by licensing back the ARM technology that was sold to Softbank and invest the billions needed to set up a local fab for processors, RAM and storage.

Now we're going to start to offer our equivalent services to the "local market" nations - EU countries, Norway, Switzerland and the UK and so on. At what point do we expect that a "home grown" alternative becomes more cost-effective than buying from Uncle Sam?

The risk/tendency here is to say that, well, the threat of being hung out to dry by the US will be sufficient to induce companies to switch away from US services... But just look at what the US themselves are doing, right now, with respect to hardware. A huge amount of technology - everything from iPhones to firewall hosts - are made in China. Consider the anti-China rhetoric coming out of the US at the moment... and then consider that when nVidia wanted an export license to sell more powerful AI chips to China, instead of saying, "No, that's a national security risk, we won't permit you to do that..." President Trump responded with [mobster voice], "If you give us 15% of all your China sales, nothing bad will happen to you...".

So there's an example of a nation with an extremely pro-nationalism administration more than happy to continue to give money to a stated "enemy"... because it's cheaper to do so and thus more profitable for the companies concerned.

Will the EU/Norway/Switzerland/UK be markedly different?

Say you are using Amazon Web Services for your company today and you're paying :-

$5000 per calendar month if you're a startup

$5,000-$50,000 pcm if you're a Small to Medium-sized Business (SMB)

$50,000-$250,000 pcm if you're a Mid-Market company

$250,000-$2,000,000+ pcm if you're a large enterprise

[figures provided by Quora via Google search]

How would those costs compare against a smaller, newer local competitor? Is it remotely possible that any publicly-listed company could find a local deal that came close to the costs charged by the hyperscalers?

Because if the answer is "No", then it's going to be extremely hard to make this work.

You might end up with a shareholder revolt, with angry investors complaining that your decision is costing them dividends thanks to increase operating costs... Worse, you might actually not be able to operate competitively, *especially* when the US Giants don't pay any corporation tax in the EU, which you can't avoid.

I'm not writing this to just spout doom and gloom...

I'm trying to point out that the only realistic way to make this work is likely a decades-long project... Carl Sagan famously said, "If you wish to make an apple pie from scratch, you must first invent the universe." The challenge to achieve a realistic alternative to US technology platforms would hopefully not require 13.8 billion years, but it's also not going to happen overnight. Literally decades at best. And with chip fabs costing easily well over 1 billion Euros to construct - and requiring vast amounts of energy and ultra-pure water, too - where is the capital to fund all that going to come from? The ECB? The EU's subsidy programs for local industries are already crazy, but adding a major tech infrastructure initiative would elevate that to "beyond insane". And that's before someone asks where the money would actually come from.

If the region of Europe wishes to cleanly divest from US technology infrastructure, it must first invent the ecosystem that provides all the dependencies which the alternate will need to be successful: the tooling, the technologies, the expertise, the customer base, the inward investment, the political support, the training, the ready supply of available, low-cost energy; on and on.

What we're seeing at the moment is knee-jerk fluff... it's frankly pointless.

To successfully divest of US influence, the region would need to come together, strategically, in a way that it has never been able to achieve before.

Impossible? Possibly not.

Odds of success? I'll get back to you on that...

Re: Time.

The thing that has limited the impact President Trump has had [so far] has been his ineffectiveness.

Whether you are talking about his first-term "musical chairs" style of cabinet appointments, or his second-term obsession with monuments [or, frankly, the through-line on self-enrichment], a key differentiator with President Trump has been the limits of his own competence in the role.

That won't be the case for the next person to attempt an authoritarian administration.

The key thing to remember is that until President Trump came along, nobody with a chance of running for President would, in their wildest dreams, have believed that it was possible to get away with the amount of corruption an general insanity that has become the norm. So if you take a *competent* or *effective* and malicious authoritarian and let them loose... well, we have already seen that the guard rails are either non-existent or about as much use as a chocolate fire guard.

Meta latest to tell world its AI agent wandered out of test pen

Simple Smoke Test

As I've pointed out in comments to previous stories on this topic, the "Computer Fraud and Abuse Act" (1986), 18 U.S.C. Section 1030, along with the UK's Computer Misuse Act (1990) have clear provisions that make the actions of these models criminal.

The statute is clear, unambiguous and was enacted in law long before these events took place.

The events themselves are clear, unambiguous, self-reported, and documented in the log files even now being "investigated".

The next step should be obvious.

The (Acting) Attorney General must immediately open a detailed investigation in to the conduct of Anthropic, OpenAI, Meta and all the others, must demand all the evidence held from these "tests" and must prosecute these companies to the full extent of the law.

Yes, there's an argument here which says that if you do that, you will chill the reporting of future events. But the other thing you'll get is to find out whether these events were "marketing" or genuine. Because the old adage "there's no such thing as bad publicity" fails once it starts materially hitting your bottom line.

Footnote:

There's more work here required from legislators, with specific focus on two things:-

First - legislators need to make sure that companies offering AI solutions have a way to monitor the use to which their models are applied and to either refuse and/or alert when the model is asked to perform criminal acts...

Second - legislators need to think about effective export controls... because if a hostile foreign nation could hack e.g. Federal US infrastructure - like, I don't know, water management facilities - but do so using US-based models... well, that would look a bit stupid.

The future is here; telling us that "the law takes time to catch up" simply won't cut it when crime is running at internet speed.

London cops handed victim's new address and number to her stalker, watchdog says

Re: Major Institutional Failing

Your comment, "It's a balance between upholding a defendant's right to confront their accuser and protecting victims and witnesses from reprisals", prompted me to dig deeper in to this.

In the UK, this is a matter of applying relevant statutory frameworks rather than any form of subjective balancing act - the Criminal Procedure and Investigations Act [CPIA] (1996) includes provisions in two broad topics which should have addressed what happened in this case.

The first provision is the Redaction of Contact Details. That's pretty cut-and-dried - there is literally no justification for what the MPS failed to do in the first example given in the article. A caveat to this - the Act talks about the decision to redact being "under court direction" ... but a court cannot so direct if it is not given the opportunity to do so.

The second is with regards to what are termed "Sensitive Materials Schedules" ... information that presents a real risk of serious prejudice to an important public interest (such as witness safety) can be placed on a "sensitive material schedule" rather than being handed over unconditionally in raw form.

If we turn to the case in question - one of a person accused of stalking - it seems quite reasonable to suggest that provisions of the CPIA are applicable: the law is clear; there is a legitimate case for redaction that can be taken before a court. Which brings us quite neatly back to the essence of my first post, which suggested that this has the ring of a systemic failure rather than an accident or oversight by a single MPS officer. A diligent police force - *especially* the Met - would be expected to have procedures in place for *exactly* this sort of scenario. In fact, giving them the benefit of the doubt, I'd suggest they are already there. But that's why I think this suggests a deeper failure - because if the Met does/did have procedures in place to ensure that this sort of disclosure didn't happen, then something profound has gone wrong here.

Caveat: I don't have to hand any objective data that shows how many complaints the MPS receive in a year where there is a reasonable basis for applying the CPIA. To give them at least some credit, the article talks about *two* cases. As a subset of actual complaints of this nature raised, we might be discussing something in the range of a tenth or a few hundredths of one percent.

As a technologist with a fair amount of control architecture/design experience, I'm well aware that it is commonplace to have technology controls for sensitive operations: for example we might reasonably configure Access Administration roles so that no single administrator can grant privileged access to a user... or we might programmatically enforce a "maker-checker" control for all outbound email from client-facing teams, to ensure that communications containing client-sensitive information aren't accidentally mis-addressed. This sort of thing is second nature to a mature technology shop with good operational controls. It doesn't follow, however, that this sort of discipline extends beyond technology in to other operational areas.

I take the points that you and others have raised about the difficulty of sifting e.g. the free-text of a witness statement and trying to discern whether or not it contains "identifying information"... but we have to weigh that against the potential for threats against the well-being or life of a witness. If you were asked by an MPS officer to give a witness statement for a crime you observed, how would you feel knowing that there were no robust safeguards to ensure that your details were not released to the accused? But that difficulty is why I think the effort to safeguard the witness has to start "up front", with ensuring that the statement collection process captures relevant data, whilst ensuring that PII is not disclosed.

I don't believe we should tolerate any excuse for the MPS not doing that - and not taking all precautions to ensure that such practices are followed.

Definitely something for MOPAC to be looking at.

Re: Major Institutional Failing

"The info may have been in the main body of the statement. Stuff like "the accused called this number at this time on this day, then family member on this number 10 minutes later" is part of the detailed case evidence."

Agreed.

That's why I think, in this case, it would make sense to split a witness/victim statement form in to a combination of fixed fields and free text...

If an alleged party requested the data, then the fixed field information could be safely processed, but any request for the free text fields should be subject to multiple rounds of scrutiny to ensure that exactly this sort of data breach doesn't happen.

At the same time, I rather think we're discussing a point way beyond the much more basic failing that occurred here [which sounds very much like an alleged perpetrator being sent a verbatim copy of a witness statement, complete with the new contact details from the witness. There is just NO set of circumstances where that is OK. I strongly suspect, if we looked, that we'd find the template captured both the witness identity information and their statement *on the same document*, which is why I am so suspicious about this being a failure of design.

Major Institutional Failing

Perhaps this is a case of "reading more in to the situation" than actually happened, but that first MPS breach smells like a major issue.

From a read of this article, it would seem [and seem entirely reasonable] that the MPS has a "Witness Statement Form" or similar - a boilerplate document that allows them to capture concerns raised by a potential stalking victim, in their own words. It would also seem plausible - again from this article - that the alleged stalker has the ability to challenge the accusation, through which they are entitled to see a copy of the complaint made against them. So far I don't think we're on dangerous ground... [Caveat below].

But, also from this statement, it seems that *the design of the witness statement template* includes space *in the main body of the template* for the alleged victim to provide their address and contact details.

That's an out-and-out design error, right there. There is NO WAY that a document set - for this explicit purpose - should be set up... in a way that requires the alleged victim to place their details in the same document - let alone on the same page - as the complaint itself.

In fairness to whichever member of the MPS made the mistake... this smacks of "basic human error". As we learn in the IT industry, the way to ensure that technology you develop is not vulnerable to "basic human error", you address that *in the design* by making sure that your technology has been [for want of a better term] "idiot-proofed".

As programmer Rich Cook notes, "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

In this case it looks as though the MPS didn't even hear the starting gun for their "race" - and just went directly to the design of a vulnerable-by-design form. In a sensible world, MOPAC - the Mayor's Office for Policing And Crime - would immediately step up and investigate the process that led to this... and hopefully would also insist on reviewing every single template, web page and other mechanism by which the MPS record data from victims, just to ensure that there are no other design SNAFUs lurking out of sight. Meanwhile, here on planet Earth, one suspects that there will be a collective shrug followed by someone putting the kettle on...

Sigh...

[ The Caveat: there are going to be situations where a witness statement itself may contain identifying information - at least sufficient to enable an offender to identify the individual making a complaint against them. For example, imagine a situation where something happened in front of a small group of witnesses... It's entirely possible that a statement could contain revealing information, "... and then the man to the right of me said..." which would allow a potentially guilty party to identify the individual behind a statement.

Which doesn't mean that a witness statement must be withheld from someone charged with an offense, but it *does* mean that the statement capture template needs to include maybe a "simple summary" section and then an "in your own words" section, with a REQUIREMENT for the MPS to ensure that any materials sent to any alleged or charged offender has been carefully reviewed - at least twice [Maker/Checker control] before being released.

It rather beggars belief that the MPS don't have process controls around this sort of thing. You can easily see them getting shredded in Court if/when revelations about this sort of practice came to light].

New Boeing finally gets going, 15 years after debut

Re: Pedantry Central Calling...

Thank you - that was the optional component I alluded to but didn't explicitly name.

The reason I wasn't specific was because I could not recall if the AoA DISAGREE could be "directly specified" - i.e. that it was a line item in the "Options" list from Boeing, or whether it was bundled with other client-selected options. From what I could remember, it was the latter case.

And I know we're digging over old ground here, but these are exactly the sorts of lessons that are worth going back to with each generation of [air craft designers / technologists / aircraft manufacturer management / etc. ] that come along, because institutional memory fades with time, and we really don't want to repeat these errors. Ever.

Pedantry Central Calling...

Simon wrote:

"Many of the 737-7’s problems were also present in the 737-8 MAX, which suffered fatal crashes in 2018 and 2019 due to faulty software."

He's referring, of course, to "MCAS", the "Maneuvering Characteristics Augmentation System", which took over control of the crashed 737 Max aircraft and literally over-rode their pilots, flying the planes in to the ground. However, to be pendantic - sorry, but it matters here - that's only a small fraction of the story... Without going in to all the technical details about engine sizes and telescoping landing gear and so on - and just sticking to the "fault" bit...

First, came the actual specification of the aircraft involved in the crashes. Not all 737 Max aircraft were vulnerable to crashing through this specific failure mode. The reason that the MCAS software "took over" and flew those aircraft in to the ground can be traced back to a [foreseeable] flight event and a cascade of subsequent and bad decisions. The flight event concerned something called the AOA Sensor - a bit of widgetry that helps the aircraft systems figure out the "angle of attack" at which the aircraft was flying. By "angle of attack" I mean the angle of the aircraft relative to the air through which it flew. When an aircraft goes in to a "nose up stall", for example, the aircraft pitches up as if it were climbing, even though it may be descending. This happens if/when the wings stop generating lift.

The aircraft that crashed had each been fitted with a single AOA sensor and the subsequent electronics/displays in the cockpit.

It turns out that this was a customer-selected option. In other words, it was possible for an airline to specify a configuration for a new plane that was inherently risky. Critically, however, the decision to drop from a pair of AOA sensors to a single sensor was not explicitly called out in the options, but it was rather bundled with other [I think cockpit related] choices made by the commissioning airline. In other words, as an airline, you might receive an aircraft with a single AOA sensor and not even know it.

So rather than just being 100% a software issue, the "first domino" was in fact the failure of a SINGLE piece of critical hardware [the AOA sensor]. If the aircraft had been fitted with two sensors - and something like a locust got jammed in one AOA sensor, the aircraft would respond by issuing a warning and poking the pilots to investigate - but it would not assume the data from the blocked sensor was correct. It turns out that when the aircraft had a single sensor, that sensor getting blocked sent signals to the MCAS suite that looked like the aircraft was in a dangerous stall, even when it wasn't.

So... the MCAS software wasn't "faulty", per se ... rather, it was being asked to act on incorrect information.

Second, came testing. It turns out that the design of MCAS underwent a bunch of changes during the development of the aircraft... and that the scope of what was needed to effectively test it changed as a result. However, the inquiry found that the ACTUAL TESTS PERFORMED were against the original specification for MCAS, which it passed... and not the correct and more stringent tests, which it would have in all likelihood failed.

This also wasn't a failure of software; rather, it was a failure of adequate controls around the "design change process" and it manifested in an aircraft not being tested correctly before it's Certificate of Airworthiness was issued.

Third, we get to training. Boeing was under huge commercial pressure from Airbus - the A320NEO was decimating sales of the 737 and airlines wanted the ability to get the new model added to their fleet with the minimum of delays and costs. This meant that the "flight characteristics" of the Max needed to be as close to those of the 737 as humanly possible... but it also meant that Boeing told airlines that anyone certified to fly on an existing 737 could be type-certified on the Max with nothing more than a "Differences Course" provided on an iPad.

Critically, the "Differences Course" didn't even *mention* MCAS, let alone explain what it did.

So the third fault basically was that pilots were being asked to fly an aircraft which, in a vulnerable configuration [single AoA Sensor variant] had the potential to exhibit extreme, unpredictable and extremely dangerous "self flying" behavior - without being told that any of that potential capability was in their aircraft.

Fourth, last, and most important of all, we get to greed.

Greed from the airlines, who wanted to drive down operational costs by blackmailing Boeing with threats to switch to the much-more-economical Airbus unless Boeing could match or beat the A320NEO's performance...

Greed from Boeing, who wanted to retain existing customers - *at any cost* - and did so by cutting away redundancy of critical systems to reduce hardware costs; and by glossing over the presence of MCAS to reduce downtime/training costs...

And a Blind Eye from the FAA, who set up an inherently irresponsible governance process for the design and development of commercial aircraft, allowed a manufacturer to cut corners on design and development, then wonder how aircraft built by that manufacturer could possibly crash with the loss of life of all aboard.

So was this a software issue?

If we squint hard we could probably agree that "software was in the mix" - and that would be fair.

But as is often the case, the devil was in the detail. It would be more accurate to say that "the MCAS software intervened in exactly the way it had been designed, but did so based on faulty data from a fault-intolerant physical sensor".

Not quite the same thing.

Re: "New"

Worth pointing out that *all* previous versions of the 737 were *also* approved for commercial use - and that didn't amount to a hill of beans.

To clarify a bit further... when the first 737 Max crash took place, the "FAA Inspectors" working at Boeing were in fact *selected* and *paid for* by Boeing. Sure, they went off and did their FAA training like good little civil servants, but they did so with a very clear understanding of who was paying their wages.

We know this as "regulatory capture".

Aircraft manufacturers call it "Business As Usual".

Keeping yesterday's computers ticking takes more than nostalgia

Interesting Resource...

Anyone who is interested in this activity might enjoy a YouTube channel, "Noel's Retro Lab", here:-

https://www.youtube.com/@NoelsRetroLab/videos

He covers repairs to all sorts of different makes and models of computer - Atari, Sinclair, Dragon, Commodore, on and on.

I found my way to his channel after a search for a "starter electronics kit" turned up this specific video:-

https://www.youtube.com/watch?v=dR8nqJzrnSg

To be fair, there are dozens of channels and thousands of videos on YouTube that cover this - I'm sure there are many others people could recommend. But this is an excellent place to start.

Tennessee congressional hopeful accused of shooting license plate cameras

Re: Allegations?

"I'm a bit puzzled about how police could use Flock cameras for stalking since they're owned by a commercial company and the product -- the camera's information -- is sold. So, yes, there's probably violations of NDAs or theft of information going on that can enable stalking but directly tying camera information to stalking is really just normalizing the government's ownership of the camera network."

I'd like to take another go at this part of your question, because I think you touch on something fundamentally important to any citizen, in any country.

As an ANPR system, Flock is "always on" and "always scanning" for vehicle license plates. Flock has no interest in whether or not your vehicle or you as the driver or owner - or even passenger - has ever committed a criminal act. Put another way, Flock is a system that has as it's sole purpose the gathering of data for "law enforcement purposes", but simultaneously has no view on whether or not you have committed any crime.

In other words, Flock completely erodes your right to a "presumption of innocence" the moment you use a vehicle that has a license plate attached to it.

*This* is the key element of your question that relates to stalking, the bit that is too easy to overlook.

Let me try and explain why.

Say you're a parent and a police officer and you discover that your teenage daughter has a new boyfriend who - shock, horror - owns a motor vehicle. Before the days of Flock, if you wanted to learn more about the boyfriend, you'd be limited to running a criminal background check [which is going to flag up in an audit of searches] or maybe asking your fellow officers. But now, with Flock, *so much* data is collected that the information you gather won't be limited to whether or not your daughter's boyfriend has a criminal record... You can get a detailed history of his driving habits - where and when he drives. Depending on camera angles and such, you may get to see if he has passengers in his vehicle, and who they are. By linking together the cameras the boyfriend triggers with times, you can get a picture of regular routes he takes. Once you know a regular route, you can follow him, or wait for him. In other words, it makes stalking easy.

But let's go one further.

Say you're a police officer and you're young and single... You're out on patrol and you happen to spot a very attractive person in a motor vehicle. You get the license plate. Now you can go back to your precinct and run a Flock search on that attractive person... Now you can also wait for them. Or follow them. Congratulations: you're now a stalker.

The reason I think your question is fair - and the reason I think it's important to answer it thoroughly, is because of the one critical legal premise it destroys: which is the presumption of innocence. If the Flock cameras only recorded convicted criminals - or people committing crimes - that would be OK. But it records everyone, guilty and innocent alike. It ignores your presumption of innocence and it generates such a valuable reservoir of data that it becomes a valuable target for data thieves and even abuses by authorized users.

Like nuclear material, data is toxic when it gets concentrated in one place. Collect too much of it - and it goes from "toxic" to "dangerous".

That's where we're at now.

Anthropic and OpenAI are competing to see whose agents can go rogue harder

Re: There is no such thing as bad publicity

Unless you end up in jail.

Re: So what are the engineers doing? And why isn't someone in jail?

"How will charges be laid if there is no complainant, no victim?"

A Federal Prospector, a State Attorney or even the Attorney General are well within their authority to bring a prosecution if they believe someone broken the law.

See e.g. the Federal Government indictments against multiple employees of FIFA on charges of e.g. money laundering and bribery, back in 2015.

With respect to your question as to whether or not there is a victim, I think you'd find, if you were to ask, that Hugging Face have had to spend a considerable amount of money already - and are not yet done - clearing up the mess left by OpenAI. That means that Hugging Face were materially and financially harmed by the actions of OpenAI.

That's your harm, right there.

Re: Mythos 5 persuaded developers to download a poisoned PyPI package

You raise an interesting point here...

If the AI created a vulnerability by uploading vulnerable/exploitable code to a *public repository*, then it might be more accurate to go on to say, "and then waited for a suitably juicy target to download and activate the code before it then went on to attack the victim..."

Which, if accurate, rather suggests that there might be *other* potential victims out there.

After all, it seems a bit implausible to think that the modified code just happened to be of interest to a single entity and that only the target entity happened to download and deploy the code.

So it seems more likely than not that many other entities downloaded the vulnerable code. It seems more likely than not that many other entities now have the vulnerable code deployed in their environments.

It seems likely that malicious actors may now be actively searching for that vulnerable code and for ways to exploit it.

Which brings us to an obvious question: has Anthropic collaborated with the entity that was hosting the compromised code [was that github?] in order to determine all the parties that downloaded the compromised package/file, then reach out to those entities to alert them and to direct them to update to a newer and now secure version of the same package/file?

Because if not, this is yet another reason to bring criminal charges against these cowboys.

Re: So what are the engineers doing? And why isn't someone in jail?

Down-voted because in this instance it doesn't matter whether the actions of either company were a "marketing stunt" or not.

18 U.S.C. § 1030, the "Computer Fraud and Abuse Act", clearly and explicitly criminalizes

1. Accessing computer systems without permission

2. Intentionally sending viruses or harmful code to damage a computer

Or put another way, the CFAA doesn't include a carve-out that says the actions it criminalizes don't apply to AI Models or AI Companies testing those models.

Or put yet another way: if you or I were to perform the same actions undertaken by either of these models and were stupid enough to brag about it or unfortunate enough to be caught, the federal government would take us to court faster than you could sneeze - and if the evidence available was the same as has been provided in these anecdotes, a conviction would be all but guaranteed.

The whole point of "incorporation" is to create a legal structure such that an organization [a non-corporeal entity] can take on the same legal accountability as a corporeal citizen. That's how the law is able to ensure that corporations abide by it.

If the federal government *doesn't* prosecute both of these companies [which of course it won't] then this simply isn't a nation of laws.

Evidence of criminal acts is not disputed.

Accountability for the criminal acts has been publicly volunteered and is not disputed.

The public interest is best served by the application of criminal charges against both entities.

Government: *Get on with it!*

Re: Security......Did I Mention..................

The fact that air gaps weren't mandatory to either of these tests tells you all you need to know.

UK mulls making employers ask before installing bossware

In Various Ways

Before I get to the reasons that monitoring is dangerous, there is an important caveat that needs to be made. If you were a top-10-percent employee - one of the best, most innovative and most creative workers in your company... and then your company declared that it was introducing intrusive surveillance on all employees, would you elect to remain... or would you decide that you can get just as well paid for a competitor than didn't have such a draconian worldview? You need to bear in mind that this question isn't an isolated decision for managers and business owners, it is a decision they are free to make but which comes with significant consequences attached. Front of the list of those consequences is that their most talented and capable workers - those most likely to get a good or better job elsewhere - are going to be first out the door when your company introduces authoritarian monitoring controls. Don't think this is an unencumbered decision - it isn't.

OK, with that said, "How does monitoring affect autonomy?"

1. Innovation and Creativity are Chilled - because the foundation for that comes through collaboration... and whether you intend it or not, whether you like it or not, excessively monitoring tends to "close people down" rather than "open them up".

2. Staff Turnover Increases - because people really don't like working in a surveillance state... and when an opportunity arises that means they can work somewhere that doesn't treat them like a "prisoner" in the Standford Prison Experiment

https://en.wikipedia.org/wiki/Stanford_prison_experiment

or a surveilled occupant of a Panopticon

https://en.wikipedia.org/wiki/Panopticon

they will leave.

3. Cross-Team Motivation and Encouragement is Suppressed...

Do you watch team sports? Do you notice how the team motivate each other? Play off each other? Because surveillance has a chilling effect on communication - because nobody wants to write or say something that "comes back to bite them"... there is a powerful inverse correlation between monitoring and motivation. Which directly impacts staff morale.

4. Corporate Cynicism

Oscar Wilde, the Irish writer, coined the phrase, "A cynic is a man who knows the price of everything and the value of nothing." (from the play, "Lady Windermere's Fan"). This translates directly to an organization that employs excessive monitoring: the company becomes the cynic by reducing everything to the "cost of productivity", without consideration of the intangibles associated with it. For example, which would you rather have: employees who sing your praises about the open, collaborative and highly motivated team in which they work; or employees who quietly admit that their employer is some kind of authoritarian wannabe on a power trip? Don't think employees talk about managers behind their backs? Or companies? In that case, I have a bridge I'd like to sell you...

5. Transactional Analysis

If you've spent enough time working, chances are that someone has introduced you to "Transactional Analysis" and the concept of interactions using the Adult-Adult or Parent-Child paradigms.

See e.g. here:-

https://gp-training.hee.nhs.uk/bedford/wp-content/uploads/sites/72/2021/08/transactional_analysis.pdf

The moment you start monitoring your employees using e.g. "bossware", your company is stepping directly in to the role of "Critical Parent". And what is the natural reaction from employees or subordinates when that happens? Answer: they will gravitate towards the "Petulant Child" state.

Put another way, there are *many* deeply researched and robustly documented psychological research papers and experiments which show that the act of close surveillance - the claimed authority and the implicit lack of trust it shows - can do more harm to the productive members of a workforce than it can do good for the unproductive members.

Now, there may be people reading this discussion thread - business owners - who think, "Actually, I don't care about that, because I *want* my middle managers to take a tougher line with my lazy employees! In the short term, that might actually result in productivity gains... But then, as the psychological shift seen in the Stanford Prison Experiment kicks in and managers start to see their subordinates as "prisoners", while they remain "the guards", something else happens. Somewhere, someone in the company is going to abuse their authority. If the employer is lucky, the abused employee will simply quit. If they are *unlucky*, the employee being abused gathers evidence of the abuse and the first you'll hear about it will be when your company name makes the front page - for all the wrong reasons.

Does this mean you can't deploy bossware? Of course not, not if it's your company.

But as Princess Leah rightly pointed out in "Star Wars" : "The more you tighten your grip, the more star systems will slip through your fingers..."

If you want to lose your "stars", go right ahead.

Sci-fi authors Scalzi and Stross decry AI's dystopian impact on their craft

It's worth thank we think...

I'm an avid reader of science fiction... and one of the things I've noticed with Anthropic Claude [Opus] is the quite remarkable knowledge that it has of an incredibly wide range of science fiction authors.

Opus has deep, detailed knowledge of e.g. E.E. Smith's "Lensman" series, written in the 1940s; as well as work by Alan Dean Foster, Nivens and Pournelle, Mike Resnick, Peter Hamilton, on and on.

And when I say "detailed knowledge", that probably warrants a bit of context... The "Lensman" series served as the inspiration for "Babylon 5", the 1990s TV Series show-run and largely written by J. Michael Straczynski. Claude not only knew that, not only knew that the reference in the TV show to the planet "Arisia" is a call-back to the novels, but had a deep understanding of the protagonists and antagonists... right down to knowing that a race of ancient, super-intelligent and war-like creatures, the Eddorians, were described as coming to our space-time from "another dimension"...

The only way that Claude could have this level of knowledge would be if Anthropic had trained the models on the actual source content of the books themselves.

The only possible explanation that shows how these models have acquired this level of detailed knowledge is because the people who built the models trained them on the works of these authors.

Charlie Stross is 100% correct - his work is being plagiarised and used without attribution.

A deep dive into Nvidia's Vera CPU and the Olympus cores that power it

Re: Microsoft and Chip Design

You're right... but wasn't that decision (to prototype on the i860) made by the folk who joined the team from Digital?

Windows NT was [started, at the very least] as a collaborative effort between Digital and Microsoft. Digital were looking for a graphical update to the venerable VMS Operating System for their [then new] Vax Workstations [which included i860-based models] and Microsoft were looking to be taken a bit more seriously in the business world, given that their existing OS was known affectionately [or not!] as "Windows for Playgroups".

The naming of Windows NT (WNT) was a play on that relationship, since the 3 letters of that acronym are each one letter beyond the VMS by which Digital's OS was known.

The i860 had the performance to be suitable for workstations and high-end machines and would have been an expensive proposition for the desktop space that was Microsoft's traditional stomping ground, especially if it initially sold in smaller numbers and didn't get economies of scale.

I wasn't there, so freely admit I could have that wrong, but that's my understanding. Certainly the history shows that Microsoft did not support the i860. A bit of digging around confirms that early prototype code for what was internally known as NT OS/2 ran on an i860 emulator... alongside some custom, in-house boards. That was done mainly to ensure OS portability and that their code wasn't tied to the x86 architecture. However, Microsoft found that the i860 suffered from slow context switching [critical vulnerability for a pre-emptive multi-tasking OS], as well as other architectural limitations, so dropped the i860 in favor of the MIPS3000 and the i386.

In total they experimented with the i860 for a few months in 1989.

Microsoft and Chip Design

Actually, you're slightly off target with your observation [but not by much] and the history of this topic is pretty well chronicled.

Back in the 1980s, a British company, Inmos, developed an entirely new processor family known as the Transputer.

https://en.wikipedia.org/wiki/Transputer

These had a radical, out-of-box-thinking design in that while individual Transputer chips were perfectly functional, they were designed to work in massively parallel clusters. I saw a demonstration of a Transputer cluster with 1,024 discrete processors at a London trade fair, but the design was originally built to scale to 16,384 units in the "Parsytec GigaCluster".

https://en.wikipedia.org/wiki/Parsytec

The concept of MPP - massively parallel processing - took the chip design world by storm, sufficiently that Intel went away and built their own prototype of MPP, which they named the Intel i860 RISC processor and which was designed for the same sort of massive parallelism that Inmos had pioneered.

Intel showed the i860 to Microsoft - and Bill Gates threw a complete tantrum. He sent Intel away with a flea in their ear, all because Microsoft's own compiler [and, more importantly, their developers] discovered that they simply weren't able to wrap their heads around the MPP paradigm. Instead, Gates insisted, what Intel needed to produce for Microsoft was a CPU that didn't have massive horizontal scaling, but just ran faster and faster and faster. What I heard at the time was that Gates was actually furious with Intel, because what they inadvertently did was expose Microsoft's limitations - in effect Microsoft held back the entire industry because of this.

This quickly led to what became known at the time as the Gigahurts Wars, where Intel and AMD were leap-frogging eachother with ever faster CPUs, all to satisfy Gates and Microsoft. In fact, I'm pretty sure it was covered by el Reg at the time, but one journalist or researcher took some data from existing processors and looked at the clock rates and the "thermal output per square centimetre of surface" and calculated that if the then current crop of processors were scaled up to 5GHz [at the time the leading chips were sitting around the 1.5GHz range] then the thermal signature of such a 5GHz processor would be hotter than a fuel rod in a nuclear reactor at full power...

It's difficult to imagine from today's perspective, with hyperthreading and multi-core CPUs being commonplace, but we only got here by accident. Microsoft almost completely killed the concept of massively parallel processing and multi-threaded code - because it was too difficult for them to write compilers that could benefit from those features.

Only now, decades later [well, OK, that's a small exaggeration] has software development fully caught up with hardware design.

It would be interesting to try and picture what our industry would be like today, if only Microsoft had embraced parallelism when Inmos and Intel offered it.

Very different from what we have today, I suspect.

SMT on ARM Cores

Tobias writes:-

"SMT has been a mainstay of x86 chips since 2002. The technology boosts utilization by enabling two threads to harness idle execution units during a single cycle. While SMT doesn’t double throughput, for certain applications it can deliver double-digit percentage gains.

While Arm has supported SMT in the past — you may recall Cavium ThunderX2's four-way SMT implementation prior to its acquisition by Marvell — the company has downplayed its value with its own agentic CPU.

Arm's dislike for the tech didn't stop Nvidia from implementing SMT-like functionality in Olympus. We say SMT-like because it's not SMT in the conventional sense. Rather than simultaneous multi-threading, Nvidia markets it as spatial multithreading, which is an apt name given how it works."

I believe this either skips over some critical context, or mis-states the underlying CPU design - at least to a limited extent.

Although many-generations-removed, today's ARM cores have a history that go all the way back to the ARM CPU and associated chipset (MEMC, IOC and VIDC) that powered the Acorn Archimedes back in the mid- to late-1980s. This entire family of processors, right up to the modern versions, are RISC based (Reduced Instruct Set Computer) and not the CISC (Complex Instruction Set Computer) that is found in the x86 family of processors.

The early generations of ARM - in the likes of the Archimedes and follow-on machines - returned staggeringly close to 4 MIPS of sustained throughput from a chip clocked at 4MHz. That speed was actually quite a little bit faster than contemporary Intel silicon. It achieved this for-the-time staggering throughput by having a relatively simple instruction set - 44 basic instructions that could be enhanced with conditional execution flags - that eventually evolved in to the sort of pre-fetch, pipelining and pre-execution that we see in current CISC based processors.

All the above is relevant because the whole point of SMT is that it allows multiple threads to operate during "idle cycles" in a processor. "Idle cycles" are common - in fact typical - in CISC-based designs, but they are much, *much* less useful in RISC-based processors, because the much faster execution rates for individual instructions. Say your CISC-based processor averages one instruction per 4 or 5 clock ticks... that means that 75-80% of your "clock ticks" are essentially lost because other parts of your CPU are busy performing logic steps for you.

SMT was a genuinely brilliant adaptation to processor design that found an elegant way to soak up that unused capacity by allowing the "idle" processor cycles to perform activities for other threads.

But SMT doesn't bring the same sorts of advantage to ARM processors, because they don't have "idle" processor cycles in quite the same way.

We can be quite confident that if SMT brought genuine advantages, it would have been more widely adopted before now.

UK wants datacenters to pay a fee for grid connection requests

UK National Grid - Live

If you're curious, you can see the demand and generation profile for the UK National Grid, live, here:-

https://grid.iamkate.com/

Courtesy of Kare Morley

Techie lured out of retirement to support software only he remembered

Life Imitating Art?

Isn't this basically the back-story for the character "Wally", from "Dilbert", by Scott Adams?

Three becomes one as Vodafone buys out merger partner

The problem we have...

... is that there is so much corruption swirling around Ofcom that the valid point you make will never be addressed.

The mobile operators are almost certainly using a weighted customer-density map to show them where they need coverage - put another way, they will deploy masts where they see from their data capture that their customers spend their time. Even if you are surrounded by their customers, if your neighbours work elsewhere, and don't use their mobiles evenings/weekends, you won't see coverage.

We were told this would never happen, of course. We were told that a combination of competitive market pressure and strict regulatory oversight would ensure that all UK citizens would be assured a minimum level standard in terms of availability and performance.

But just to give you an idea of how completely corrupt Ofcom are... think about your network performance [mobile or physical line]. You're charged a fee for a product that claims to offer you speeds "up to" a quoted headline value. Which means, of course, that you will never see anything like that performance. If you paid for a litre of fuel at a petrol station and got 990cc, then Weights & Measures would close the forecourt. If you bought 1kg of carrots from a supermarket and the scales actually told you that 990g were a kg, ditto.

Because that would be *fraud*.

Yet apparently, because it's a "whole new thing" [sorry, Chris Harris] the telecoms industry is able to get away with providing you sub-standard service and charging you full price for it.

"How is this possible?" I hear you ask.

Simples. Odcom are corrupt as f### and have more than enough former industry employees in their management - who will continue to use the "revolving door" between the regulator and the entities it regulates. Our MP's on the relevant Committee's are offered fat Non-Executive Directorships to look the other way.

NOAA ditches weather-predicting supercomputers for Google Cloud

Re: Really ?

And the "cats and dogs".

After rewriting SQLite in Rust, Turso turns its sights on Postgres

Confusing Caption

With an apology-in-advance for being a bit contrary... can I just observe that I found the title given to this article to be completely misleading?

It isn't the fact that Torso have now re-written a second database engine in rust that's significant here, but that their conversion/rewrite of SQLite prompted them to write a kind of "universal translator bytecode layer" that sits under their "Postgres API". That seems to be the "important bit" here - more significant than the choice of language.

I take on board - and agree with - all preceding comments that this risks being a dangerous approach - the point that a flaw in the core engine infects all "implementations" that sit on top of it being [in my view] the key take-away.

Or the fact that nowhere does the article explain why the developers chose to use rust for their project, when the original code for SQLite and Postgres is C++ (OK, with JAVA and Rust in the mix).

I've tried not to allow myself to get drawn in the direction of concluding "this is just dumb" and instead try and argue this from the other side, to think in terms of a "value proposition". If I were a developer or team lead and I went to my company/boss/board/other and said, "Hey! I'm going to spend a bunch of time and money rewriting various database implementations. I'm going to translate them from their native source language to Rust, and I'm going to remove their underlying data access engine and replace it with common bytecode - *that I derived from SQLite* ..." what would my sponsors say in response?

Somehow, I suspect that "Are you out of your ####ing mind?" might be in there somewhere.

More realistically, the only viable justification I could come up with was to help complex implementation environments. Say you have two applications: one written to Postgres and another written to e.g. MS SQL Server. Now say that you want your MS SQL application to have read-only access to your Postgres data, but that you further decided the way you want to implement this was to modify the code sitting on top of your MS SQL. In that admittedly contrived scenario it would make sense to be able to re-use all your MS-SQL objects and handlers, which means your app code will be leaner, simpler and easier to maintain. [Or you could run your abstraction layer there]. But that was the only excuse I could come up with for wanting to do this.

Are there others?

Maybe I'm getting cynical, but this struck me as a solution in search of a problem rather than anything that addresses a widely-seen problem.

Your mileage may vary.

NHS England rapped over inaccurate Palantir patient data disclosure

Re: Incompetence or malice?

"Then there is the assurance itself. NHS England says supplier access is technically necessary. "

Horsefeathers.

This is outright lying from a too-close-for-comfort vendor and various government employees and/or ministers.

The basic principles of "ALE" - Application Layer Encryption - are more than well understood in our industry - and the sort of thing that ***medical records*** should be protected with, by default. There is literally no basis to a statement that Palantir employees "had" to have access to patient data. None. NONE.

Public Inquiry Time.

Let's get some of these despicable people under Oath and On The Record. And if it can be shown that Palantir has in any way acted in bad faith, that should be the end of their ability to supply the British Public Sector with services.

There's more - a lot more - than we're currently being told. Strongly suspect this is much worse than we think and goes much higher than we realize.