lambdaone

That's a really fantastic typo. I know it was unintentional, but still...

Kaggle certainly seems like a good route for this, making it easy for the many people who merely want Wikipedia data, who will now follow the path of least resistance to get it.

I doubt it will discourage the true large-scale bad actors for whom Wikipedia is only a tiny subset of what they are trying to download, and are sufficiently well-resourced that they can't be bothered to special-case it.

It'll be interesting to see how this plays out.

Fascinating work. I'm in the process of reading David Graeber's The Dawn of Everything, so this is timely for me.

It's an entertainment article, and doesn't make any claim to be anything else. I'm not sure what you would prefer in its place; can you give any examples of what you would consider to be a suitable treatment of this topic?

I was there. I drew the artwork for the poster for the talk that got pinned up on noticeboards around the univrsity. I met Conway a handful of times, mostly at DAMTP, and he was always interesting, always with new ideas.

I feel the words "might" and "some" are doing a lot of heavy lifting in that sentence. The downsides of tariffs, though, are not hypothetical.

Either local solar panels, grid power, or a combination of both, yes. And of course solar panels can also indirectly "store" power by simply reducing demand on hydro resources during the day, allowing water to back up for night-time use.

In spite of all of this, Cycorp is still in business, and have pivoted to healthcare automation, including apparently insurance denials. I wonder if the full Cyc knowledg base will ever end up being released to the public domain, or whether it will simply fade away into nonexistence as proprietary data?

Generation and storage definitely should go hand in hand, but I think the Pakistani authorities' desire is simply to have something better than the alternative of not having it. At least Pakistan has plenty of hydropower installations that could potentially be adapted to act as energy storage.

This is fascinating. As the article says, sometimes the most unglamorous things can be among the most interesting.

It's not just Wikipedia - the entire rest of the open-access web is suffering with them.

I think the most interesting thing here is that it shows that the companies doing these crawls simply don't care who they hurt, as they actively take measures to prevent their victims from stopping them by using multiple IP addresses, snowshoe crawling, evading fingerprinting, and so on.

For Wikipedia, there's a solution served up to them on a plate. But they simply can't be bothered to take it.

And this in turn shows the overall moral standards of those companies - it's the wild west out there, where the weak go to the wall, and those inflicting the damage know what they're doing, and just don't care. Sociopaths.

This is why Rust is the leading alternative to C/C++; it was designed from the start to both call and be called from other languages to enable progressive migration, rather than requiring an incompatible and impractical big bang change that would never happen.

The mitigations in the cited article are good too, but they don't replace the need for safer languages.

There is some really promising-looking work on using a mixture of LLMs and formal proof techniques and/or unit testing to perform reliable and idiomatic translation from unsafe to safe languages. See, for example, https://arxiv.org/abs/2503.12511v2 and https://arxiv.org/abs/2409.10506, and https://arxiv.org/abs/2503.17741v1

The nice thing about this approach is that the LLMs don't need to be flawless for it to work, as the formal analysis / unit testing will keep their errors at bay - they just need to be good enough to eventually output something that passes the tests.

It's already been demonstrated to be insufficient; otherwise Apple software would now be impregnable. That's not to say these protections are a bad idea; they should be universal as they substantially reduce the existing attack surface - but the paper massively over-sells them as a panacea.

From the cited paper:

"These four types of integrity, do not establish memory safety, but merely attempt to contain the effects of its absence; therefore, attackers will still be able to change software behavior by corrupting memory."

and the paper then goes on to say, about Apple's implementation of the cited techniques:

"This intuition is borne out by experience: in part as a result of Apple’s deployment of these defenses since 2019, the incidence of RCE attacks on Apple client software has decreased significantly—despite strong attack pressure—and the market value of such attacks risen sharply."

"Decreased significantly" is not "eliminated"; indeed, you could paraphrase this as "the combination of these techniques has already been shown to be insufficient for security guarantees".

Which is not to say that these mitigations are a bad idea; but I think their benefits are significantly over-sold in the paper.

I don't doubt that most of the gazillion of so lines of legacy C++ will never be rewritten. But critical infrastructure - and there's a lot of it - most certainly needs to be either rewritten in safer languages, or somehow proved correct, and starting new projects in C++ just seems to me to be an unwise move when there are mature safer alternatives like Rust.

Human civilization is now so totally dependent on fragile, buggy software, and active threats against that software increasing so rapidly, that we will look back on this era as we do on the eras of exploding steam engines, collapsing medieval cathedrals, cities that were built out of flammable materials, or earthquake-unsafe buildings in fault zones.

This doesn't mean that safer C++ isn't a good idea; but it's also clear that C++ is unlikely ever to become a safe language; it's too riddled with holes, and the codebase built on those holes too vast, for all the problems to be fixed.

Possibly enables him to stand, according to the article - several other patients weren't helped by the treatment, and in the case that showed a positive effect the researchers currently can't eliminate the possibility of natural recovery causing the improvement.

But it's promising work, shows the treatment seems at least to be safe, and more research will no doubt follow to clarify this.

You can see a lot of open mouth/tongue stuff being skipped. Dealing with the tongue and the inside of the mouth is a huge problem with this sort of visual dubbing. Using traditional techniques, you can model teeth and gums as rigid bodies, and faces as rubber sheets (to first approximation), but tongues, for which you typically have no visual reference in any given shot, are much more difficult to model, and continuously, subtly, on the move. "AI" is the general answer to this problem nowadays, but even ML-based systems struggle to deal with the tongue issue while trying to reconcile visual appearance with animation fidelity.

This seems to be the research group involved:

https://www.med.keio.ac.jp/gcoe-stemcell/english/member/okan...

and here: https://www.scmp.com/news/asia/east-asia/article/3303473/jap...

Illegal commerce, money laundering, and speculation seem to have more than sufficed over that period

All of which is fantastic, until you can't trust Apple because they are under a secret obligation to disable that feature. Non-programmable hardware gating the I/O lines or power isn't hackable in the same way.

I'm quite surprised that they use a secure exclave to control the physical camera LED - this is absolutely massive overengineering to do something very simple.

A tiny bit of hardwired dedicated logic integrated into the camera module would be more than adequate to do this - just gating of either the digital I/O or the power to the camera, and a pulse-stretcher so the LED goes on for at least a few seconds each time to prevent an attack by rapidly flicking the camera logic on and off.

A similar circuit for the microphone with a different-coloured physical LED - not just a software-controlled dot on the screen - would be a good idea too.

The traction I'm looking for is discussion of this issue by technically knowledgeable people. Something is happening here which potentially affects the majority of the population of the UK, and the tech community by and large seem to be ignoring it.

Banking is critical national infrastructure. If online banking were to stop working for any considereable time, the result would be economic chaos, and right now the online banking services of most of the major banks are going down regularly, and concurrently, to the point where the mainstream media are reporting it.

Outages like this should be incredibly rare, and certainly not both frequent and concurrent across the big-nine banks.

It's all happening in plain sight, but outside of some trade press reports, no-one seems to be discussing it within the tech community. DDoS? Nation-state level hacking? Wide-area data centre or telecoms network failures? Repeated failure of some unacknowledged single point of failure? Or something else?

It's clear that even the Treasury Committee don't know, or they wouldn't be sending these letters to the banks' management.

Whatever it is, the banks seem to be keeping it a secret, and security-through-obscurity is generally a very bad idea. I understand keeping problems secret for short periods to allow fixes, but this has now been going on for months. Something is very wrong.

More: the Treasury Committee is investigating, and has sent letters to all the CMA9 banks:

https://committees.parliament.uk/publications/46590/document...

https://www.openbanking.org.uk/glossary/cma-9/

Unless this is all chance, and IT reliability and/or security is falling apart across the entire British banking sector independently, which seems increasingly unlikely, something is going on. But what?

Yes, this has been submitted to HN before, and hasn't gained any traction.

But this isn't the first time something like this has happened, and simultaneous outages like this are not something that is likely to happen by chance. This report is only part of the visible problem; this is happening to other banks as well on a regular basis (see below).

If it's not chance, either external attacks have occurred against several different banking groups at once (Lloyds, TSB, Halifax and BoS are all one group, but Halifax, Nationwide, First Direct and Barclays are not), or a substantial fraction of the entire British banking industry has a single point of failure somewhere.

Whichever it is, the banks and their regulators are keeping very quiet about it.

More reporting:

https://www.theregister.com/2025/02/28/payday_from_hell_as_s...

https://www.independent.co.uk/tech/lloyds-bank-down-not-work...

Let's not let the best be the enemy of the good. Malicious actors who disregard CAA would first have to have gone through the process of accreditation to be added to public trust stores, and then would quickly get removed from those trust stores as soon as the imposture was detected. So while creating a malicious CA and then ignoring CAA records is entirely possible for few-shot high-value attacks, it's not a scalable approach, and it means CAA offers at least partial protection against malicious actors forging certificates as a day-to-day activity.

Transparency logs are of course better because they make it much easier for rogue CAs to be caught rapidly, but it's not a reason to abandon CAA until transparency log checking is universal, not just in browsers, but across the whole PKI ecosystem.

Lloyds, Halifax, Bank of Scotland and TSB are all subsidiaries of the same organization, so will likely share infrastructure. But First Direct (which I believe are part of HSBC), Barclays, and Nationwide are not, and I believe are all unrelated to one another.

According to the Register, it's Lloyds Bank, Halifax, TSB, Nationwide, First Direct, Bank of Scotland, and Barclays.

Interestingly, all the banks seem to have the exact same notice on their websites about this. (See https://www.theregister.com/2025/02/28/payday_from_hell_as_s... )

None of the reporting on this seems to report a cause for what might be behind this. A concerted DDoS campaign? Failure of some shared common facility? Nation-state-level hacking?

Multiple UK banks are simultaneously reporting outages on their online banking sites and apps. Interestingly, they all seem to have the exact same message of their websites about this.

None of the reporting on this seems to report a cause for what might be behind this. A concerted DDoS campaign? Failure of some shared common facility? Nation-state-level hacking?