Security Now 1056 transcript

Please be advised this transcript is AI-generated and may not be word for word. Time codes refer to the approximate times in the ad-supported version of the show.

Leo Laporte [00:00:00]:
It's time for security now. Steve Gibson is here. We're talking about, as usual, all the security problems like the flaws, the holes in the US power grid. Apparently China has been using it for War Games. Apple's move to 26:2 is about security. We'll talk about the end of the line for long term certificates and what's going on with Australia and their social media band. Steve's got an update. All of that coming up on Security Now.

TWiT.tv [00:00:35]:
Podcasts you love from people you trust. This is Twit. This is Security now with Steve Gibson. Episode 1056 recorded Tuesday, December 16, 2025. Australia, it's time for security now. Fasten your seatbelts, put on your propeller hats and get ready for Mr. Steve Gibson, our man of the hour and our security guru. Hello, Steve.

Leo Laporte [00:01:06]:
I just love it. You look at me like, oh, there he is. Hey, Steve, you know what I'm gonna get? We're gonna get a double dose of Steve this week because you're gonna be on Twit on Sunday for our holiday show.

Steve Gibson [00:01:14]:
Gonna be very fun.

Leo Laporte [00:01:16]:
Yeah. You've always, we've had you on the holiday show many times. You've always wonderful to have on.

Steve Gibson [00:01:20]:
I gotta dust off my Santa cap. I got around here.

Leo Laporte [00:01:23]:
Yeah, yeah. Dyer.

Steve Gibson [00:01:25]:
I have, I have the Grinch. Was it. I guess it was the Grinch. You were Grinch. You had the hair. I remember that. Paul Thurat is. Loved it that I just kept doing this.

Leo Laporte [00:01:36]:
It'll be fun. It's Paris Martineau. It's you and who else? Who else? Beninos on Twitch. Micah. Micah. That's right. So it's going to be, as always with our holiday show, kind of relaxed. We'll probably look back at the big stories of the year.

Leo Laporte [00:01:49]:
But mostly he's just kind of sitting around.

Steve Gibson [00:01:52]:
Yeah.

Leo Laporte [00:01:52]:
Enjoying each other.

Steve Gibson [00:01:53]:
What the heck happened in 2025? So speaking of what the heck happened today's podcast, I don't know if I've, I'm, I'm sure in the past I've used a single word title. Today we have one. It's just Australia.

Leo Laporte [00:02:08]:
It says it all.

Steve Gibson [00:02:11]:
It does. Wow. I mean, the entire world's attention has been focused on this and the results were somewhat different than we thought. I spent some time bringing myself current. I've got two pieces of listener feedback that we'll cover there at the end of the show from one from an Aussie who's talking about the way things look are different than some of the way it's been characterized. And I don't mean to just, you know, drag us week after week through age verification, but, you know, it is like the big problem to solve right now. And it's, it's in our wheelhouse because crypto is the solution. Yet we're not using that.

Steve Gibson [00:02:56]:
We're using. Well, what do you think? How old do you think he looks? I don't know. His face is scrunched up. You know, it's a little hard to tell.

Leo Laporte [00:03:04]:
Such a weird way to do that.

Steve Gibson [00:03:07]:
It is so wrong. Anyway, and that's gonna, we're gonna talk about that because that actually is creating a new set of problems. But first we're going to look at Home Depot's puzzling reluctance to close a very bad hole in their security. Gnome's shell. Manager is unhappy with AI we're going to do a little bit of a deep dig there and any of our coders or code curious listeners are probably going to find that interesting. Also, we're going to look at how attacks on open source repositories compare now that we're ending 2025 with what 24 looked like by comparison. Some surprising information about the degree to which Chinese researchers have taken aim at the US power grid and the specific nature of that aim. It's worse than we thought.

Steve Gibson [00:04:05]:
Also, how bad has that react to shell vulnerability turned out to be? We have numbers as well as some new react vulnerabilities which are a consequence, interestingly, of researchers looking at the react code. And we've seen that happen before, too. So. And I'm going to briefly touch on, as you did in the previous podcast on MacBreak Weekly, Apple's move to iOS 26.2 and some interesting zero days that were discovered there. Let's Encrypt has a big announcement. They've. They've had a series of announcements. A biggie is projected for 2026.

Steve Gibson [00:04:45]:
Based on the. The shape of the curve that they're on. I think they're going to make it. I've got a check in on the progress of my DNS benchmark after its first 10 days. We've, I've learned some interesting things. We've got some listener feedback and then, as I said, Australia. So I think another great podcast for our listeners.

Leo Laporte [00:05:09]:
Good day, Australia. All right. Yes, it will be a good day for us today. Security now day. Always look forward to Tuesday with Steve Gibson before we get to the picture of the week, which apparently is timely for both of us. I'm not sure why I haven't looked at it yet, but we'll Find out in a moment. I would like to talk about our sponsor for this segment on security now, Zapier. Zapier does a lot of the work behind the scenes on our shows.

Leo Laporte [00:05:37]:
You may not even know it. Zapier is the tool I've been using for years to automate workflows. So it's one of the ways we prepare our shows. When I find a news story, I bookmark it. Zapier picks up the bookmark, puts it on Mastodon, toots it on our Twit news feed on Mastodon, but also then puts it formats it, puts it in a Google spreadsheet so that the editors could pick it up and then put it in our rundowns. I mean, it's just a really wonderful tool that I use all the time without even thinking about it. Because once you set it up, it just works. It just works.

Leo Laporte [00:06:12]:
Well, now Zapier is even better. And now I'm thinking of all sorts of new ways I can use it. We cover a lot of things on this show, but over the last few months, one of the top topics on all of our shows, AI, Right? Let's face it, talking about trends doesn't help you be more efficient at work. For that, you need the right tools. How many times have you sat down at the AI prompt going, well, I don't, what should I, what should I say? Well, with Zapier, you got the right tool. Zapier is how you break the hype cycle and put AI to work across your company. Zapier is my favorite on automating workflow tool. I just, I just love it.

Leo Laporte [00:06:51]:
It's, it's. But now it's even better because they've added AI Orchestration. It is now the premier AI orchestration platform. Zapier is how you can actually deliver as a company on your AI strategy, not just talk about it. With Zapier's AI orchestration platform, you can bring the power of AI to any workflow. I'm thinking of some of the workflows that I have already I want to add AI to. Of course you can create brand new AI based workflows as well. You can do more of what matters.

Leo Laporte [00:07:20]:
Use Zapier. It's like, you know, who was it? Was it Archimedes said, give me a lever, I could move the world? Zapier is that lever. It's that thing that, that gives you so much power and now add AI to it. You connect top AI models like Chat, GPT or Claude or, well, they have many of them to the tools Your team's already using Google Drive and Microsoft Office and you know all of that. Zapier has over 3,000 integrations, so even if I started to list them, I could never finish it. Works with everything. I use it to make my lights come on at sunset, things like that. So you can add AI to any of those workflows or create your own AI specific workflows, AI powered workflows like an autonomous agent or a customer chatbot, or anything you can imagine you can orchestrate with Zapier and AI.

Leo Laporte [00:08:15]:
The thing about Zapier that's really important doesn't require technical expertise. It's for everyone. You don't have to be a tech expert. And the proof is that teams have already used Zapier to automate over 300 million AI tasks. 300 million. Join the millions of businesses transforming how they work with Zapier and AI. Get started for free by visiting zapier.com securitynow that's Z-A P-I-E-R.com security now. Thank you, Zapier, for your support of Security now and the important work Steve is doing here.

Leo Laporte [00:08:51]:
Steve, we can go ahead with the picture.

Steve Gibson [00:08:54]:
Happier means more happy.

Leo Laporte [00:08:56]:
Happier. Zappier makes you happier.

Steve Gibson [00:08:59]:
Well, no, I'm wondering if Zappier means more zappy.

Leo Laporte [00:09:02]:
Well, they call the automation zaps. So maybe I'm more zappy.

Steve Gibson [00:09:08]:
I'm more zappy. I'm Zappier.

Leo Laporte [00:09:12]:
I'll propose that to them as their next slogan. How about that?

Steve Gibson [00:09:15]:
Maybe they won't fire the. Okay, so our picture of the week had no caption. I just couldn't think of one that did any better job than this did. It's a four frame cartoon. So we have a young girl sitting on Santa's lap, as is customary, and she says to Santa for Christmas, I want a dragon.

Leo Laporte [00:09:41]:
Yeah.

Steve Gibson [00:09:42]:
And Santa says, okay, be realistic. So she says, 64 gig of RAM. And he says, what color do you want your dragon?

Leo Laporte [00:09:56]:
That is pretty awesome and very timely. Yes, both of us, it turns out, responded to this RAM crisis.

Steve Gibson [00:10:05]:
Yeah, I purchased what will. I don't buy PCs often. Probably maybe at a pace of 1 20th of yours. Leo, I'm just estimating, you know, I'm.

Leo Laporte [00:10:18]:
Actually, I have to buy them to try them.

Steve Gibson [00:10:20]:
I know. And the irs, you have to explain that. It's like. Sorry, irs. I had to.

Leo Laporte [00:10:25]:
Hey, no, they understand. No, they understand. Of course. It's business expense. Yeah.

Steve Gibson [00:10:30]:
I'm talking to you in front of a Windows 7 gigabyte motherboard from. I don't Know, I think Thunderbolt was an innovation when I bought this thing. So it's been a while because it's great, it works, it goes.

Leo Laporte [00:10:47]:
Nowadays computers really are so fast. Used to be you'd have to buy it to keep up with Windows being so sluggish. You'd have to buy more of a processor.

Steve Gibson [00:10:55]:
But now nowadays you're buying it because you want to be able to plug more displays in to the box. So. And then at my other location, you know, my place with Lori, I've got a one of those really low profile Intel NUCs.

Leo Laporte [00:11:12]:
Those are great. I love those.

Steve Gibson [00:11:13]:
Well, they are except that it's sitting on the desk behind a monitor and its fan is just dropping. Drives me nuts because it's a, you know, to be so small it's got to move, it's got to force a lot of air through. So there's a little small flat disc fan. That's.

Leo Laporte [00:11:36]:
Not nice.

Steve Gibson [00:11:37]:
Oh my God. The only good thing is I can tell when, I can only. I can always tell when some process is like hogging the CPU and I fire. So I fire up Task manager and it shows, you know, very high on some random thing. Right. So I'll think, well. And it's typically anti malware. It's decided to, to wake up and bog the whole system down while it rescans my drive.

Steve Gibson [00:12:02]:
So anyway, point is because of the, the crazy, and we talked about it last week, the crazy recent explosion in RAM prices which is being driven because all these data centers that are being set up with are have hogged all of the RAM production capacity of the world. The RAM makers are going, well, if you want it that badly, here's where, here's our new price and anyway, so, so anyway, I purchased a Lenovo Gen 3 Core i9 whatever triple scoop thing, you know, it's a small, small form factor because that's the right thing and.

Leo Laporte [00:12:46]:
It'S got, you know, you're for a geek. Most geeks like they could rip off all of the part numbers of everything they bought. But you just. The triple scoop.

Steve Gibson [00:12:56]:
Yeah, that's right. It's got.

Leo Laporte [00:12:57]:
And it doesn't matter anymore, does it just.

Steve Gibson [00:13:01]:
Yeah, precisely. I'm still kind of, you know, intel centric. I feel more comfortable with an actual Intel.

Leo Laporte [00:13:08]:
Well, I think for laptops intel is probably still the right way to go. I think desktop's AMD is the champ, but.

Steve Gibson [00:13:14]:
Well, that's it. This is a desktop and I still kind of, I still said fine.

Leo Laporte [00:13:20]:
Intel's come along a long way. They, they were Struggling.

Steve Gibson [00:13:23]:
It does have the Nvidia, whatever the hell it is.

Leo Laporte [00:13:26]:
Oh, good.

Steve Gibson [00:13:28]:
Something or other. It's got a neural. Neural thing.

Leo Laporte [00:13:31]:
Maybe some super neurals will happen.

Steve Gibson [00:13:34]:
Double dip, extra crunchy.

Leo Laporte [00:13:36]:
That's right.

Steve Gibson [00:13:37]:
I know that it has three display ports because as I mentioned before, my setup is three screens. I made the mistake of having a high resolution center screen and different resolutions on the wings. And that's disastrous. When you drag something across and it.

Leo Laporte [00:13:53]:
Like goes off, it gets big or small or.

Steve Gibson [00:13:55]:
Yeah, that's good.

Leo Laporte [00:13:56]:
No, it has to all be the same.

Steve Gibson [00:13:57]:
And in fact, I don't think Windows works right. Actually, when you're dragging, it's not happening.

Leo Laporte [00:14:02]:
Steve, little tip here. Windows doesn't work right. Period. Just a little inside information.

Steve Gibson [00:14:09]:
Oh, try to diagnose. Yes, you're right. And is it today? Oh, I think it is today. I have a little bit of a beef with Microsoft. Not surprisingly, we've gone several weeks without.

Leo Laporte [00:14:18]:
I'm going full length. I did the same thing. I bought a Lenovo, but I bought a laptop. This is the ThinkPad carbon and it's a Core Ultra. And I'm putting. But I'm putting Linux on this because I'm not a masochist. Well, no, you were explaining this.

Steve Gibson [00:14:34]:
Yeah, you were explaining on MacBreak how you're basically severing ties with the real world. And we understand, Leo, it's not that.

Leo Laporte [00:14:43]:
It's just that. Well, we had a story about a poor guy who's actually in our club, Australian of all things, who got locked out of his Apple account and is getting no response from Apple. And that means he's lost everything for 20 years because. And this is true of all of these guys, you know, it's if they're kind of siloed. And so I want to go with Linux because I just feel like I'm the user, I'm the, I'm not, I'm not going to be the, the victim of this. I don't want to be.

Steve Gibson [00:15:15]:
Well, and it's, it's a lesson that I learned at some point with spinrite was people were saying, hey, hard drives are like less expensive than Spin, right? Why would I. You use spinrite to fix my dead hard drive. And it's like, hey, it's your data dummy.

Leo Laporte [00:15:32]:
It's the hard drive. It's what's on.

Steve Gibson [00:15:34]:
No, no one cares about the hard drive. I, I've got those for two doorstops. No, it's what's on the hard drive that you want to get back. So, yeah, I get It. And, and boy, think about. I'm noticing the difference today versus when we were growing up, when you actually had to put film in the camera and then like wind the knob until, you know, like. And throw away the first couple because they were going to be exposed to light.

Leo Laporte [00:15:58]:
Yeah, yeah.

Steve Gibson [00:16:00]:
And it was. And you just didn't indiscriminately take pictures of everything because that was expensive.

Leo Laporte [00:16:06]:
Yeah.

Steve Gibson [00:16:06]:
You were actually consuming something. Mylar was dying on your behalf and silver iodide or something was getting exposed.

Leo Laporte [00:16:15]:
I don't know, like 50 cents for every shot.

Steve Gibson [00:16:17]:
Yeah. Now it's a different world. But you do need to. I agree with you that archiving your. This photo collection that we now just take for granted. What if it did disappear?

Leo Laporte [00:16:29]:
What if you lost your Google account? What would happen? What if you lost your Apple account? What would happen? Paul Thurat very nearly lost everything when his Google account was canceled. He was able to get it back. But it really, I think it reminds us that it's on us to make sure that we are whole and not dependent on these third parties.

Steve Gibson [00:16:48]:
And if anything, we've seen a complete collapse of user support. Like true customer concern. If something doesn't work, it's good luck. You know, you're not. You're going to get some robot chat box in the lower right corner of your screen that says how may I help you today? And you ask it a question that says, would you. Is that nine or ten? No, I, I need. You know, can I talk to a real person, please?

Leo Laporte [00:17:14]:
Well, it's even worse if you get stuff. Yeah, real people. No, I always said Google gave you support via Python script.

Steve Gibson [00:17:22]:
And boy, speaking of that, I've seen more mistakes from Google's little helpful AI with when you ask it something, it just makes up crap. I've mentioned it before. Just happened to me yesterday where I was asking it something. Oh, I wanted to know if I could limit the postings on Zenforo, the forum software we use for specific people. Because we've got one person who just like, just like he, he believes that he's somehow getting remunerated based on character by the word not helpful. Anyway. And of course Google said, yes, you can. Here's what you do.

Steve Gibson [00:17:56]:
It's like. And it made up a complete bunch of nonsense that didn't, didn't exist before that I asked it. There's another problem that we're having. Windows 11 has something called Smart Application Control. Well, right off the bat, the name should tell you that you've got some.

Leo Laporte [00:18:14]:
You know, it's not smart.

Steve Gibson [00:18:17]:
No, because, because there have been some users of the benchmark who have been blocked by smart Application Control. This is not like Windows Defender where you can say, okay, I know you're, you're nervous because see, the problem is we sign and I talked about this a long time ago. A couple years ago, we custom sign everybody's individual download with their name and license in the code so, so that it is pre licensed for them. Well, that means that every copy is unique, which means that Microsoft can't learn that, oh, thousands of people have downloaded this and we never got any complaints. So the good news is we've had almost no trouble. But two people that I'm aware of have said that Smart App Control has said no. Well, okay, get this, Leo, unlike Windows Defender, you can't say I know, but I know Steve and you know, trust him. Let this through.

Steve Gibson [00:19:22]:
No, if you turn it off, you can never turn it on again. Get this. It can only be turned on during a fresh install from scratch of Windows 11 because they're saying, oh, it has to be on from the beginning so that we can assure you that there was never a moment where, when your system was vulnerable. And because it can absolutely cause trouble, I mean it won't let any unsigned software run. You're just sol if you are trying to run anything that is not signed. So you can imagine that enterprises have a problem with that because they're running internal software for their enterprises. So it can be turned off. Most enterprises do have it off.

Steve Gibson [00:20:13]:
It will never be on it if you've upgraded windows from 10 to 11 because again, well, we don't know how contaminated your system already is. The only way to have it on is if it's a fresh install. Now oftentimes OEMs will start off by turning it on, but then they get so many customer complaints about this being a problem that now OEMs are shipping with it off because it's just not worth it. You still have Windows Defender. Anyway, my point is it's not smart. And I asked because this was the first time I encountered. It was yesterday I said to, to Google, you know what is smart app App Control and can I turn it off? And Google said, oh yes, here's what it is and yes, you could turn it off. And it gave me instructions to turn it off, which, which technically are correct.

Steve Gibson [00:21:04]:
But it didn't explain of course, that once turned on again, so, so it's not off for just one application. I got a little confused with Windows Defender. Anyway, the world we live in. You're in. You're in Linux. And I understand why.

Leo Laporte [00:21:20]:
That's why I'm in Windows.

Steve Gibson [00:21:22]:
Because I have customers.

Leo Laporte [00:21:23]:
No, I understand I'm in the very enviable position where I owe nothing to anybody and I can do what I want. And I'm very happily using Linux.

Steve Gibson [00:21:34]:
I will say, however, I've been very impressed with how many people are running the benchmark under Linux and on their Apple machines. So there's a strong crossover. I mean, we're not just. Even though I'm producing Windows only software, thankfully the Wine people have been working overtime. It's a miracle.

Leo Laporte [00:21:53]:
That's another loyalty to intel. You're writing x86 assembler. You can't be using those smart Snapdragon stuff. Although our processors.

Steve Gibson [00:22:04]:
Rosetta works great.

Leo Laporte [00:22:05]:
No, that's good.

Steve Gibson [00:22:06]:
It runs on intel arm, on Windows ARM and Mac ARM machines.

Leo Laporte [00:22:13]:
The last operating system version it will run. Because they're killing Rosetta.

Steve Gibson [00:22:17]:
I know, but there's something else. Not Rosetta, but there was.

Leo Laporte [00:22:20]:
There are other emulators. Yeah, I mean, I use. I use Parallels all the time. There's Fusion, VMware, Fusion and Parallels. There's Qemu, there's a number of emulators that'll let you do that because you're.

Steve Gibson [00:22:29]:
And I.

Leo Laporte [00:22:29]:
And this is the key. You wouldn't want to use. Use that for spin, right? Because you don't want an emulation layer, but your tool is looking at DNS speeds. That's independent of how it's running. Let's talk about Home Depot.

Steve Gibson [00:22:45]:
Oh, okay. So last week I used the phrase oh, yeah? Well, make me in reference to the sort of conduct that's probably most common in adolescent males of around high school age. I was reminded of that by TechCrunch's reporting of home Depots apparently taking the same unfortunate tactic, even though one could argue they're grown ups. TechCrunch's headline was Home Depot exposed access to internal systems for a year, says researcher. And actually, it's nearly two years. Zach Whitaker reported for TechCrunch. A security researcher said Home Depot exposed access to its internal systems for a year after one of its employees published a private access token online. Likely by mistake.

Steve Gibson [00:23:42]:
I would say definitely by mistake. Unless he was, you know, really disgruntled. The researcher found the exposed token and found the exposed token and tried to privately alert Home Depot to its security lapse, but was ignored for several weeks. The exposure is now fixed. After TechCrunch contacted the company's representatives last week, so the security researcher was Ben Zimmerman, who writes TechCrunch told TechCrunch that in early November he found a published GitHub Access Token belonging to a Home Depot employee, which was exposed sometime in early 2024. So as I said, two years. Coming up on two years. When he tested the token, Zimmerman said that it granted access to hundreds of private Home Depot source code repositories hosted on GitHub and allowed its holder to modify their contents.

Steve Gibson [00:24:52]:
Yikes. Okay, so just to pause here for a second, we don't know what those hundreds of private Home Depot source code repositories might have contained, or might still contain, but having a token loose on the Internet that permits write access to them ought to keep anyone from resting before it was invalidated. I can't imagine someone reporting this and just being blown off. We haven't encountered this Ben Zimmerman before, but Zach provided a link to Ben's website where he introduces himself, writing, hey, I'm Ben. I'm a security researcher from California. I've been awarded over $20,000 in bug bounties for securing critical infrastructure and the open web. Then he lists a bunch of his discoveries on his page. So this guy's the real deal, Zach continues writing.

Steve Gibson [00:25:45]:
The researcher said the keys allowed access to Home Depot's cloud infrastructure, including its order fulfillment and inventory management systems and co development pipelines. Right. And order fulfillment, among other systems. Home Depot has hosted much of its developer and engineering infrastructure on GitHub since 2015, so for the last decade, according to a customer profile on GitHub's website, Zimmerman, the researcher, said he spent he sent several emails to Home Depot but never heard back. Nor did he get a response from Home Depot's Chief Information Security Officer, Chris Lanziata. After sending a message to him over LinkedIn, Zimmerman told TechCrunch, in other words, Ben really tried to like every way he could to contact Home Depot and say hello. Zimmerman told TechCrunch that he has disclosed several similar exposures in recent months to companies which have thanked him for his findings. He said Home Depot is the only company that ignored me, unquote.

Steve Gibson [00:26:56]:
Given that Home Depot offers no way to report security flaws such as a vulnerability disclosure or or a bug bounty program, Zimmerman contacted TechCrunch finally in an effort to get the exposure fixed so right using TechCrunch's strength. When reached by TechCrunch on December 5, Home Depot spokesperson George Lane acknowledged the receipt of our email, but did not respond to follow up emails asking for comment. Wow. The exposed token is no longer online. And the researcher said the token's access was revoked soon after our outreach. TechCrunch's outreach. We also asked Lane if Home Depot has the technical means, such as logs, to determine whether anyone else used the token during the months it was left online. You know, almost 24 months to access any of Home Depot's internal systems.

Steve Gibson [00:27:58]:
We did not hear back. So.

Leo Laporte [00:28:02]:
Okay.

Steve Gibson [00:28:03]:
The question at the end of Zach's reporting, of course, is exactly the one I was asking myself. Ben was able to date the creation of the token to early 2024. So we're coming up on two years of write access exposure to many of Home Depot's critical appearing internal systems by way of the software that runs them. Ben's a good guy security researcher who's out there working to improve the security of the world. But we know that within the population of people who may be poking around looking for security vulnerabilities, good guys like Ben are almost certainly in the minority. Access to hundreds of Home Depot's internal operations source code repositories would be immensely valuable to any attacker who wants to find some way to threaten and extort Home Depot as well as, you know, you know, who is. Home Depot is a well known US entity with deep pockets and apparently not much in the way of security practices. So do they have logs? Do they even care if they have them? We don't know anything about Home Depot's internal IT culture, but what we do know doesn't look good.

Steve Gibson [00:29:23]:
So not the way you need to operate. And you know, we need to remember, I think, that not all companies are IT centric. I think that's crazy in today's world, you know, we're in the process of a lengthy remodeling of a condo that we'll be moving into, my wife and I in a month or two. And you know, Home Depot and their online presence and the fact that they've got some retail outlets near to us, they've been seeing a lot of use from us in the last few months. So a company that is, you know, on the Internet cannot afford not to have an IT culture, which is up to speed. And there sure doesn't seem to be.

Leo Laporte [00:30:11]:
I thought you were going to say we're building a house and we're going to put locks on the doors, we can assure you. Maybe security cameras in there too, huh?

Steve Gibson [00:30:22]:
That too, you betcha. Wow. Okay, so this is really good. In fact, this is so good. Leo, I think we should take a break before I get into this. Goodness. Because otherwise we're going to get well past our first breakpoint, so let's do that and then we're going to talk about what Gnomes, Shell extension manager, one of them had to say about AI and its contribution to their efforts.

Leo Laporte [00:30:52]:
Yeah, I'm well aware of this. I think they had to. But we'll talk about it in just a little bit. First though, since Steve wants to take a break, I would like to talk about our sponsor for this segment on security now, Threat Locker. Very excited about Threat Locker because I think Steve and I are going to be working with them in the spring at their big zero trust world. Threatlocker is a very, very well known maker of zero trust solutions that are both easy to install, affordable and highly effective in stopping supply chain attacks. Zero days There is a real reason why you need Threat Locker ransomware. I don't have to tell you this.

Leo Laporte [00:31:31]:
If you listen to the show, you know it is harming businesses everywhere. Threat Locker can help prevent you from becoming the next victim. Threat Locker is a zero trust platform and this is the key. Takes a proactive. These are the three words. Deny by default approach. Deny by default approach. That means it blocks every unauthorized action to protect you from both known and unknown threats.

Leo Laporte [00:31:58]:
It's the only way you can. You, you have to explicitly say it's okay for this program to do this, it's okay for this user to do this. You have to explicitly say that. And this is incredibly powerful. And that's probably why Threat Locker is trusted by companies that just can't afford any downtime. Global enterprises like JetBlue, an airline goes down for five minutes and it is a crisis, right? Port of Vancouver, same thing. Infrastructure. Threat Locker shields them and can shield you from zero day exploits and supply chain attacks while providing complete audit trails for compliance.

Leo Laporte [00:32:33]:
That's another benefit of this because if everything that happens is proactively approved by you, well, you've got an audit trail of everything that did anything that everybody who did it, you know, it's great for compliance as more cybercriminals are turning to something called malvertising. This is something that Steve's been really talking a lot about is, is how hard it is to protect your company from employees acting completely innocently. And, and in order to do this you really need more than the traditional security tools. Malvertising is a perfect example. Attackers create convincing fake websites. They impersonate popular brands, AI tools, software applications. They distribute them through social media ads, through hijacked accounts. And then, and this is the most evil part, they use Actually, it's all evil.

Leo Laporte [00:33:26]:
But they use legitimate ad networks. They buy ads and all of these are automated on all of the ad networks. They're all automated, so there's nobody checking. So they buy these ads to deliver malware, which means your employee browsing on a work system to legitimate sites will see these ads. They can't help it, you know, they don't have to seek it out. They're being thrust at them. Traditional security tools usually miss these attacks because they are clever. They use fileless payloads, they run in memory.

Leo Laporte [00:33:59]:
They exploit trusted services that bypass typical filters. But not Threat Locker. Threat Locker's innovative ring fencing technology strengthens endpoint defense by controlling which applications and scripts can access or execute. It's as simple as that. That contains potential threats. Even if those malicious ads successfully reach the device, they cannot run because you haven't approved them. Threat Locker works across all industries. It supports Windows and Mac environments.

Leo Laporte [00:34:30]:
It provides 24. 7 US based support. Best support ever. And enables comprehensive visibility and control. Jack Senisap is the director of IT Infrastructure and Security at Red Nurse Markets. They use Threat Locker. Jack says, quote, when it comes to ThreatLocker, the team stands by their product. ThreatLocker's onboarding phase was a very good experience and they were very hands on.

Leo Laporte [00:34:54]:
Threat Locker was able to help me and guide me to where I am in our Environment today. Visit threatlocker.com Twitter to get a free 30 day trial and learn more about how ThreatLocker can help mitigate unknown threats and ensure compliance. That's ThreatLocker. And for a limited time, if you use this offer code ZTWTWIT26 you're going to get $200 off registration for Zero Trust World 2026. It's in Orlando. ZTWIT26 200 bucks off registration for Zero Trust World 2066. That gives you access to all sessions. It gives you hands on hacking labs, gives you meals.

Leo Laporte [00:35:35]:
There is a very famous after party they do every year. It's the most interactive hands on cybersecurity learning event of the year. It's March 4th through the 6th in Orlando and I think it's okay to say we're going to be there. I'm very excited. Be sure to register with the code ZTWTWIT26. We'll see at Zero Trust World. We'll see you and Threat Locker at Zero Trust World. And I'm very excited about that, Steve.

Leo Laporte [00:36:07]:
It's going to be a lot of fun.

Steve Gibson [00:36:08]:
It's going to be fun. And we're probably okay to say we're the last presentation of the first day. Fall back. Cocktail, Cocktail party.

Leo Laporte [00:36:17]:
So I wish we would be around. Yeah, you'll have a chance to buttonhole us and talk to us. So that's gonna be. I'm. I cannot wait. And Orlando, I think, is a fun place to go. It's going to be warmer than it is stuff.

Steve Gibson [00:36:30]:
It's got stuff.

Leo Laporte [00:36:31]:
Look, we have a party going on. Okay, on we go with the show.

Steve Gibson [00:36:36]:
So a recent posting by one of the guys who's taken on the job of managing gnome's shell extensions was interesting and I wanted to share it so. But first of all, just to be clear about what GNOME is for those who may be familiar with the Windows or Mac world. Gnome, GNOME is to Linux and Unix, like operating systems, what Explorer and the Windows Desktop is to Windows or Finder, and the Mac OS UI is to Mac os. So it's the ui, it's the desktop, you know, file manager and so forth. All three GNOME Explorer and Finder, you know, are that for their respective environments. And GNOME is, you know, G N O M E. There was originally an abbreviation for GNU Network Object Model Environment. So since then it's taken on a life of its own and you know, people just know it as gnome.

Steve Gibson [00:37:37]:
Okay? Therefore a GNOME shell extension is an add on that adds a feature to the Linux desktop, which is what runs gnome.

Leo Laporte [00:37:48]:
So.

Steve Gibson [00:37:49]:
So here's what one of the shell extension managers wrote last week. He said, since I joined the extensions team, I've only had one goal in mind, making the extension developers job easier by providing them documentation and help. I started with the port guide and then I became involved in the reviews by providing developers code samples, mentioning best practices and even fixing the issues myself and sending them merge requests. Andy Holmes and I spent a lot of time writing all the necessary documentation for the extension developers. We even made the review guidelines very strict and easy to understand with code samples. Today, extension developers have all the documentation to start with extensions, a porting guide to port their extensions, and a very friendly place to on the GNOME Extensions matrix channel to ask questions and get fast answers. We now have a very strong community of GNOME shell extensions that can easily overcome all the difficulties of learning and changes. The number of submitted packages is growing every month and we see more and more people joining the extensions community to create their own extensions.

Steve Gibson [00:39:11]:
Some days I spend more than six hours a day reviewing over 15,000 lines of extension code and answering questions from the community. In the past two months, we've received many new extensions. This is a good thing since it can make the extensions community grow even more. But there is one issue with some packages. Some devs are using AI without understanding the code being produced. This has led to receiving packages with many unnecessary lines and bad practices. And once a bad practice is introduced in one package, it can create a domino effect appearing on other extensions. That alone has increased the waiting time for all packages to be reviewed.

Steve Gibson [00:40:09]:
At the start, I was really curious about the increase in unnecessary try catch block usage in many new extensions being submitted. So I asked and they answered that it is coming from AI. Just to give you a gist of how this unnecessary code might look. Okay, and then in his posting he gives us a sample of this code that I'm going to dissect here in a second. He provides us a sample of code that is what he actually sees in submitted GNOME extension source. And it's got a whole bunch of lines. And then he says instead of simply calling, and then he's calling a function, super dot destroy he said, which you clearly know exists in the parent. And then he basically shows all of those lines and then basically the a single line or single call is all you need.

Steve Gibson [00:41:17]:
So he says at this point we have to add a new rule to the review guidelines. Any packages with unnecessary code that indicate they are AI generated will be rejected. This doesn't mean you cannot use AI for learning or fixing some issues. He writes, AI is a fantastic tool for learning and helping find and fix issues. Use it for that, not for generating the entire extension. For sure, in the future AI can generate very high quality code without any unnecessary lines. But until then, if you want to start writing extensions, you can always ask us in the GNOME extensions matrix channel. Okay, so for people who as I said, are coders or code adjacent or code curious, this is, this is a, like, there's a, just, just a perfect example of many different things going on here.

Steve Gibson [00:42:27]:
So we're gonna, we're gonna look and understand this manager's annoyance so that we can also, and we need to look at it and understand it so we could talk about what AI is doing here and, and, and what's wrong. So first of all, modern high level languages have a construction known as try, catch and Leo will be glad to know that this concept originated back in the 1960s with Lisp, which used the semantics catch and throw to essentially do the same thing. This first appeared in Lisp. So the idea behind this is that if some code might produce an error at runtime, not when you're compiling it where the syntax passes, but when you're actually running it, when, where something bad happens, like you tried to divide something by zero, you can't, right? That's illegal. So that produces an error. So the idea is that if you have some code that might produce an error at runtime, we don't want the entire program to just give up and explode. We want to have the opportunity, we, the coder, want to have the opportunity to contain the problem and to possibly handle it ourselves and in some more of our own code. So the suspect code code that might cause a problem is placed inside what's called a try block, which tells the runtime manager to literally try doing this.

Steve Gibson [00:44:07]:
The try block is then followed by a catch block that's used to catch any runtime error that might unexpectedly occur while we're executing the code inside that first try block. So in other words, we're telling the runtime manager, while code is executing inside this try block, don't freak out if anything bad happens, simply stop what you're doing for us there and execute the code we have provided for for this purpose in the catch block, which immediately follows the try block and we'll take it from there. So this allows code to be somewhat self healing and to handle its own errors internally, rather than simply, you know, crashing and saying, you know, bam, this program has died. Okay, so now let's look at the specific case of this gratuitous AI generated code which, which this manager posted in the example the manager provided we have some code in the try block that first of all cannot possibly fail. It's, it's already, the code is already being extremely cautious. It it first checks to see whether the super object contains a function named destroy. The test for that. Just asking the question, does this exist? Cannot produce an error.

Steve Gibson [00:45:51]:
It will either return true or false. Either the super object exposes a destroy function or it doesn't. And then the way that conditional is written, only if the super object does expose a destroy function will that destroy function then be called on that super object. So this conditional that's wrapped in a try block cannot fail. It cannot cause an error that could require the try catch exception handling mechanism to be invoked. It can't happen. But more than this, we learn from the context that the manager shared with us, which is that whatever that super.destroy function is, it is apparently well known to exist and must exist in this GNOME shell extensions execution environment. That makes it always safe to simply call the function.

Steve Gibson [00:47:03]:
It will always be present and simply calling it can never fail. So not only was the use of that try catch construction provably and obviously unnecessary to anyone looking at the code, because the conditional expression it contained, that's all it contains, is one conditional expression was first testing for the presence of the function and only calling the function if it existed. So that conditional test itself was also completely superfluous. Because whatever that super destroy function might be, apparently it must always be present. That means that everything there, all of that code, other than simply calling the super destroy function directly, was superfluous. It was gratuitous nonsense. So how did this happen? It happened because today's LLM based AI, as we've been saying recently as we grown over the last year, to really deeply understand what is going on here, it doesn't understand even a little bit what it's doing. It doesn't know whether we're asking about the population of kangaroos in Australia or asking for code to destroy the super object.

Steve Gibson [00:48:31]:
It's all the same to today's AI. It's all just language. Which brings us to the main point of this. The thing that I thought was most interesting was the observation that AI generated code could and would become infected with nonsense code like this. That's a very interesting observation on the part of this manager, and I'm sure it tracks everyone's intuitive and growing understanding of the way today's LLM based AI operates. Today's AI is all just astonishingly sophisticated pattern matching. So somewhere along the way, AI picked up that conditional test construction of making sure that a function existed on an object before calling that function would be good. It doesn't hurt to do that.

Steve Gibson [00:49:30]:
But our code would get seriously bogged down. I mean, like the world's code would get seriously bogged down if we were to keep asking the runtime manager to verify the presence of known existing functions before every time we called one. The point is that testing like this for a function that might not exist is a good thing to do. So there's a place for it. And AI picked up on that useful instance without any understanding of why, and is now salting the code it produces with that nonsense without need. Alternatively, you could protect yourself from a missing function by wrapping it in a try catch construction. We saw that too. So in this case, the AI did both of those things when neither were necessary.

Steve Gibson [00:50:33]:
It didn't know why. It was just copying stuff it saw elsewhere where there actually was a need. But in this case, there's no need yet. It still copied that code because it saw it elsewhere without ever understanding it. So here's where the notion of infection of course comes in, which is from promulgation. We know that AI is training on what it finds out on the open Internet, even if what it finds is code that it or some other AI previously emitted. That means that superfluous code like what we've just seen, which does not cause errors but adds nothing other than overhead and bloat, will tend to be self perpetuating. If this manager did not proactively strip this crap out of gnome's open source shell extensions code base, it would remain there.

Steve Gibson [00:51:31]:
It would get picked up by LLMs that were training on it, that would then further replicate it into the future. And the more it's replicated, the stronger it becomes. The pattern takes hold. Before long, code would be littered with this because non coders would be asking AI to write an extension without ever bothering or needing to look inside. Look, it works. Yes, and it's three times larger than it needs to be because there's all this am I me? Am I still me, Am I going to be me Crap. This, that's, that's like loaded into this. So I wanted to spend some time on this because I think it clearly represents a danger to open source code.

Steve Gibson [00:52:19]:
The crucial thing to appreciate is that AI is producing code that it does not understand. It's amazing that it's able to do so, but it's not without, you know, some downside risk. And any code that doesn't actually cause an error, that forces. It, doesn't cause an error that would force it to be debugged and to be corrected, that code won't be corrected or removed because it works. And if it's put back into circulation, other AI will train on it and it will continue to live and get amplified. So that said, I'm sure that all is not lost forever because I'm one. As I've been saying from the start, I am 100% just like this guy is who wrote at the end of his posting. I am 100% absolutely certain that some future coding AI, which we don't have yet, that's been specifically designed for coding, will look at the code that was emitted by these early LLMs like we've just seen and shake its electronic head.

Steve Gibson [00:53:44]:
It would be able to see and actually understand the code used in this example. It would know that super.destroy function must always be present in the super object. It would know that the super.destroy function can always be counted on to be present. So it would remove the conditional test for its presence. Then it would see that what's left in the try block, which is just that function call cannot possibly fail. So it would completely remove the try catch construction and all of the code from the catch block, which would also be removed because it could never be executed. We're not there yet. The point is we could contain the problem in the short term just by not blindly submitting AI code back into the public repository pool where AI will train on it and amplify bad practices.

Steve Gibson [00:54:50]:
You know, not things that produce errors, but things that just produce bloat until in the future we end up having truly smart coding AI. I'm, I'm sure that's coming because code can be understood by a computer. I don't think language can necessarily be understood or at least not where, where we are today. Code can. It, it, it's, this is going to be possible. So there is hope for getting the, you know, even the, the, the human generated code cleaned up. I suspect leo. But anyway, I thought this was a really, it was just a perfect example of what is actually being seen in the wild, what AI is producing, why they've had to tighten the guidelines in this instance.

Steve Gibson [00:55:41]:
And unfortunately it's unlikely that the majority of the AI generated code that is being put back into the public arena is being checked by people who know better than to allow this slop, which doesn't produce errors, to persist. So the, the, the, the, the, the future is true coding AI that is able to look at this and just say, okay, we don't need any of this crap, let's get rid of it and we're just going to call the function.

Leo Laporte [00:56:14]:
Maybe it's being super cautious, that's all.

Steve Gibson [00:56:17]:
Wasn't that a cool, a cool example?

Leo Laporte [00:56:19]:
I'm not sure I agree with the example, but there's a debate going on in the discord from some of our more accomplished programmers who say, well, you don't ever want to assume that Super Destroy is going to work and if it throws an error, you want to catch the error if you can. I don't know if the type of is necessary.

Steve Gibson [00:56:39]:
That's maybe, well, and, but, but when you catch it, all you're doing in this example is throwing up a message, another error. So that doesn't, that doesn't help anything.

Leo Laporte [00:56:48]:
That's true. It's a good point. Yeah, I don't know. Yeah, there's, there's, there's this, there's discussion about it. It's fine.

Steve Gibson [00:56:56]:
So whether Super Destroy fails to destroy something, we're talking about its existence, not the, the, the, the, the value that it.

Leo Laporte [00:57:07]:
Well, it's both, it's both because it, it asks for a type of, it says, is this a function? I think that's superfluous. It's obviously a function and then it runs it and it in the try. So if Super Destroy failed or didn't exist.

Steve Gibson [00:57:20]:
But we know it exists. The author said, the author said it is known to exist in this environment.

Leo Laporte [00:57:27]:
Darren says, and maybe he's being facetious. It's JavaScript, you never know what exists. He's probably, probably making a joke. He also, I mean look, he coded for financial institutions where they probably do bend over backwards to make sure to catch errors, right? And that's a, that's a mindset, you know, and who knows, maybe that's where the AI got it. I don't know. But I'm sure there's other, many multiple examples in the, in the GNOME extensions of obviously AI generated crap. That's part of the problem is a lot of the people who do this are karma farming. They're not really trying to create useful extensions.

Leo Laporte [00:58:10]:
GNOME extensions are great, I use them all the time. But there are also people out there who just want to say, look, I put an extension, they want to get GitHub stars or whatever it is, and they aren't actively contributing to the ecosystem. And I think that's more of the.

Steve Gibson [00:58:24]:
Problem that like the Android apps, how many?

Leo Laporte [00:58:28]:
Right. Exactly.

Steve Gibson [00:58:29]:
Oh my God, exactly.

Leo Laporte [00:58:31]:
And AI makes this possible at scale, right? Because somebody with no coding skill at all can, you know, create some slop. And he's just trying to keep the slop out of the, out of the extension library. The extension library is already ungainly big and full of old stuff and bad stuff. So I can understand why he might want to restrict some of the AI.

Steve Gibson [00:58:51]:
Slop it's going to. You know, having some AI overlords may not be that bad, you know, Leo, I don't know. I'm not sure that we're demonstrating.

Leo Laporte [00:59:00]:
Can we do worse than humans have done? Right? I don't know. Exactly.

Steve Gibson [00:59:07]:
Okay, so the, the deliberate pollution of our industry's open source repositories not by well meaning authors and AI, but by malicious actors is one of the most unfortunate but retrospectively obvious problems of the open source movement. Right? I mean the altruistic goal is to allow all well meaning actors to share or well meaning coders to share and share alike. It's like, hey, I wrote this, this is useful. Here it is in case it's good for anybody else. You know, it's a wonderful concept in principle. It was. What's his face is the open source guy. I'm blanking on his name.

Leo Laporte [00:59:51]:
Linus Torvalds. Oh, Richard Stallman.

Steve Gibson [00:59:54]:
Stallman, yes. Stallman is like original. Perfect concept of let's all. All software should be free and you know, we just put it out there and people can use it and they can improve it and then everybody gets their improvements and so forth. Well, great. How's that working?

Leo Laporte [01:00:13]:
Pretty good actually. Nothing, you know, you wrote Emacs. I'm pretty happy with it.

Steve Gibson [01:00:19]:
Nothing has ever been more prone to abuse, however, because the entire system is built on the assumption of goodwill. Yeah. By those who are contributing. Yeah. As the year 2025 draws to a close, we're able to look back now on this past year and compared to 2024, as usual, the volume of packages submitted to NPM, that's the Package Management Management Repository for JavaScript in 2025, far outweighs what's seen in any of the other repository ecosystems. The primary reason for this is that when looking at web applications, regardless of the backend technology, you know, whether you've got Java or Rust or C Sharp or whatever on the back end, it is most common for the front end UI to be built using JavaScript or TypeScript. Right. That's what our browsers typically run.

Steve Gibson [01:01:19]:
You know, that's the scripting in the browser itself. So these front end technologies largely depend upon npm. Adding to this is the fact that it's very straightforward to author and publish packages to npm, which explains why there's a consistent, consistently high level of activity there. I've got a pie chart here at the top of page six which shows the breakdown of the public repositories. NPM, this JavaScript repository holds 2/3 of the entire repository segment. NuGet holds second place. That's the repository for the dot net ecosystem. It's got 20% which is puts it in number two ranking compared to NPM's 65.5.

Steve Gibson [01:02:15]:
Just shy half a percent shy of 2/3, 66%. In third place is PI. PI. We're also often talking about problems there. It's got 13.1% but those three, those top three are followed by in order of really diminished share.

Leo Laporte [01:02:32]:
Tiny cargo.

Steve Gibson [01:02:34]:
Yes, Cargo, Ruby, Gems, Go Lang and Maven.

Leo Laporte [01:02:39]:
Cargo's for Rust, Ruby, you Gems, obviously Ruby go and go. I what Maven. What is Maven? I don't know what maven is.

Steve Gibson [01:02:45]:
Good question. I didn't even I didn't look it up. Yeah, but taken together, those top three three comprised 98.5% of the entire space, with those also rans holding a total aggregate of one and a half percent. So overall compared comparing this year 2025 as we're closing out to the same period in 2024, there was an 86.8%. So not quite doubling, but close 80 86.8% increase in malicious submissions of all kinds relative to the same period last year. To give everyone some sense for this, here are the counts and the natures of what bad guys were hoping to slip into the repositories and slip into other users and developers. Code bases 4196 packages were specifically designed to target organizations or groups often linked to cyber espionage or financial theft. More than 58,000 packages contained URLs known to be malicious, underscoring the growing risk of dependency injection attacks.

Steve Gibson [01:04:11]:
Right, where where the code itself might not be malicious, but when it's running, it reaches out to a known malicious URL to bring some dependencies in which are then malicious. A whopping almost 930,000 packages included pre compiled binaries. What's in that pre compiled binary, I wonder? Right? Creating potential attack vectors for binary tampering. 161,000 packages executed suspicious code during their installation. 38,000 packages made server requests to IP addresses attempting to communicate with command and control servers. More than a million packages attempted to obfuscate their underlying code, making detecting malicious activity much more difficult. I should note that I don't remember these the statistic I saw it, it was something like Mike, most of these things had mildly downward aiming trends. This obfuscation of underlying code saw like a 1200% jump in the last year.

Steve Gibson [01:05:28]:
That's like the big thing to do now is to obfuscate your code. But you know, there are reasonable reasons to do that. Like it's proprietary and you'd like to protect your proprietary product. Like I would imagine that, you know, some of our password managers have deliberately protected script that they need to run in the browser, but they would rather not have people messing with it. Nearly 5,000 packages were identified as typo squats in indicating a concerted effort by attackers to just trick developers into installing malicious versions of popular packages. We've talked about typo squatting years ago where you know, closely named packages were actually being downloaded because someone just mistyped it. It didn't generate an error because guess what, some bad guy already stuck a package there by that typoed name. And that's what you're downloading now.

Steve Gibson [01:06:29]:
Without realizing it, more than 61,000, almost 62,000 spam packages were published across across the ecosystems, severely degrading the integrity of the open source repositories just by filling them up with crap and threatening the trust the developers place in these platforms. I would be very wary about trusting them at this point. And more than 206,000 packages were flagged as containing crypto critical malware. 206,632 packages again flagged as containing critical malware. And we, we, you know, every few weeks I just remind everybody by noting how many hundreds of NPM packages were removed because they were containing malware. Well, the aggregate of that over the year to almost 207,000 packages were found just, you know, just malicious containing crap that, that were posted in the repository. The Vera code group who make it their business to keep an eye on all this, wrote about the trends that they've been seeing changing over the last year. They said we observed several trends across these categories of malicious behavior when compared to last year.

Steve Gibson [01:07:51]:
Most notably, it is now common for packages to make use of obfuscation, as I noted, a normally benign technique used to make the code harder to analyze or reverse engineer in order to protect intellectual property. However, attackers are leveraging this to disguise malicious payloads and make detection significantly more difficult. We saw a rise in code that executes during package installation. This is particularly problematic for malware analysis when malicious code is fetched from outside the package itself, for example via a file download from a URL during installation using pre and post install hooks. This dynamic nature makes it difficult to be certain whether a package is malicious or not, as the contents of the file behind the URL could change over time, right? Swapping out a benign or legitimate file for a malicious payload. There was a reduction in dependency confusion attacks this year, suggesting tactics to target specific groups or organizations for financial gain have changed and other more effective means are being used instead. So unfortunately, there's no easy solution to this, right? The repositories are so popular because they serve as a source of, in many cases, terrific ready made code that solves real problems that developers have. Rather than continually reinventing the wheel, writing your own package to do something, use one that's proven if you can.

Steve Gibson [01:09:36]:
The only thing developers can do is to remain vigilant and inspect anything that's downloaded. Unfortunately, because benign behavior, as they noted, can change when behavior is based on whatever is is pulled from a URL, even an initial all clear might not be enough caution. So, Leah, we're at an hour. We're going to talk about China next. But let's take a break.

Leo Laporte [01:10:05]:
Moving fast. All right. You're watching Security now. Steve Gibson, I'm Leo Laporte. We're glad you're here. Of course, I know you're glad you're here. What would you do on a Tuesday if you didn't listen to security now? That's my question for you. By the way.

Leo Laporte [01:10:20]:
We will have a show next Tuesday, Christmas eve Eve, the 23rd and then the 30th. We're going to do a special Steve is going to bring back. We are going to bring back Steve's classic 2000, I think it was 2009, vitamin D episode, which really in the intervening 16 years has really proven to be kind of prescient and quite smart. And I think probably thanks to it, a lot of our listeners stayed healthy through the COVID pandemic, as Steve did. That will be replayed. There is no video because it was an audio show. Steve and I will record an open to it tomorrow or just to kind of set it up. But I understand Anthony Nielsen has done something interesting so that we can put it on YouTube.

Leo Laporte [01:11:09]:
There will be some video you can think kind of think of as your geek Yule log, I think is the idea, but I'm not sure exactly. Stay tuned for that. Our show today, brought to you by Delete Me. Ever wonder how much of your personal data is out there on the Internet for anyone to see? Don't look. It's a nightmare. It's a lot more than anybody really should ever have to see. Your name, your contact info, your Social Security number. Can you believe in this day and age it is not illegal to buy and sell people's Social Security numbers, home addresses, even information about your family members.

Leo Laporte [01:11:47]:
And here's the thing. It's all being collected, compiled by this industry segment called data brokers that again, completely legal in the US and they data brokers, they will compile that information and then sell it along to the highest bidder or any bidder. It's actually pretty cheap. Forget the highest, says the highest, anybody. That includes, of course, marketers, but also law enforcement, includes nation states, includes China. Anyone on the web can buy your private details and the impact can be pretty horrific. Identity theft, phishing attempts. That's what got us using Delete Me.

Leo Laporte [01:12:25]:
People were impersonating our CEO and, and trying to extort money out. Fortunately, we have a smart team. But I don't know, you know, you don't want to allow that. It can be a source of doxing and harassment. Look, you can protect your privacy and you should. With Delete Me, you absolutely have to protect yourself. Unfortunately, Congress hasn't done it. The laws haven't done it, the states haven't done it.

Leo Laporte [01:12:51]:
That's why I personally recommend and why we use Delete Me, especially a business. You should have delete me for all of your managers. Trust me, I know. Delete Me is a subscription service that removes your personal info, just wipes it from hundreds of data brokers. You sign up, you tell Deleteme exactly what information you want deleted and then their experts will take it from there. Now, it's not just a one time service. They will delete all that information. And the reason it's not one time is twofold.

Leo Laporte [01:13:22]:
One is there's always new data brokers every day. Somebody gets in this business because it's a lucrative business, it's a great business. But two data brokers, not exactly the most respected members of society, shall we say. Yeah, you deleted it, but there's nothing to stop them from saying, oh, look at this. I don't know if it's the same, but I'm gonna start collecting this information and, and your dossier gets built right up again. So Delete Me goes out and they check again and again. They send you regular personalized privacy reports showing what they found, where they found it, what they removed. We just got one the other day for Lisa.

Leo Laporte [01:13:58]:
Delete Me is always working for you. They're constantly monitoring and removing that personal information you don't want on the Internet. To put it simply, Delete Me does the hard work of wiping you, your family, your employees, your managers, your businesses. Personal information from data broker websites. Take control of your data. Keep your private life private. Sign up for Delete Me for a special discount just for you. Our listeners today get 20% off your delete Me plan.

Leo Laporte [01:14:25]:
Your individual plan when you go to joindeleteme.com twit and you use the promo code TWIT at checkout. Now this is the only way to get that 20% off. Go to JoinDeleteMe.com TWIT Enter the code TWIT at checkout. Join Delete Me. One word, JoinDeleteMe.com TWIT. Make sure you go there and use the offer code twit for 20% off. Thank you, Deleteme. You're doing important work.

Leo Laporte [01:14:51]:
So is this guy right here, Mr. Steve Gibson.

Steve Gibson [01:14:54]:
Okay, so.

Leo Laporte [01:14:55]:
Oh, boy.

Steve Gibson [01:14:58]:
We've recently talked about the various countries becoming Worried after their discovery of multiple undocumented cellular radios and hidden inside their widely deployed Chinese made electric buses. In the first case that we reported, the buses were driven into what was described as bus size Faraday cages to cut off all radio access, to cut them off from any outside monitoring or control, and all of the SIM cards were removed from their secret cellular radios. The news of these buses wouldn't have surprised any of our long term listeners since we had previously reported upon the similar discovery of undocumented cellular radios in Chinese made dockside shipping cranes and the inverters used to convert the DC current produced by wind turbines and solar panels into ac. So we have all that already and it's a lot. We might think that it would be difficult to further surprise and worry us, but when you learn that from 2010 to present, Chinese researchers have published 2723 research papers, most never translated into English on the subject of vulnerabilities in the United States power grid. That's a bit of a wake up call. 2,723 papers with at least 225 of those papers, so not quite 10% of them, but still 225 which explicitly explore potential attacks on on the US power grid. I sincerely hope that people over on this side of the Pacific who are in a position to do something about this are also studying these papers and not sitting around waiting for something bad to happen because China is apparently prepared.

Steve Gibson [01:17:12]:
Strider Intelligence's report is titled In Broad Daylight US Grid exposed to Risk from PRC Manufactured Inverter Equipment. They wrote the People's Republic of China is systematically targeting America's critical infrastructure as part of a long term Strategy. Again since 2010, so 15 years of research, security research papers, long term strategy to gain leverage in a crisis. These are coordinated campaigns to pre position access across the systems that keep the US running. I mean it sounds like science fiction, right? But no, they wrote. This new report from Strider details the United States growing dependence upon inverter based resources. That's they have an acronym ibr, Inverter Based Resources including solar inverters and battery energy storage systems manufactured by companies in the People's Republic of China. These networked software driven devices are capable of remote communication and control which when combined with their PRC origin, expose US critical infrastructure to unprecedented risk.

Steve Gibson [01:18:39]:
Now you know, just to pause here for a minute, we know there are people in the United States who if they appreciated this, like our, our senators and representatives in Congress would be freaking out over the idea that this is true. So again, I hope Somebody's paying attention, they wrote. Under the PRC's 2017 National Intelligence Law, any domestic company that is Chinese domestic company can be compelled to support state intelligence activities. There's no doubt about that now. As a result, PRC made inverter based resources inherently carry elevated security risks regardless of direct ties to high risk entities. Strider's analysis found that nearly half of of all inverters and battery energy storage systems imported into the United States between 2015 and 2024 came from a high risk PRC manufacturer. Additionally, 86% of U.S. utilities surveyed for this report, representing about 12% of the installed U.S.

Steve Gibson [01:19:52]:
capacity, rely on at least one risky PRC supplier in their power composition. Three of the high risk PRC suppliers found were First Contemporary Amperex Technology CATL. In 2025, the U.S. department of Defense labeled CATL a Chinese military company flagging national security and sanctions exposure. They're one of the suppliers of the hardware we're using in the US Huawei. The company has a documented history of IP theft accusations, export control violations, and close alignment with the PRC military intelligence and law enforcement entities. Huawei was added to the U.S. commerce Department's entity list and banned from U.S.

Steve Gibson [01:20:45]:
5G networks over espionage risks. But there's no federal rule banning Huawei solar inverters. So in they flow. And finally, Sungrow, the company's CEO and chairman, is a member of the National People's Congress, the legislative body of the PRC state. And nearly 30% of Sungrow's senior management are members of the Chinese Communist Party, they said within the 2,723 PRC research publications examining weaknesses in the US energy grid at least, and here's that number. 225 of those publications related to potential attacks against the US grid, including multiple publications that ran attack simulations on the Western U. S Power grid to test new concepts, methods and tools of attacking us. Okay, so you know, we.

Steve Gibson [01:21:50]:
Leo, we've talked about this. The US And China have the most bizarre interdependent relationship.

Leo Laporte [01:21:59]:
This is strange.

Steve Gibson [01:22:00]:
It is. Perhaps codependent would be a better term. Yeah, I don't understand it. But then frenemies.

Leo Laporte [01:22:07]:
I also. Cooperative frenemies.

Steve Gibson [01:22:11]:
I also don't understand the world's superpowers having their nuclear arsenals all aimed at each other. That's also crazy. So perhaps this cyber war nonsense is much the same as the nuclear standoff that has been in place now for decades. Let's just hope that no one ever makes the mistake of pulling any triggers. So it's like you don't attack us, you know, you don't shut down our power grid. We're not going to shut down your power grid. Nobody wants their power grid shut down. And.

Steve Gibson [01:22:45]:
And wow. I guess this is just the way it goes now. Yeah.

Leo Laporte [01:22:49]:
Yeah, it's very strange.

Steve Gibson [01:22:51]:
Wow.

Leo Laporte [01:22:53]:
It's like the Cold War kind of, right?

Steve Gibson [01:22:56]:
It is. No, it absolutely is. It is. You know, and as I said, I've recently, we did get some intelligence that suggests that we are every bit as much in their networks over there as they're in ours over here. And I guess both sides understand that. And it's just kind of a status quo. And meanwhile we're gonna buy stuff and they're gonna buy stuff and let's just, you know, hope they don't.

Leo Laporte [01:23:30]:
Ton of real estate in the US and they probably are a single largest holder of American bonds. So I don't know what the answer is. I really don't.

Steve Gibson [01:23:42]:
No. It's crazy. Okay, following up on last week's podcast, which I titled reacts Perfect 10, last Friday the 12th, Google updated the world on the 5 once again Chinese state actors that have been actively attacking the west through this distressingly easy to exploit and widespread vulnerability in REACT servers. Google's Friday posting was titled Multiple Threat Actors Exploit react to Shell CVE 2025-55-5182 and they wrote on December 3, 2025, a critical, unauthenticated remote code execution RCE vulnerability in REACT server components tracked as that cve, AKA React to Shell was publicly disclosed. Shortly after disclosure, Google Threat Intelligence group GTIG had begun observing widespread exploitation across many threat clusters ranging from opportunistic cybercrime actors to suspected espionage groups. GTIG has identified distinct campaigns leveraging this vulnerability to deploy a minocat Tunneler, Snow Light downloader, Hisonic Backdoor and Compud backdoor, as well as XM Rig cryptocurrency miners, some of which overlaps with actively previous with activity previously reported by Huntress. You know Huntress Labs. These observed campaigns highlight the risk posed to organizations using unpatched versions of React and Next js.

Steve Gibson [01:25:40]:
This post details the observed exploitation chains and Post compromise behaviors and provides intelligence to assist defenders in identifying and remediating this threat. Okay, now Google then reminds us they spend some time in their posting reminding us about the nature and background of the REACT problem, which I'm going to skip since we covered that at length last week. What I think is interesting and important for us to look at is what Google is actually seeing being done. They're watching it happen. All enabled by this perfect 10 vulnerability, which we first just talked about last week. It's one thing to say, oh, that's not good a perfect 10, but it's still useful to see exactly what that means. Like what does a perfect 10 do? So they write since exploitation began GTIG Again, Google's Threat Intelligence Group has observed diverse payloads and post exploitation behaviors across multiple regions and industries. In this blog we focus on China Nexus espionage and financially motivated activity, but we have additionally observed Iranian based actors exploiting the same CVE as of December 12th.

Steve Gibson [01:27:10]:
That's last Friday. GTIG has identified multiple China Nexus threat clusters utilizing the CVE to compromise victim networks globally. Amazon Web Services reporting indicates that China Nexus threat groups Earth Lamia and Jackpot Panda, which we talked about last week, are also exploiting this vulnerability. GTIG tracks earth Lamia as UNC 5454. Currently, there are no public indicators available to assess a group relationship for Jackpot Panda. Okay, so actual exploitations Minocat GTIC observed China Nexus espionage cluster UNC6600 exploiting the vulnerability to deliver the react to shell vulnerability. This perfect 10 vulnerability to deliver the minocat tunneler the threat actor retrieved and executed a bash script used to create a hidden directory. So retrieved and executed meaning they used react shell to get onto the server, then reached out from that server to retrieve a bash script which they then ran, which in turn obtained the minocat tunneler they said.

Steve Gibson [01:28:41]:
So retrieved and executed a bash script used to create a hidden directory. So it's it's under the home it's dot system d utils hidden directory. It then kills any processes named NTP client so network time protocol client. It then downloads a minocat binary and establishes persistence by creating a new cron job and a systemd service and by inserting malicious commands into the current user's shell config which will execute minocat whenever a new shell is started and also apparently based on a cron minocat they Say is a 64 bit ELF executable for Linux that includes a custom NSS wrapper and an embedded open source fast reverse proxy, an FRP client that handles the actual tunneling. So again, I think it helps to appreciate that these are not theoretical attacks, right? They are actually happening to real people and organizations. If this happens to a server, the fast reverse proxy client phones home to establish a persistent connection, then allowing bad actors, apparently Chinese bad actors to do whatever they wish with the compromised system. And the important thing to appreciate is that this is a persistence mechanism. The owner of the react server might have then patched it, rebooted it, restarted it, whatever, but it's too late.

Steve Gibson [01:30:23]:
The machine has already been owned and will continue to be owned until and unless the specific modifications that were made and this malware that has been installed and set up to keep running is removed. Another example Snowlight they wrote in separate incidents suspected China nexus threat actor UNC 6586 exploited the vulnerability to execute a command using curl or wget to retrieve a script that then downloaded and executed a Snow Light downloader payload. Snow Light is a component of V Shell, a publicly available multi platform backdoor written in Go which has been used by threat actors of varying motivations. GTIG observed Snowlight making HTTP get requests to command and control infrastructure to retrieve additional payloads masquerading as legitimate files. GTIG also observed multiple incidents in which a different threat actor, UNC6588 exploited the vulnerability, then ran a script that used WGET to download a compute backdoor payload. The script then executed the compud sample which masqueraded as vim. GTIG did not observe any significant follow on activity and this threat actor's motivations are currently unknown. Compud has historically been linked to suspected China Nexus espionage activity.

Steve Gibson [01:31:58]:
In 2022 GTIG observed compute in incidents involving a suspected China Nexus espionage actor and we also observed samples uploaded to virus total from Taiwan, Vietnam and China. So wow, you know this is all actually happening. We have two more hisonic another China Nexus actor, UNC6603 deployed an updated version right? Because you wouldn't want an old version an updated version of the Hisonic backdoor. Hisonic is a GO based implant that utilizes legitimate cloud services such as Cloudflare, Pages and GitLab to retrieve its encrypted configuration. This technique allows the actor to blend malicious traffic with legitimate network activity. In this instance the actor embedded an XOR encoded so weekly encoded just basically obscured configuration for the Hisonic backdoor delimited between two markers. They're just random hex strings to denote the start of the configuration and to market's end. Telemetry indicates this actor is targeting cloud infrastructure, specifically AWS and Alibaba cloud instances within the Asia Pacific APAC region.

Steve Gibson [01:33:22]:
And finally they wrote we also observed a China Nexus actor UNC 6595 exploiting the vulnerability to deploy Angry Rebel Linux. The threat actor uses an installation script b SH that attempts to evade detection by masquerading as the legitimate OpenSSH daemon within the etc directory for rather than its standard location. The actor also employs timestamping to alter file timestamps and executes anti forensics commands such as clearing the shell history using history hyphen. C Telemetry indicates this threat actor cluster is primarily targeting infrastructure hosted on international virtual private servers VPSs. So, you know, an example of true actual happening real world consequences of this vulnerability. I think it's important to appreciate again that, that real people and organizations are being hurt due to this vulnerability. It's unclear to me, as it was last week when we first reported on this, why the updated React server code was not given a great deal more time to filter out into the React server installed base before it was publicly disclosed to trigger this feeding frenzy. My guess is that any update to React would have triggered an investigation and reverse engineering of the changes by malign forces.

Steve Gibson [01:35:06]:
And since it was all, you know, React was is probably I didn't look. But if it's probably very easy to take a look at it and see what changed and know what was fixed. So perhaps it was better to make a big noise and just hope that, that that noise would be heard by people, legitimate users of the React server components, and it would get updated quickly. Unfortunately, this is a big bad one and you know, lots of people are going to get hurt from this and we know what's going to happen, right? This is about money. This is about bad guys making money. It's money, money, money, money, money. So they're gonna, they're gonna do what they can. They're gonna end up installing ransomware, encrypting data, exfiltrating data, and then holding these companies for ransom, hoping to get some money out of it.

Steve Gibson [01:36:02]:
They don't really care what these companies do. They're not interested. They just want money. And speaking of the React vulnerability, something else happened that we have also seen before when something bad was found in a significant piece of open source code. The pile on by the security researchers who all wanted to take a look and see what this was about, ended up turning up additional previously unknown problems. In this case, Meta React's original creator and chief maintainer has consequently released new security updates for the React JavaScript framework. The new patches fix two denial of service bugs and a vulnerability that can expose an app's source code. So there's a little tiny bit of silver lining for the otherwise devastating React vulnerability.

Steve Gibson [01:37:07]:
One thing we know is that motivating responsible security researchers to examine code is a terrific way to get it improved. And that happened in this case also last Friday, Apple moved to iOS 26.2, which patched two actively exploited zero day vulnerabilities in WebKit. Apple stated that the zero days were used in what they termed an extremely sophisticated attack and that the targeted users were still running iOS versions earlier than 26. So we don't know whether the major change that was made and we talked about it at length in iOS 26 that seriously hardened the kernel. We don't know whether those so called extremely sophisticated attacks would have worked against people running now this, you know, much stronger kernel that iOS 26 brings. But we do know that these zero days were being used in people with versions of iOS of iOS earlier than 26. We would hope that any target against whom it was worth launching what Apple is calling an extremely sophisticated attack would be someone who understood that upgrading older hardware that can run the latest protections, if indeed their hardware was unable to run iOS 26 is worth doing. You know, even if it means somehow tolerating Apple's way over the top UI nonsense.

Steve Gibson [01:38:56]:
You know, liquid glass, it's still worth having the the security and as we noted, you can turn a lot of the liquid glass off, making it significantly less liquid. And Leo, we're at an hour and a half in. I want to talk about. Let's encrypt at some length. So let's take a break and we're going to look at. Wow. Where let's encrypt is and what's going to happen with them next year.

Leo Laporte [01:39:25]:
I'm a little worried. Well, we'll see. But before we do that, let me talk about our sponsor for this segment on security now. Veeam Data resilience. This ought to be at the top of your to do list. When your data goes dark, Veeam turns the lights back on. Veeam keeps enterprises running when digital disruptions like ransomware strike. You need Veeam.

Leo Laporte [01:39:50]:
How does Veeam work? Well, by giving businesses powerful data recovery options that ensure you have the right tool for any scenario. Veeam gives you broad, flexible workload coverage. And this is one of the kind of pain points in having a reliable, resilient data backup is your data is everywhere. Clouds containers on prem on hard drives, everywhere. Which makes it tricky, right? With veeam you get full visibility into the security readiness of every part of your data ecosystem. And it works on every part. Tested, documented and provable Recovery plans. How's your recovery plan doing? Huh? When did you update that last? They can be deployed with the click of a button.

Leo Laporte [01:40:36]:
This is really why veeam is the number one global market leader in data resilience. Just call him the global leader in helping you stay calm under pressure. We all need this with Veeam. It's all good. Keep your business running@veeam.com that's V E A M dot com. There's no reason for you to be in the headlines. Tomorrow's headlines about yet another company shut down by ransomware. No reason at all because you've got Veeam.

Leo Laporte [01:41:07]:
V E E A M dot com. Keep moving with Veeam. All right, let's talk about, let's Encrypt.

Steve Gibson [01:41:15]:
Steve, you've got Veeam and you've got us.

Leo Laporte [01:41:18]:
Yeah, yeah, right. But I often wonder when you hear about these companies like Jaguar down for a month, it cost a huge billions of dollars. Don't they have backup? But I, you know, and I've learned, I've since learned it's really hard for enterprises because their data's all over the place. It's a complex system. It's not as easy as me just backing up my stuff on a synology.

Steve Gibson [01:41:42]:
And backup is always sort of an afterthought, right? It's like, let's get it going. It's the lowest going first. And then it's like, okay, but wait a minute, next week was going to be for doing backup. Oh no, no, we need you to do this now.

Leo Laporte [01:41:54]:
Right?

Steve Gibson [01:41:55]:
Do that later. Yeah, right. Okay. So let's Encrypt will cross a significant milestone in 2026 next year, with traditional certificate authorities establishing increasingly stringent security requirements to avoid spoofing. And with the coming ridiculous short lifetime certificates that will be putting a practical end to manual web certificate management. The lure of simply obtaining a domain validation certificate by Pro by providing proof of domain control through a DNS lookup and an ACME server listening at port 80 of the domain's IP. Well, that solution was always going to win. And winning it is.

Steve Gibson [01:42:51]:
Early last week, John Ass AAS over at let's Encrypt posted 10 years of let's Encrypt certificates. He wrote on September 14, 2015. So a little over 10 years ago, our first publicly trusted certificate went live. We were proud that we had issued a certificate that a significant majority of clients would accept and had done it using automated software. That's the ACME protocol that makes that possible. Of course, he says, in retrospect, this was just the first of billions of certificates. Today, let's Encrypt is the largest certificate authority in the world in terms of Certificates issued. And we've talked about that, right? We've seen a pie chart.

Steve Gibson [01:43:42]:
It's like the vast majority of certificates are now let's encrypt. He said. The ACME protocol we helped create and standardize is integrated throughout the server server ecosystem and we've become a household name among system administrators. In 2023, we marked the 10th anniversary of the creation of our non profit and Internet security research group isrg, which continues to host let's Encrypt and other public benefit infrastructure projects. Now, in honor of the 10th anniversary of let's Encrypt public certificate issuance and the start of the general availability of our services, meaning 10 years ago, we're looking back at a few milestones and factors that contributed to our success. A conspicuous part of let's Encrypt history is how thoroughly our vision of scalability through automation has succeeded. And no one can argue with that. He wrote.

Steve Gibson [01:44:46]:
In March 2016, we issued. So March 2016, six years after they began, we issued our one millionth certificate just two years later, in September 2018. Okay, so two and a half years later, we were issuing a million certificates per day in 2020, two years later, five years ago, we reached a billion total certificates issued. And as a, as of late 2025, so now we're frequently, he wrote, issuing 10 million certificates per day. 10 million certificates a day, meaning on a rolling basis, 10 million certificates per day are, are reaching to the point where their expiration date is near enough that it is time for their server to request a fresh certificate from let's Encrypt, which it then receives and installs and then has another period during, you know, until it needs to do that again. We know that let's Encrypt certificates are 90 day certificates. So some amount of time shy of 90 days, the server starts thinking, okay, this certificate doesn't have much time left. Need to get another fresh 90 day certificate.

Steve Gibson [01:46:15]:
So think of that. Oh, and he finishes saying, we are now on track to reach a billion active sites. A billion active sites, probably sometime in the coming year. So that's the milestone for 2026, a billion sites. So think of that. One billion domain names, one billion certificates being continuously created, installed and replaced on a rolling basis on web servers across the world. That really is an accomplishment. As our listeners know, I've been a big fan and user of DigiCert's certificates ever since I, ever since I left VeriSign, who was later purchased by Digicert.

Steve Gibson [01:47:04]:
But this steadily shortening certificate life Means that within another year or two I'll be joining the teeming billions whose certificates all say let's encrypt. It's certainly no longer the case that let's encrypt certificates are in any way second class. The browsers collectively first decided to deprecate any extra value or, you know, cache provided by extended validation EV certificates. Remember we for a while we had a green bar and, and. Or a, you know, extra glowy something. It was good. So now there's no reason to pay anything extra for those because users never see them right. Consequently, generic domain validation DV certs have become the norm.

Steve Gibson [01:47:59]:
Then the CA browser forum decided to abandon reasonably long lived certificates. Just just as Mozilla's efforts to solve the certificate revocation problem finally succeeded, offering total privacy based on client side Bloom filters. They got it working. We now have revocation in real time with no privacy consequences. And we're going to abandon that. We're going to go basically real time certificate issuance. Lord help us. So as we've seen, the people who are driving the decisions behind technology do not always arrive at what looks like the best solution.

Steve Gibson [01:48:49]:
But we at least can all celebrate let's encrypt achievement. That said, I still shudder at the idea that a billion websites. Think of this. A billion websites will all be dependent upon a single service for their certificates. And that if anything should happen to that service, websites will begin dropping off the air at the rate of 10, 10 million per day, which is the rate at which they are now issuing new certificates. 10 million certificates per day. Websites will begin dropping off the Internet at the rate of 10 million per day if let's Encrypt is ever unable to renew them before they actually expire. You know, the genius of the Internet's design has always been its distributed diversity without any single point of failure.

Steve Gibson [01:49:50]:
How many times is. Oh, that's a big benefit of the Internet. No single point of failure. Well, we've just created one. This changes that. I hope we know what we're doing. And this is on the CA browser forum. If this, if this ever collapses.

Steve Gibson [01:50:06]:
Because they're the people who did this who shortened the certificate lifetime and actually unfortunately it's Apple that, for reasons I don't understand.

Leo Laporte [01:50:16]:
Yeah, I just don't get it.

Steve Gibson [01:50:18]:
Forced this to happen. It's just. No, this, we, we fixed this. We solved the problem. You know, yes, the, the original lists of revocations, the CRLs, the, the certificate, the original certificate revocation lists, they had a problem. We switched to OCSP to, to, to solve that. That had a privacy problem. So we fixed the CRLs with Bloom filters so, so that it's now absolutely possible to maintain an instant availability, a quick knowledge of, of revocation.

Steve Gibson [01:50:56]:
But we've abandoned that and we're now going to go to real time issuance. It's like somebody wants to have absolute control over the issuance of these certificates. Unfortunately, as I said, that is not the Internet way. And it really does create a, a, a, a single point of failure which our entire system, I mean the reason the Internet has, has survived is that it hasn't had that before. Seems like the wrong thing and it seems like it was completely unnecessary. I just don't get it. Yeah, what I do get is 10 days of the DNS benchmarks success. Now that it's been exposed to a much wider audience.

Steve Gibson [01:51:44]:
I should mention that we are now at its third release. We were at release one this time last week. Anybody who purchased it now will get the third release. And anyone who runs releases one or two will immediately see a pop up, giving them the notice that there's been an update and a link where they can download it and immediately update themselves. As I said, I'm no longer going to hold the release of something up until it's like this. It's absolutely known that I will never have to change it again. That did make sense. Back when I was duplicating disks for Spinrite, we were packaging them in boxes and sending them to egghead software to stick on a shelf.

Steve Gibson [01:52:34]:
Today we have a connected world and so it just makes more sense to, to, to put something out which is, you know, really good and where every known problem is solved. And that's what I waited for. Took a year to get there. But as you expose it to a lot larger audience, you're going to find things you didn't find. So for example, the primary incentive for the second release was this was a bug of mine. The discovery that I had not allocated. You'll love this, Leo. Large enough string buffers in the code that posts the conclusions which contains and shows the total number of packets sent and received.

Steve Gibson [01:53:20]:
When I allowed eight characters I had, I had eight character buffers. So because ASCII strings are null terminated Pascal strings, the first byte of a Pascal string is the byte is a byte with the length of the string. The problem is that limits strings to 255 characters. We switch to what's called null terminated strings, where you have ASCII characters or Unicode characters, which, and you signal the End of the string with a null byte or two. In the case of Unicode, that makes the strings able to be of any length. Of course, it does make them a little vulnerable to mistakes where then you keep looking for a null and bad guys can arrange to do things and so forth. But the technology is nice anyway, the original benchmark, well, maybe it would send 30,000 packets. So that would be 30 comma 000 and a null.

Steve Gibson [01:54:31]:
So what, six bytes? And you couldn't do more than that? So I, I allocated eight byte buffers, no problem.

Leo Laporte [01:54:41]:
Nobody, nobody would ever need more than 8 bytes. Ever.

Steve Gibson [01:54:44]:
No. Then I introduced the benchmarks of 50x and 100x sampling modes. Whoops. 30,000 became 3 million.

Leo Laporte [01:54:55]:
Oh boy.

Steve Gibson [01:54:56]:
3 million is 3 comma 000 comma 000. Because I I comma eyes those strings. Well, that's 10 bytes. Oh, 10, that's okay, 10 bytes. And that overflowed the buffer. And so what you, what a couple users quickly reported was when they ran the 100X, you know, in fact, one of our, I think it may have been one of our podcast listeners purchased the benchmark. He said, I just decided to go for the gusto is the expression he used. And so as soon as he, he waited 45 minutes for this thing to finish and then it crashed, it's like, whoops, sorry about that.

Steve Gibson [01:55:36]:
So I immediately fixed the problem, updated to our, our second release, I doubled the buffers to 16 bytes and there's no way we're going to ever overflow those. So that's fixed now. The primary incentive for the third release was actually not my fault, but I'm glad for it. What we discovered was that we needed at least version 9 of the Windows WINE emulator. A surprising number of people are running the DNS benchmark under Linux and Mac, as I mentioned before.

Leo Laporte [01:56:10]:
Right.

Steve Gibson [01:56:10]:
And despite the fact that wine nine is nearly two years old and 10 was released at the start of this year, not surprisingly, who would be surprised, many people still have Wine 8. The problem is that Wine 8 predated the change in code signing from SHA1 to SHA256. The DNS benchmark verifies its own digital signature at startup to make sure that it was properly downloaded and saved and that there was no error anywhere. So it checks its own digital signature. Well, that was failing. For those who were still using wine 8, the problem was under the assumption that the only reason for a signature failure would be code modification. The error message that was being presented was confusing. It stated that something must have been altered.

Steve Gibson [01:57:07]:
Something must have altered the program after it was downloaded. Anyway, that wasn't true. It was that they were using wine 8. So I quickly pushed the third release out to end the confusion. Now the benchmark first checks to see whether it's running under Wine and if so, whether it's Wine nine or later. If it's Wine eight or earlier, it explains that the user will need the. The user who's. Who's using it on Linux or Mac on an old version of Wine will need to update to a later version of Wine.

Steve Gibson [01:57:42]:
So, and, and when there was one other thing that somebody wanted, somebody noted that it would be nice if contrl C copied all of the text from any of the many dialogues in the program to aid in translation. So I thought, oh, that's a really good point. So I, you know, that's in there now too. So we've received a bunch of gratifying feedback, some from people who cannot get their head around the the fact that so much is packed into 215k bytes, you know, everything it does, and all of the descriptive dialogues and Windows that it contains 215k, you know, small JPEGs are bigger than that. You know, we've all become so abused by the ridiculous multi hundred megabyte monstrosities that we've lost sight of how dense and expressive actual code can be. I'm surprised, frankly. I'll like write a whole bunch of stuff to do to add some new feature and the program only got a K bigger. It's like, wow, this is great.

Steve Gibson [01:58:51]:
Anyway, the other feedback has been as predicted from people who are commenting that they were happy with their local DNS resolver, whose caching performance was insanely high. The problem with having an insanely high performance local DNS router cache is that its contents will be largely the same as the DNS cache in Windows itself, because the request from Windows will be what caused their local router to load its cache in the first place. So Windows won't ask again for anything that's already cached, since Windows will already have it. Therefore, caching performance just doesn't matter. What really matters is the mix of queries. And that's what I've understood and that V2 offers. So people have been saying, hey, I was really happy with my DNS setup, but version two, I'm gonna have to make some changes. So of course that's good news because it's more correct than.

Steve Gibson [01:59:51]:
Than the way we were doing it before. Anyway, it's been, it's been Good. And I do have something to fix coming up, but I don't have a solution for it. Yeah, I don't even remember what it was. It just, it's something that came up this morning. So everybody who purchases gets whatever is the most current. And I'll check back next week and let people know where we are.

Leo Laporte [02:00:12]:
So is there an auto update feature or do you have to download?

Steve Gibson [02:00:16]:
Well, a lot of our developers said I don't like code that downloads itself. So what there is is a link you can click and then that takes you to the page that allows you to get the new code, which I think is the best thing.

Leo Laporte [02:00:31]:
Yeah, that's, that's good.

Steve Gibson [02:00:34]:
Listener feedback. Scott Wise wrote Steve, an issue I see with age grouping or the over age token credential for age verification that I'm sure you've thought about. Oh and actually this is a really great point, but I don't remember hearing discussed is that it will disclose your birthday on your birthday. Okay, now listen to this guys. This is kind of cool. He said if you need to be a certain age to access a service, be it physically or virtually, you likely do it on or very near your birthday. A common one is going to is going drinking on your birthday. When you are exactly old enough in the physical realm, you'll likely get a congratulations and maybe even a free drink, but they don't share your personal information with others.

Steve Gibson [02:01:27]:
If you need to be a certain age to access social media, you are likely to create an account on your birthday and you should be assured that the company. Oh and he says and, and you could be assured or should be that the company will sell that information to as many others as they can. You know, taking a, a jaundiced view, which I understand. He said reaching certain ages will trigger different ads. Driving age will likely trigger car sales ads and reaching the drinking age may trigger alcohol ads. These will happen regardless of your actual birthday as they would fall into the age group identification. He says I don't know all the ramifications of disclosing your birthday, but a few I can think of would be enhanced phishing, fake account creation and password guessing. This isn't a reason to stop the work on age grouping or the over age token credential, but I think it should be considered.

Steve Gibson [02:02:26]:
Signed Scott in Regina, Saskatchewan, Canada. So I think Scott makes a terrific point. Think about this in a in a world where accounts on highly desirable services are age gated the first time start use of those services could reasonably be used to infer something about an individual's age now back in the 70s, though apparently less so today. Knowing when someone had obtained their driver's license would, with some accuracy, probably tag their age. You know, apparently today's teenagers feel less urgency to drive than I did. You know, that urgency to drive may put it off. Yeah. May have been replaced with an urgency to use social media.

Steve Gibson [02:03:19]:
I don't know.

Leo Laporte [02:03:20]:
But they want to stay home.

Steve Gibson [02:03:22]:
Yeah. But if we imagine a world where having, where we do have robustly solved the online proof of age problem, it is easily foreseeable that anyone turning 16, for example, in Australia and soon in many other jurisdictions, would immediately like, it's like, hey, I'm 16, I finally can do this. They would immediately join the many services that they would then be able to on the day of their 16th birthday. So as Scott, I think very astutely points out, that does constitute a strong age disclosure, which, or, you know, birth date disclosure, which I'd never thought about before. Mr. Gekko said there's one problem with the age verification solution that's being worked on and that is the discrimination of what device and operating system one must use to be considered valid. The attestation system discriminates against open source operating systems. He's right.

Steve Gibson [02:04:33]:
Browsers and even presents prevents new competition from being able to start. This means to use the Internet, social media or anything considered adult content. One must use an Apple or Microsoft based computer with an Apple, Microsoft or Google browser and one must use iOS with Safari or one of the approved Android phone vendors with original software. This will be very, very bad and no one is talking about the issue from this standpoint. He said. I personally install an open source operating system on both my phone and PC to get away from the privacy invading companies. Once these laws come into play, I won't be able to use Facebook to contact my parents who would not use Signal or any other messaging solution and will be treated like a bad guy because I decided to go for privacy. So I think this is another Great point.

Steve Gibson [02:05:34]:
Our Mr. Gecko here is noting that the requirement of bringing enforceable security to age verification means that platforms which are unable to offer true enforceability will not be permitted to assert their user's age. And as listeners of this, of this, you know, in the past know this is a common theme, right? Listeners of this podcast know this is a common theme. Hundreds of millions of Otherwise completely functional PCs are stuck at Windows 10 because they only contain hardware or firmware Support for version 1.2 of the TPM. And Microsoft has decided to require TPM 2.0 for Windows 11 and beyond. Another example is the de facto requirement that Windows executables be signed with an expensive cryptographic certificate that expires every few years for no reason other than to create revenue for certificate authorities. As Mr. Gekko noted, all of this is hostile to open source, open source and open platforms.

Steve Gibson [02:06:52]:
All security, as we've noted recently, absolutely requires the ability to robustly keep secrets of of some kind somewhere. Yet full openness is explicitly about never keeping secrets. The two concepts are fundamentally at odds with one another. Owen Legare says hi Steve, I have a question regarding the GRC SC bot check shortcut you created. You know, that's the thing that I that I recently mentioned where you you you can check the service that is that is watching malicious botnet activity and creating a database by ip. This allows someone to check that their current IP for for known bot activity, he said in the podcast discussion of the service. I don't recall any mention about when you get a result showing activity how to determine if that activity is from your network or whoever had been assigned that IP address previously. He's 100 right there, he said since most people get their IP address by DHCP, the activity could be from someone who had that IP previously.

Steve Gibson [02:08:13]:
He says if there if there is a way to determine how long you have had your IP address and the bot check site shows the dates when the malicious activity occurred, you should be able to determine if all the activity was before you were assigned the IP address. Is this the way to make that determination? Signed Owen. So he makes a very good point. For those whose IP addresses change often, this test would be inaccurate in both directions. It could produce false positives or false negatives by reporting on the condition of the network of whomever one or more people may have had that IP previously. The other problem is that IPv4 depletion has moved some large ISP hosts to carrier grade NAT. When an ISP has more subscribers than they have IPv4 addresses, and when they are unwilling or unable to upgrade their services to IPv6, they will be forced to place their own NAT routers between their subscribers and the Internet. Just as we end users have many more Internet gadgets than we have public IP addresses.

Steve Gibson [02:09:32]:
My point, typically we have one public IP address or two for IPv4 and IPv6. My point is that carrier grade NAT, which is becoming increasingly common will also obscure the truth since any One of the ISPs many subscribers may have been emitting malicious bot traffic from the public ip that is now assigned to the user running the bot check service. So it's true that all of those caveats need to be taken into consideration when using that free bot check service. For myself, my IPs with Cox Communications and my cable modems tend to remain static for years at a time. I mean I, I, I am able to establish static IP filters at GRC that knows my IP and, and I'm able to to lock ports and access based on those because they change so infrequently and even though they are dhcp, DHCP does try to reissue the same IP you had before. So there is an effort to maintain a static ip. I've told people in some cases where they had some reason to change their ip, you know, just turn off your cable modem overnight and after a long enough period of time when it comes back up it will probably have a new ip, but, but it needs to be a significant outage in order to get your IP to change. Still, Owen is right.

Steve Gibson [02:11:05]:
You could get false positives or false negatives if your IP has changed and that botnet and that bot check site is, is basing its appraisal on ip. Allen W said, oh, and Leo, you're going to love this. This is Allen, our voracious security now consuming semi truck driver. He said, steve, I last wrote to you at the end of October asking about a password of 63 plus signs. Oh yeah, I just finished that episode and you're right, I understand now. He said, kind of cool that I wasn't far off in my assumption of 63 plus signs being a strong, a strong password. Great episode, thank you. And he said, yes, I have listened up to episode 303 since late October.

Leo Laporte [02:12:01]:
He's got a way to go and.

Steve Gibson [02:12:03]:
Not yes, but he's, he's making good progress and I mean he's a third of the way to the infamous 999 so. Or almost a third. So he's getting close. And he said, and not just during my 70 hour work week driving a semi. He said, I found myself spending a large portion of my waking hours listening to Security Now. He said, I was thrilled when you read my last email on Security Now. And yes, my Python sensei Sean did indeed share that clip with me. As you mentioned, by the time I get caught up, I'll be a completely different person.

Steve Gibson [02:12:41]:
I see that already. As you can imagine, listening to 50 plus hours of security now per week while driving a semi and then listening more after hours has made me quite paranoid about everything security and it's constantly on my mind. Perhaps my brain is in overload. I took the week of Thanksgiving off and didn't listen to a single episode for six days. I felt less nervous about security two days into my break, but then during a train ride, the strangers at the table with me started talking about loving their debit cards tap feature and moments later I found myself lecturing everyone about what could happen thanks to that little chip.

Leo Laporte [02:13:26]:
Nice.

Steve Gibson [02:13:27]:
He's become an evangelist, he said. Later, I realized that most of what I said was probably based on information from before Michael Jackson died. But even in hindsight, no regrets. They got off light since I didn't make them all buy a copy of Spinrite before disembarking the train, he said. Since listening to episode 303, I'm going to ask about something you've mentioned a few times. I understand that every successive binary bit represents a doubling of values, but I've also heard you say that with 26 letters in the Alphabet, double that for upper and lowercase and add numeric digits. That would give 62 possible combinations out of a total of 64 total in a 6 bit word. I've heard you run the math which reveals 5.9375 bits of entropy just shy of 6 bits.

Steve Gibson [02:14:33]:
Considering that binary is either a 0 or a 1, how is it that the 0.9375 is not rounded up to 1? I'd think someone trying to brute force the number would have to try all 64 combinations. Wouldn't just letters of a single case plus numbers giving 36 possible combinations take the same amount of time to crack? Since all six bits would have to be tested, the brute forcing system wouldn't know to test just the first 36 out of the 64 values. Right? He said. Thank you and Leo for this podcast. Sitting in traffic is a lot less rage inducing since I started listening, and that's a good trade off for the cold sweats I get until my VPN reconnects every time I reboot my computers or sell Signed Allen okay, so to answer Alan's question, the answer is in fact the effective entropy really is that odd seeming 5.9375 just shy of six six bits 5.9375 bits of entropy because the lowercase plus uppercase plus 10 digits create, in this example, a total of 62 characters in this reduced Alphabet. And even though expressing any of those 62 characters in our reduced Alphabet does require six bits, there is no character represented by the 63rd and 64th binary bit patterns. Those final two binary bit patterns do not stand for anything. They do not represent any character of our reduced Alphabet, so they cannot be tested.

Steve Gibson [02:16:38]:
We must stop after testing this, the 60 second character, which is the at the end of our Alphabet, reset it back to zero increment the next most significant character to its next possibility, and keep trying. So Alan, another astute question from our on the road rapidly Catching up. Alan, what are you going to do when you get caught up and there's only one of these a week, you know. Oh my God. Lewis Blanchard said hello Steve, I continue to really enjoy the Security now podcast. I recently purchased a new Microtik Hexs 2025 Router Running Firmware Router OS 7.2.6, which offers excellent value. After updating the device and installing it in my home network, I ran the Shields up test to assess its default security posture. I was pleased to see that the All Service Ports check reported stealth for all open TCP IP ports.

Steve Gibson [02:17:45]:
However, Shields up was able to elicit a reply to an ICMP Echo request a ping. I confirmed this behavior after a factory reset, indicating it is the device's default configuration. I've since configured the firewall to drop inbound ICMP Echo requests, resolving the issue. My question is about the security implications of this default setting. Is shipping a router with default ICMP Echo replies enabled potentially negligent or dangerous for general customers who may have little networking knowledge? Given that Mikrotik, which I used to call Microtic, I'm glad I don't anymore, often uses the same default configuration across many hardware models? Would it be worthwhile to contact Mikrotik to suggest a change to the default firewall template to drop WAN side ICMP Echo requests while ensuring vital ICMP traffic such as destination unreachable remains active for performance? Best wishes to you and your family for the holidays. Thanks in advance, Louis okay, so that's a great question. It's one of those issues like the undeniable utility of NAT routing that causes the old gray beard Internet Internet Unix gurus to increase their blood pressure medication. The reason for this is is that it is it is absolutely clear that any IP device that's alive and working should, at the absolute bare minimum, reply to an ICMP Echo request with an ICMP Echo reply if an Internet protocol stack is present and connected.

Steve Gibson [02:19:49]:
The specifications are are very clear that this must be done. The argument could be made and believe me, the cranky old graybeard Internet Internet Unix gurus do that. Any device that deliberately fails to do so do this simplest of all things, is an aberrant abomination on the Internet, has no right to to send or receive a single IP packet and should be immediately disconnected with prejudice and burned at the stake. Yes, I completely understand what those people are saying and they're not wrong. ICMP echo requests and replies commonly referred to as pings are incredibly useful. They're perhaps one of the most useful features of of IP networking. By being so low level, by not relying upon anything else to function by by default always being present, it's possible to ping any device at any IP and to know that you'll receive a reply if that device is alive and if IP traffic has managed to get to and from the source of the ping and its destination. So in a very real sense, deliberately not replying to a ping request, just ignoring it, is a breach of one of the most fundamental laws of the Internet protocol.

Steve Gibson [02:21:28]:
The flip side is to ask who is pinging us and why would we want a tech who works for our ISP to be able to ping our router if they are working at diagnosing some network trouble? Yeah, of course we would. But would we want to reply to an ICMP echo request from some random hacker in North Korea, China or Russia? How just telling them that, hey, yeah, we're here, what do you have in mind? How does that possibly help us? The problem with those old gray beard Internet UNIX gurus is that they're living in their own ivory tower. They'll say, well of course you should have a good firewall, right? But what if that firewall contains a known bug that requires a bunch of pounding on its wall in order to penetrate? No one is going to bother pursuing a difficult to exploit firewall vulnerability against an IP that doesn't reply may not even be there, it's just dead air. But if that same IP bounces back with a Hiya, what's up? Response to anyone, anywhere in the world who might be knocking, does that make sense? You might just find yourself on the receiving end of an attempt to penetrate your defenses just because you said, yeah, I'm here. I'm not saying that any of that is likely to happen, but it's a valid scenario. I think the question to ask oneself is how it benefits you to have the device that's protecting your entire network announcing its presence to anyone, anywhere who attempts to bounce a ping off its public interface. If running with full stealth is an option, I don't see any reason not to use it. And if you are working with your ISPs tech, I'll bet they know by now to ask you to disable your router's stealth mode if they are trying to use ICMP Echo requests to troubleshoot your connection to their network.

Steve Gibson [02:23:55]:
So. Great question.

Leo Laporte [02:23:57]:
I learned that from Shields up back in the day.

Steve Gibson [02:24:01]:
Yeah. Actually I was a little curious about where the term stealth came from. It is the. It is the opinion of AI that I did originate that. I thought that was interesting. I mean, obviously the only thing originated. No, I got it from Star Trek. Of course.

Steve Gibson [02:24:20]:
You know the, the. Yeah, I know. I guess cloaking. Cloaking was the Klingons stealth fighter. So maybe, maybe stealth was mine. I don't know where I got. But anyway, in terms of. Of Internet presence, it was Shields up that first used it and then.

Steve Gibson [02:24:34]:
And that of course got picked up and widely used. So that was cool.

Leo Laporte [02:24:38]:
Yep. No knocks are heard here. Let's take a break. Then we go to Australia. We go down under with Steve and reaction to the social media ban which took effect last Wednesday. Wow, it's been almost a week. There's some very unhappy teenagers. Or are there? I don't know.

Leo Laporte [02:25:02]:
Let's find out. But first, a word from our sponsor.

Steve Gibson [02:25:05]:
It's been mixed. Yep.

Leo Laporte [02:25:06]:
Yeah, I bet it. Well, mixed. Yeah, that's. That's fair.

Steve Gibson [02:25:09]:
There are some relieved teenagers. I'll share their comments.

Leo Laporte [02:25:11]:
I'm sure there were. Yeah. Oh, thank God. I couldn't control it.

Steve Gibson [02:25:16]:
No, it's. Now I don't have to be on.

Leo Laporte [02:25:18]:
Right, right. Yeah, that might be the unbalanced. The best thing to do. I don't know. We'll find out. Stay tuned. First word from our sponsor, Bitwarden, the trusted leader in passwords. Yes.

Leo Laporte [02:25:32]:
Pass keys. Yes. And even secrets Management. Bitwarden is consistently ranked number one in user satisfaction by G2 and software reviews. You'll see, by the way, also picked as the number one password manager time and time again by independent reviewers. And I gotta point out, Steve Gibson and I are among the 10 million users across 180 countries and more than 50,000 businesses that use Bitwarden. As we approach the holiday season, this is one of you should know. This is one of the biggest, riskiest times for credential risks of the year.

Leo Laporte [02:26:11]:
Why? Because people are out there, they're shopping, they're using their credit cards. Maybe they're having a little too much fun. They're not paying as close attention to the phishing attacks. It's Cyber Security Awareness Month, by the way. They do an annual poll, the Cybersecurity Security Awareness Month poll. The Most recent poll revealed 42% of parents. This actually applies to what's going on in Australia right now. 42% of parents with kids age 3 to 5, little kids, young kids said their child has accidentally shared personal data online.

Leo Laporte [02:26:47]:
Don't ask how, I don't even want to know. Meanwhile, 80% of Gen Z parents feel their kids kids could fall victim to AI scams. But despite all that, 37% still give their kids full autonomy or only lightly monitor online usage. As cyber threats become increasingly personal, having a robust identity and access management solution is more critical than ever. And this is a great time to teach your kids that. Teach them how to protect themselves online, how to be security conscious. Whether you're protecting one account or thousands, Bitwarden keeps them secure all year long with constant updates. They're always adding new features.

Leo Laporte [02:27:29]:
They just added a great new feature that allows users to access their vaults and this is in chromium based browsers which is most of them using a pass key instead of having to remember a master password, which delivers a secure phishing resistant authentication method that protects against credential theft. Can even be tied into biometrics to make it even more secure. I actually whenever I log into Bitwarden, I do it with my fingerprint reader. I love that. Bit Warden's latest MCP Server if you're an AI fan, you'll like this release of the MCP server is now general and it does more than just vault operations. It enables AI agents to assist with organization level administrative using the Bit Warden Public API. It's really amazing what they do. According to IBM, the average cost of a data breach you don't even want to know tops $10.22 million per breach.

Leo Laporte [02:28:25]:
That includes ransom downtime reputation loss. With 88% of cyber attacks on basic web apps tied to compromised credentials, bad passwords and leaked passwords, it's easy to see why a password manager like Bitwarden remains a critical critical layer of every IT protection stack. Bitwarden it's a cost effective tool for any team, whether it's IT and operations, finance, engineering, HR marketing. Bitwarden will enhance your business's security and productivity. And introducing Bitwarden security in your business is the simplest way and probably the least expensive investment to safeguard, guard credentials and protect all your employees. So stay safe and secure online this holiday season. Bitwarden setup is easy. They support importing for most password management solutions, so it's easy to move.

Leo Laporte [02:29:16]:
I would bet though that most people who start with Bitwarden have never used a password manager before, which is one of the reasons Bitwarden is so easy to use that it encourages this. Plus the fact that it's free for life for unlimited passwords, Unlimited Pass Keys, yubikeys2 for our individual users, so doesn't cost them anything. Plus it's open source. I think that's super important. Bitwarden's open source code is regularly audited by third party experts. You can see it yourself. It's on GitHub. Bitwarden meets SOC2 Type 2 GDPR HIPAA CCPA compliance.

Leo Laporte [02:29:52]:
It's ISO 270012002 certified. Get started today with Bitwarden's free trial of a teams or enterprise plan. Or as I said, get started for free across all devices as an individual user. Bitwarden.com TWIT there's no better way to protect yourself this holiday season. Bitwarden.com TWIT we thank them so much for supporting security. Now we really appreciate all the help they give us all year long. They've been a great sponsor. Back again in 2026.

Leo Laporte [02:30:27]:
Now let's, let's find out what's going on in Australia. I'm dying to know.

Steve Gibson [02:30:31]:
Okay, so I expect to be giving this entire age verification issue a rest for a while. Hopefully the world's going to calm down now that Australia has done this. Although the EU is making noises, you know, at least until something more happens. Last thing I want to do is bore our listeners, but this is what's happening on the Internet right now. But before doing that, I wanted to wrap up today's podcast with a check in on the status of Australia's social media age restrictions. You know, sharing also some comments from two of our listeners and I think my clearest yet description of where we should and where we should not compromise. So what's going on in Australia? To say that the entire world is watching with interest would be no exaggeration at all. You would think that the world's news reporting agencies were starred for news with all of the coverage that this ban has been attracting.

Steve Gibson [02:31:36]:
Everybody's watching and everybody's reporting. Sadly, technology in general, I feel, is not showing too well. You know, technology's reputation is taking a bit of a beating because Australia's teens are being confronted with age detection based on facial feature characteristics which everyone knows to be readily spoofable. And no one is being disabused of that belief. Since last Wednesday, there are stories of girls applying more makeup to appear older and slipping right past the detector when before they didn't. Or a 13 year old boy who scrunched up his face when asked to verify his age. Presumably the scrunched up face looked old and wrinkled and pruny and that's. That's all it took, right? Other teens have simply had someone older look into the camera for them.

Steve Gibson [02:32:37]:
And on the flip side, 16, 17 and 18 year olds have been banned for being underage. So this is not technology's proudest time. I've seen stories of parents who for whatever reason believe in raising their children to be their best friends. They believe that overexposure to social media may not be healthy for their kids, but remaining their child's best friend means that someone else needs to tell them no. So these kids parents have been disappointed when their 12 year old was accepted as being 16 and allowed to continue social media. They were hoping it would end, but what can they do right? At the same time there have been stories of teens expressing relief at being denied and blocked due to their age. If they could be involved in the social media rat race, they needed to be, but they are not unhappy now to be off the hook, at least for a few years. Maybe the practice of facial age spoofing will just become another game now that kids play that shows how dumb the adults are.

Steve Gibson [02:33:55]:
At this moment it would be difficult to argue with that. My advice to the facial detection providers would be to invest the profits that they are currently enjoying today because my bet is those profits are going to be short lived. It's bad that facial age detection is such an inherently inexact practice. I completely understand that this is all we have right now, but it has been misapplied for this application. It should never have been used here since whether or not teens are old enough to have access to the social media which is often central to their lives. Independent of whether or not this might be healthy, it cannot be left to chance and to a capricious, error prone technology. My point is the go no go decision is too important and must be made fairly and based upon an individual's actual age, not more or less a coin toss. Some are saying that anything is better than nothing.

Steve Gibson [02:35:06]:
I'm not so sure that's true. Among the rest of the world that's watching this ever made nationwide experiment is the eu. They may be further along with an application that can verify someone's age without any privacy compromise. One thing is for sure, anyone who may have believed that facial feature age determination actually works well enough probably no longer thinks so. I hope that's true. I encountered A note from an Australian listener of ours that I thought provided some valuable perspective. Bruce French wrote, hi Steve and Leo. I'm a long time listener and club twit member here in.

Steve Gibson [02:35:52]:
How do you pronounce this? Adelaide. Adelaide.

Leo Laporte [02:35:54]:
Adelaide, yeah.

Steve Gibson [02:35:56]:
Adelaide, Australia. Yeah. I've been listening to Leo since he was in the cottage. And Leo, you and I have been talking since before the cottage. So you know, we've been doing the podcast since. Yeah, well, I guess, yeah, the cottage was where you were when we began. When, when, when, you know, twit began. Right, right.

Steve Gibson [02:36:15]:
He said, I've been listening to your discussion on the social media ban security now, episodes 40, 10, 54 and 55 just implemented here and thought it may be useful to put my point of view and limited experience forward. Firstly, this small part of the world has not stopped functioning. It just has not been a huge deal. There has been the usual commentary on the various media outlets. Some teens have been able to bypass the restrictions, some adults have been blocked when they should not have been. But these do not appear to be in large numbers. No mass commentary in either direction. Nobody within my extended family has been asked to verify their age.

Steve Gibson [02:37:01]:
Unless you are under 16 or near 16 years old, it's been a non event for the majority. When listening to episode 1054 I became a little defensive of Australia, I suppose as I thought your tone was a little condescending and mocking. I think I understand more where you're coming from after just having listened to episode 1055, privacy being the issue of concern. Well, and accuracy from me. So yeah, you know, know fairness and correctness, you know, for me a flaky age verifier seems like a really bad thing. Anyway, he continues, I would like to make the point that this social media ban is essentially driven by the people just implemented by the government. There have been a number of well documented cases here where teens have died of suicide as a result of social media abuse. With the media companies refusing to control or take down the relevant content, the public has essentially asked the government to do something.

Steve Gibson [02:38:11]:
There looks to be strong majority support throughout the country for this action. I have no data on hand to support this, but it is clear there has been very little pushback other than from the media companies. I note here that in general in Australia we are prepared to have some restrictions imposed if it is for the greater good. This looks to be one of those times. There even appears to be support, though begrudging from a good proportion of the teens affected. Of course, all this is from my very limited viewpoint. I do not have teenagers myself and my grandchildren are not yet old enough for this to have been an issue. Regards, Bruce French so thank you Bruce.

Steve Gibson [02:38:53]:
I thought that's valuable perspective and it's interesting that Bruce reports that adults are not being asked to verify their ages. There are presumably other heuristics that the services could be and I guess probably are using because they don't want to be doing this either. I encountered an interesting thought somewhere which noted that anyone having an existing account that's at least 10 years old could safely be assumed to be at least 16 years old today, since they would have had to create the account 10 years ago when they were younger than 6, which seems unlikely. I agree with Bruce from my casual survey of the reporting that, you know, the things he saw are what I saw too. I did get the general sense that only some younger teens are chafing. Many of their peers seem somewhat relieved that peer pressures are no longer forcing their reluctant participation, and the sense of relief among the adult and parent population appears to be nearly universal. So I want to share and react to at some length to what another of our listeners wrote Jane said, Greetings Steve. In the previous episode as well as in a number of previous ones, you expressed an opinion that a universal location independent age verification standard should be developed as it is the direction the web is going.

Steve Gibson [02:40:29]:
However, I find it unsettling when this is treated as an acceptable compromise. She said. The privacy preservation in at least some of the methods discussed, such as the one described in episode 1044 that was the true age system can be negated by subpoenas as admitted in that episode as well, thus leaving people still very vulnerable. This could also be a very convenient avenue to also denying certain adults, like journalists, access to various resources based on political reasons. One particular approach was mentioned as it was Apple or Google doing the verification maybe on device. Even if we assume no logs are sent out to their servers, this is a very damaging solution. Right now switching to a freedom respecting OS is more important than ever. With the increasing surveillance attacks on freedom and and just plain and shittification like the proposed limitations on unverified APK installation.

Steve Gibson [02:41:39]:
After having used graphene for one and a half years now, I don't think I can go back to having Google services at all, let alone with maximum privileges. Same for Linux on my desktop. In the newest episode it was phrased as we can do it without any loss of privacy, unquote. But the biggest loss of privacy in the proposed solution, in addition to surrendering your sensitive documents to Apple or Google is the loss of privacy on the device itself by having to have the invasive Google services privileged in the system. Same goes for Apple, except there aren't d appled OS versions in the first place. A whole other problem in itself is having to register with and agree to the terms of a third party completely unrelated to the service one was going to use. De Googled oss are already being disadvantaged. Banking and other important apps would often refuse to run on non stock oss, which is one of the biggest hurdles to adoption.

Steve Gibson [02:42:49]:
You can get around this with root and certain tools, but that's apparently becoming harder, doesn't always work and is a continuous fight. Not to mention that would mean still having the invasive Google services installed. Age confirmation is likely to be treated as strictly as identity documents or banking, thus effectively excluding people like me. There's an example of this already. The European Identity Wallet, which is mentioned in this podcast, has been found to employ play, meaning Play Store integrity. An issue was raised on GitHub. She provides a link, but at least the last I checked the developers dismissed it. I find it odd to treat widespread age verification as any less horrific than chat control.

Steve Gibson [02:43:43]:
This would cause just as much collateral damage, if not more far outweighing any potential benefits and it like. And it'd be unlikely to protect children. She hasn't quote protect the children. Anyway, thanks for the podcast. It's one of the reasons I switched my education direction towards security.

Leo Laporte [02:44:04]:
Nice. Nice. Yeah.

Steve Gibson [02:44:06]:
Okay, so first I want to make one point. Jane notes that the privacy preservation of the system we talked about in episode 1044 could be negated by subpoena. To be very clear, I would never consider any system whose privacy can be breached by a court order to be sufficiently privacy preserving. I mentioned that aspect of the True Age system specifically because it was a red flag and it was. There was no there was some comment of it being incorporated into into some of their technology being used by the World Wide Web Consortium the W3C. We know. We know how true privacy fanatics such as Apple and Signal would respond. They would have deliberately designed their technology so that they are technically unable to respond to any court order.

Steve Gibson [02:45:02]:
That's who they are. But the bigger point I want to make here reflects Jane's very understandable absolutist attitude, which she shares with many of our listeners. The Internet has been commercialized and its users are being monetized whether we like it or not. The commercial interests such as Apple and Google have grown into monopolies that no longer have any meaningful competition and we did that for them. And the various governments of the world are unhappy that the Internet fights against their desire to monitor and control what their own citizens and even other countries citizens are allowed to do. We've seen all of this in this podcast. Jane started out her note writing in the previous episode as well as in a number of previous ones. You expressed an opinion that that a universal location independent age verification standard should be developed as it is the direction the web is going.

Steve Gibson [02:46:07]:
However, I find it unsettling when this idea is treated as an acceptable compromise. I understand what she means, but in Australia today, young people are being forced to stare into a camera's lens so that their image can be transmitted to some third party service and used to judge their age. That's not privacy preserving by anyone's standard. The question is no longer whether or not Internet users are going to be able to continue to enjoy completely unfettered access to any resource anywhere they choose. They're not. That's over. That's what's known as a lost cause. Our various governments are taking those days away.

Steve Gibson [02:47:01]:
So it's not about having acceptable compromises. Whether we like it or not, with or without us, control is descending upon the Internet. Apple already knows all about me. I subscribe to Apple TV and news and have Apple pay set up in my iPhone. So I have no problem with the idea that Apple would allow my smartphone to assert my age or age range and absolutely nothing else to anyone who has a need to know after I've given my permission. I can't say that I trust Google to the same extent, but perhaps the Android platform will find a savior to offer universally accepted age assertion. What's possible from a pure technology standpoint, and this is where acceptable compromise comes in for me, but also where I see no reason to further compromise beyond that at all ever, is for individuals to affirmatively identify themselves just once to one trusted proxy, under the understanding that while that proxy must briefly know who they actually are in the physical world in order to verify their date of birth, that proxy will then discard all of that transient identifying information, retaining only their date of birth and the information required to identify them biometrically from then on. We can do that from that point forward at any time they can call upon that proxy to present to any inquiring third party an anonymous assertion of whatever age is required.

Steve Gibson [02:48:55]:
If we can get that, it will be a lot. It should be the industry's goal. I am seriously annoyed that Apple has not yet stepped up with the realization that it is in the best interests of their users for their idevices to be able to make those assertions on their behalf. Apple should be the one to do this. They are hurting the privacy of their users by continuing to refuse. None of the children who are staring into an iPhone in Australia should need to be screwed. Scrunching up their faces or applying makeup and having their phones sent, their photos sent to third party services. Not when Apple could entirely solve this problem without breaking a sweat.

Steve Gibson [02:49:46]:
The noises the EU is making along these lines all sound right and there's talk of some app that's presumably EU centric and cross platform so that both Apple and Android would be covered. That may be where the rest of the world is looking next. So you know, and I, and I heard you guys on Mac Break Weekly, Leo, you know, having a similar conversation, you know, chafing at the idea that we no longer get total absolute freedom and privacy. Well, we don't. Our governments have decided that's know we're not going to have that so.

Leo Laporte [02:50:28]:
Well, doesn't mean we have to accept it.

Steve Gibson [02:50:31]:
No, as I said, you can unplug. Absolutely.

Leo Laporte [02:50:35]:
Yeah. Or we can protest, change governments.

Steve Gibson [02:50:39]:
You. Yes, right.

Leo Laporte [02:50:40]:
Or I don't have to accept the fact that they've decided that that's not. That doesn't mean I have to, you know, accept that by any means. And I'm not going to unplug. We could have a private secure Internet. What about that? Why should the government be able allowed to do that? I don't think that they should be allowed to do that and I think it's a mistake to bent to roll over and say oh well I've done it. So that's the way it is. I disagree 100%.

Steve Gibson [02:51:08]:
Well, if it's going to happen, we can do it with minimal loss of privacy from a technology standpoint. The rest is politics. And I'm, you know.

Leo Laporte [02:51:17]:
Yeah, I mean, yeah, I agree that's a political decision. Yeah.

Steve Gibson [02:51:24]:
I mean no one should, no, no one should misunderstand me and think that I think this is a good idea.

Leo Laporte [02:51:30]:
Right.

Steve Gibson [02:51:30]:
I'm saying it is happening. But if it is, then, then we want to make the it. We want to make the best of it. We want the least invasion of our privacy possible. And it is absolutely possible for Apple with their biometric unlocking to, to be the entity that asserts our, our age. And now, now, agreed. There's a slippery slope aspect to this also. Right.

Steve Gibson [02:51:58]:
The more this becomes possible, the more likely it is to happen.

Leo Laporte [02:52:02]:
Right.

Steve Gibson [02:52:04]:
So you know, maybe while we have Fuzzy face detection. Some applications won't, you know, won't be able to use it because they're just not accurate enough and we're seeing how inaccurate it is in Australia.

Leo Laporte [02:52:17]:
I choose to resist.

Steve Gibson [02:52:20]:
That's more power to you, my friend.

Leo Laporte [02:52:22]:
And I'm not going to disconnect. I'm going to resist. Yeah, we'll see what happens. I may well lose Steve Gibson. This is the place to come if you want to learn what it all means means and how to do it and what's the ins and the outs. And I wish more, more policymakers would listen. Let's, let's get them to listen. Tell your policymaker friends, your Congress critters, this is the place to be on a Tuesday.

Leo Laporte [02:52:50]:
We do this show live Tuesday after.

Steve Gibson [02:52:55]:
Pardon me. Can you imagine anyone from Congress listening? They go, yeah, I can't imagine. Well, I'm a utopian Ron, Ron Wyden. I can imagine. Well, he would have a staffer who, who would be listening and then say, hey, you know, Ron, I guarantee you.

Leo Laporte [02:53:13]:
Members of Congress are listening to podcasts. I would submit this would be a better one for them to listen to than many of their other choices, if not all. That's just my thought. If you have an opinion. Well, there's many ways to get a hold of us. I'll tell you first of all, how you can watch the show every Tuesday right after Mac break weekly round 1:30pm Pacific, 4:30 Eastern, 21:30 UTC. We stream it live in the Club Twit Discord. I hope you're a member.

Leo Laporte [02:53:41]:
You can watch there if you are. If not, we also stream it on YouTube, Twitch, X.com, facebook, LinkedIn and kick after the Fact. On demand versions of the show are available at our site, TWiT TV SN. There's audio and video there or on YouTube. There's a video there of every show and you can use that to share CL clips. And of course you can subscribe in your favorite podcast client audio or video. Steve also has copies of the show. He has unique copies of the show.

Leo Laporte [02:54:09]:
A 16 kilobit audio version for the bandwidth impaired, a 64 kilobit for people with at least one ear. He also has the transcripts, which are very complete, many pages, usually a couple of dozen pages of notes, links, images. It's a very nice piece of work he does every week. You can get that by going to his site GRC.com and downloading it. You can also subscribe to his newsletter and he'll mail that out to you. Every week, a day or so before the show begins which is nice. You can read along as you listen or click the links and so forth. To do that go to grc.com email that's actually initially was created so that you could validate your email address so he can make sure you're not a spammer.

Leo Laporte [02:54:51]:
So you can send him stuff like, like pictures of the week, comments, suggestions like we just heard. But you can also when you're there submitting your email address, you'll note there are two newsletters you can subscribe to. One is very infrequent. Just announces new software like the DNS Benchmark Pro which just came out or the weekly show notes email. That's all there is. Privacy First GRC.com Email you'll also find Steve many of Steve's programs there. I used to say your bread and butter spin, right? That's for sure. But there's Also now the DNS Pro benchmark for a mere, what is it, 10 bucks lifetime.

Steve Gibson [02:55:28]:
995 Time Lifetime Subscription get its entire future.

Leo Laporte [02:55:33]:
Good way to support him is to buy his software I think GRC.com let's see what else. I guess that's all of it. We will be back here next week for a regular episode on Christmas Eve Eve. Then we're taking a week off and that's when you're going to get the Vitamin E D story. It's a, it's a Christmas story. We all enjoy the Vitamin D story. That'll be on this New year's Eve Eve December 30th. And then we'll be back with new shows again in January.

Steve Gibson [02:56:06]:
Wow. 2026.

Leo Laporte [02:56:08]:
Yikes. Yikes. Steve, we live in the future and it's just about as dystopian as we thought.

Steve Gibson [02:56:14]:
May your certificates keep getting shorter.

Leo Laporte [02:56:17]:
May they never expire. No, that's not quite right, is it?

Steve Gibson [02:56:21]:
Unfortunately.

Leo Laporte [02:56:22]:
Thank you, Steve. Have a great week. We'll see you all next time on Security Now.

Steve Gibson [02:56:26]:
Bye.

Leo Laporte [02:56:30]:
Security now.