lambdaone

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?

Why limit your changes to syntax? Intercal's COME FROM would be a good addition, but you definitely also need SOLVE and PROVE statements to increase the power of the language.

Having IF TERMINATES and IF NOT TERMINATES predicates would be useful, too. Why limit yourself to everyday computable functions? And if you really wanted to, you could implement both SOLVE and PROVE in terms of them...

You're right that this is generally a golden rule. But rules can have exceptions, and this seems to be one of them; the Linux kernel is now so large and complex, and C so obviously outdated now, that it's worth the pain to start writing drivers in Rust. And because of the modularity of the kernel, and the care taken to make Rust binary-compatible with C, this looks to be actually practical, as individual subsystems will be either entirely Rust or entirely C, particularly when new drivers are involved.

Rust is a systems programming language by design; bit-banging is totally within its remit, and I can't think of anything in the kernel that Rust can't do but that C could. If you want really, really tight control of exactly which machine instructions get generated, you would still have to go to assembler anyway, in either Rust or C.

While it's almost never a compiler error, it happens, and I have personal experience; I once found an error in the VAX/VMS Pascal compiler - and could demonstrate it as such by disassembling the compiler output - and had to work around it until DEC fixed it.

See my comments about L4S.

It is until you congest it. Then, like all other network technologies, performance collapses. You can still force traffic through with EDC, buffering, and re-tries, but at massive cost to overall network performance.

Wireless networks' latency problems are almost entirely caused by contention, buffering, and vast over-booking of bandwidth, where raw bandwidth number competition has been over-valued relative to actual network application performance.

L4S is on its way, and may finally be the beginning of the end for bufferbloat and congestion, and vendors of mobile devices are in an almost unique position of being able to roll out network stack changes en masse. And just for once, consumer incentives, vendor incentives and network operator incentives all align - and it's incremental, and lacking in incentives for bad actors.

See this blog entry: https://www.ietf.org/blog/banishing-bufferbloat/ for more on L4S and bufferbloat. And this: https://datatracker.ietf.org/meeting/105/materials/slides-10... for a proper technical deep dive.

The development of L4S has been a pincer operation across all levels of the network stack, integrating everything previously understood about latency and congestion in real networks, and one of the most impressive bits of network engineering I've seen in the history of the Internet.

One in five seems to be an under-estimate. Based on my experience of Upwork, at least 50% would be a better estimate.

I think there's big potential in using DNS blacklists for this: they have the advantage of being massively scalable and simple to maintain, and clients configuration to use them is also easy.

The scalability comes from the caching inherent in DNS; instead of having to have millions of people downloading text files from a website over HTTP on a regular basis, the data is in effect lazy-uploaded into the cloud of caching DNS resolvers, with no administration cost on behalf of the DNSBL operator.

Reputation whitelists (or other scoring services) would also be just as easy to implement.

What's the reasoning behind the 10^12 instances claim? It is based on something like 20^9 mobile devices, each with 50 apps, each with an SQLite database?

Or some other calculation?

The next logical step after AI-slop music from Spotify would be for device manufacturers to cut out one more middleman, and provide their own locally-generated on-device AI-slop music as a feature of their devices.

It's quite concerning that they had at least two things go wrong at once, each without a backup plan. What happens now? Is something like an FAA investigation going to happen, or is SpaceX not under any kind of regulatory control in this regard?

While it's true that mathematics cannot ever be completely formalized, per Gödel's incompleteness theorems, a huge amount of it obviously can, as is demonstrated by the fact that we can write it down in a reasonably rigorous way in a combination of conventional mathematical notation and plain English.

Nor is this in any way "a fundamental problem with using AI to do math".

Yes. The lack of diffuse reflection from the pink train is the clearest giveaway, and AI videos in general have problems with getting shadows and radiosity right. There's also the existence of the real-world Hello Kitty Shinkansen and the APM Cat Bus in Japan that makes this image more plausible.

A tragic and short-sighted act of cultural vandalism for short-term profit. In other words, business as usual.

It's mind-boggling that this is not enforced by hardware: as other commenters has said, both by powering the LED from the same power as the camera, and also by making the enabling of that power use a simple hardware pulse-stretcher that would prevent the attacker from enabling the camera at such a low duty cycle that its flickering would be invisible to the user.

Ideally, the same should also be true of the microphone pre-amp, with its own LED separate from the camera one.

Surely when the price of power turns negative, you just start to disconnect panels from the inverters at the low-voltage side? The voltage remains, but no current flows, and no power is generated. If switching huge DC currents is the issue, this disconnection can be pushed down towards the panel level; relays/contactors would do fine, and you can dial capacity up and down by connecting or disconnecting a greater or lesser area of panels.

Is there some electrical engineering reason this cannot be done?