Meta and SQL Server make strange bedfellows on a couch of cyber-pain

Opinion When two stories from opposite ends of the IT universe boil down to the same thing, sound the klaxons. At the uber-fashionable AI end of tech, Meta has grudgingly complied with a ruling not to feed European social media crap into its training data. Meanwhile, in the industrial slums, 20 percent of running Microsoft SQL Server instances are now past the end of support.

In a saner world, that second story would have the same prominence in mainstream media as everything else in AI and cybercrime that fills the headlines. Databases make the world go round. They're where the AI training data lives, they're where the ransomware raiders go to pillage. They hold our money, our health, our digital lives. They are at the heart of every enterprise large or small. They are also inexorably dull, at least to normies, so when one in five cases of a mainstream database is out of date in a hostile environment, nobody cares. Worse, neither do one in five of sysadmins in here. If those databases were milk in the fridge, you'd know about them. But databases don't smell when they reach the expiry date.

Back at Meta, the ban on European training data on the grounds of privacy has validity, but masks many unresolved questions. How does an LLM cope with 20-plus different languages? We don't really even know how it copes with one. It's a fascinating research area, for sure, and not one you want going live tomorrow on hundreds of millions of citizens. A bigger question, though, is what will happen when products based on European-free training data are released on the European market.

If efforts to regulate and ethicize AI get anywhere, they'll minimize the use of biased training data that can harm users down the line. If AI were a dairy farm, banning European training data would be like banning harmful feed supplements, and ethical AI guidelines would prevent selling milk from poorly fed cows.

Feeding time

Hence our two stories meeting in the middle – they're both about the software and services supply chain, just at each end. Which means we already have a working model of a system that can create and enforce best practices based on risk and evidence of harm, regardless of the details of the technology. What we put into our mouths is even more intimate than what we put into our brains, so food standards have a lot to teach us.

The food standards regulatory environment is one of the outstanding successes of our time, albeit largely unsung and often used as a political pawn. The food industry itself is uncountably vast and varied, and ferociously competitive. If a penny can be shaved while two would draw blood, have the sticking plasters ready. And yet we still buy our food shipped across the globe to our supermarkets in the carefree assumption that it's been prepared, shipped, and sold while being kept perfectly safe to eat.

Different regulatory regimes are more or less lax, with clear consequences – one in six Americans becomes sick from food-borne illnesses a year compared to one in 28 Brits. That's not because of fastidious personal hygiene in the old country. Such differences are a political choice. As the UK has a perfectly serviceable food chain, stronger regulation does not impede commerce and innovation.

The system works, when it is allowed to, on a feedback loop – rules are set and enough checks made to persuade the industry to comply, and when things go wrong, a very efficient diagnostic regime identifies the problem and traces it to source. Typically, an uptick in food-carried infection triggers sequencing of the pathogen's DNA to establish common cause, coupled with an investigation into who ate what when. The investigators then work back through the supply chain to find a common source, which is then dealt with.

It is at the very least arguable that end-of-life database software is a pathogen vector at the end of the supply chain. If a large number of similar systems become vulnerable, they attract the attention of malicious actors who see big rewards for less work. Supermarkets cannot sell out-of-date food, so why should enterprises be allowed to run out-of-date software? While software's under-regulation means there are few tools available to enforce cyber hygiene, there are options. The insurance industry protects and indemnifies organizations, but is itself highly regulated. Invalidating aspects of that when out-of-date software has been identified and not fixed would be interesting indeed.

At the other end of the supply chain, where software and services are created and trained, the same principles of controlling risk based on evidence and potential harm as found in food can apply. Innovation isn't banned, it's encouraged and essential, but the potential risk scales with reach and impact with users. European data regulators implicitly work with this in mind; an explicit formulation of principle here would also be most interesting.

Food hygiene from farm to plate has developed alongside the biology of sickness since the 19th century. Cyber hygiene only got going in the 1980s with the co-development of viruses, software monopolies, and more recently universal connectivity. No wonder it's a century behind. Until that changes, though, expect to get cyber-sick like a medieval peasant with the bloody flux. You really don't want that. ®