Schneier on Security

Clive Robinson • February 5, 2026 10:18 AM

@ Q, ALL,

With regards,

“So the “auto-update to stay protected” claims are false.”

This has been known for a very long time.

When you analyse it, it fails because there is no verifiable way to establish a “root of trust” as Certificate Authorities can not be trusted to do what they are supposed to do, which is maintain a minimum level of security so that the “Certificate Chain” can be trusted so what we now call the “Supply Chain” is well and truly broken beyond any hope of repair as it’s all electronic on the Internet these days.

I the past you used to buy software on floppies, CD/DVDs or even tape. This “Physical media” was actually hard to usurp. Though historically Microsoft was the first to send out a prototype virus on such disks as part of MS Word on tech-support disks. Apple had the claim to fame of being the first to have hardware infected in the supply chain so that plugging your iPod into a USB port doomed you. An attack type that spread later to not just memory sticks, but broad band and WiFi dongles.

But you will find way back on this blog @Nick P and myself pointing out why “code signing” was a load of nonsense and how it could fairly easily be go around.

And eventually such attacks came to pass…

On average the musings of “the usual suspects” here were around eight years ahead of the curve.

Some still are as has been seen with hardware failings that gave us “The Xmas Gift that keeps giving”.

I’ve repeatedly warned about smart devices and “secure apps” like “Signal” where the “security end point” was on the same device as the “communications endpoint”. So why bother attacking the crypto when you can just do an “end run attack” through the OS, Drivers, or Other Apps to the user interface.

This is now known as “Client Side Scanning” and you can not stop it on devices where the foundations that support it got built into the OS by Apple, Google, and Microsoft, as part of C19 contact tracing…

To me this was obvious after I’d shown to “proof level” via the Work of Claude Shannon in the 1940’s and Gus Simmons work built on that in the 1980’s that it was not only not possible to prevent secure comms channels with E2EE but as importantly make them oblivious to any observer. All you needed was a “one time pad” cipher and a “one time phrase” code book (actually as long as you used the OTP correctly and the phrase book was constructed correctly it did not actually need to be used as “one time phrases”).

Get the “security endpoint” off of the device with the communications end point and even “client side scanning” will not work.

But doing this is “not convenient” for the average person who can not even say OpSec let alone what it means.

So they will never be secure, which makes the few of us who try to be secure just one silly move by a second party vulnerable.

It’s why I’ve worked on how to make such systems “deniable”…

The thing is others have taken the same ideas and used it as proof as to why AI “guide rails” will always be vulnerable to “prompt injection attacks”…

So as you can see there is a reason why I talk not just about “air gaps” but “energy caps” and “hard segregation” techniques. Which Microsoft, and Google try their best to prevent…

At the moment your choices of OS is kind of limited to the BSDs and GNU Linuxs…

Which as was pointed out “Agent P” was spending his time trying to make vulnerable via SystemD etc…