| ||||||
Description: Gmail's spam filtering false-positive spree. iOS 26's Safari randomizes its fingerprint by default. Cisco's SNMP stands for "Security Not My Problem." Windows' "stuck" Extended Security Updates (ESU). Europe complains, gets one year of ESU with no strings. Where to get $6 TLS certs (really) while they last. The lessons to learn from Jaguar Land Rover's mess. The NEON app: Get paid to have your voice recorded. Bluesky's age verification, now coming to Ohio. What is "Kids Web Services" for age verification? More than 10K Ollama instances publicly exposed. GRC's DNS Benchmark reaches "release candidate."
High quality (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-1045.mp3 |
SHOW TEASE: It's time for Security Now!. Steve Gibson is here. He's got a whole mailbag to go through, lots of questions and suggestions. We'll talk about Cisco's broken SNMP implementation on some of its routers, two million people affected, and how to fix it. Some good news if you use Mac products. Safari has randomized its fingerprint, and Steve will explain what that means. Also, if you're in the EU, you get another year of security updates for Windows 10. We'll have the details on that and a whole lot more, plus Kids Web Services, a new way to do age verification. Actually, it's an old way that is now becoming very popular. And why you should secure your Ollama instance. All that coming up next on Security Now!.
| Leo Laporte: This is Security Now! with Steve Gibson, Episode 1045, recorded Tuesday, September 30th, 2025: News and Listener Views. It's time for Security Now!. Yes, if it's 1:00 o'clock on a Tuesday it must be time for Security Now!. The man, the myth, the legend, Steve Gibson is here. There's no myth about this man. |
| Steve Gibson: That's right, I'm a myth. |
| Leo: He's a legend. |
| Steve: The mythological Steve Gibson. |
| Leo: Every week Steve gives us the latest security news, explains how things work, and really gives us just a great list of fascinating stories to talk about. And this week I'm sure is no exception. What do we have today? |
| Steve: Well, we've got a bunch of news. Nothing really stood out as an "oh my god" sort of thing. So I just called Episode 1045 "News and Listener Views" because I got a lot of feedback. And oh my god, Leo, I mean, I know that everybody's probably been noticing that I'm stuck on this age verification deal. |
| Leo: Yeah. |
| Steve: But based on the feedback that I'm getting from our listeners, everybody is, too. I mean, the idea that everybody has to defrock in order to access some Internet content because you have to affirmatively prove that you've old enough, it's not just kids; right? I mean, it's everybody. That really gets people wound up. |
| Leo: Yes. |
| Steve: It's like, whoa, wait a minute. |
| Leo: Yes. Yeah. |
| Steve: And anyway, so then we have a little bit more on that. But lots of other news. I have some feedback from last week's interesting adventure of spamtopia with Gmail and what happened there. iOS 26's Safari says that it's randomizing its users' fingerprints. We're going to check in on that. There's some argument that Cisco's SNMP actually stands for Security's Not My Problem. |
| Leo: I love it. |
| Steve: Also, major happenings over on the Windows Extended Security Updates front, both in Europe and here domestically. Also I found out, I went looking for and found a $6 TLS certificate. |
| Leo: What? |
| Steve: Get them while they last because they're only going to be good for a few more years. But six bucks sure beats $326, which is what DigiCert wanted to charge me. I'll explain why all that happened. Also, yes, and I heard you talking about it before, Jaguar Land Rover's mess continuing. |
| Leo: Oh, what a story. |
| Steve: Whoa, yes. Also there's a bizarre new app that hit number two in social media over on the Apple Store, the Neon app, which really tells us that there's a whole different demographic of Apple iPhone user than the old folks that listen to this podcast largely. We're going to check in on that. Bluesky has announced that they're adding age verification now to Ohio, in addition to South Dakota and Wyoming. Also I figured out what they're doing it with, and it's not something that they created. It's a third party. So we're going to look at that also. We found - we. Censys found more than 10,000 - 10,000! - instances of Ollama publicly exposed. |
| Leo: Oh. Very easy to do that by accident, yeah. |
| Steve: Yes, exactly. And the DNS Benchmark I've been working on has reached Release Candidate level. So I have some news. |
| Leo: Oh, boy. |
| Steve: It's not available yet, but I'm, you know, we're down at, literally, are there any I's left that haven't been dotted. And I'm very pleased with that. So that, and then a bunch of feedback from our listeners because email is working again, and everybody's writing. So I got - I think that's probably a worthwhile podcast. |
| Leo: We used to do this every other week, the feedback episode, and I miss it. I'm really glad that we can do this from time to time. I think that we have a wonderful audience. |
| Steve: Yeah, I think it's important because, I mean, it really does, it inspires feedback. I'm able to better direct the podcast, knowing what our listeners get wound up about. |
| Leo: That's right, yeah. |
| Steve: I could either wind them up further, or unwind them, depending upon what it is. |
| Leo: Hmm. Let me think. All right. Well, we're going to get to that. We have a Picture of the Week. I have not looked. All I see is the tag "Guilty As Charged." So I don't know what that means, but we'll find out in just a moment with our Picture of the Week. Steve Gibson, Security Now!, is on and ready to go. I am ready to take a gander at the Picture of the Week. |
| Steve: So yes. As you noted, I gave this the caption, okay, "Guilty, as charged." |
| Leo: 2020. I'll make it a little wider here. "2020: Don't force me to install 10." Okay. |
| Steve: Yup. |
| Leo: "2025." It is true. |
| Steve: I know. It's true. |
| Leo: It's true. |
| Steve: So the upper frame of this little cartoon shows us the year 2020. It's got a big Windows 7 logo, and a little guy there on his knees, crying, "Don't force me to install Windows 10." And of course "guilty as charged" because everybody knows that I wrote an app called Never10, which was specifically designed to endorse this upper frame. And then the second frame of the little cartoon, a scant five years later, we've got the Windows 10 logo, and a guy's falling forward on his hands, tears pouring out, and it says, "Windows 10, don't leave me." |
| Leo: Oh, so true. So true. |
| Steve: So yes. Guilty as charged. |
| Leo: We are a fickle bunch. Yeah, yeah. |
| Steve: And, you know, okay. So in my defense, what upset me was the force, that being forced. |
| Leo: Yes, yes, yes. |
| Steve: It was my wife Lorrie at the time looking at the dialog that said "Upgrade now or tonight," rather than "no thank you." You know, the "no thank you" was there for a while, then they decided, well, this isn't working. Let's not give them a choice. And that's, you know, that was what upset me was that users' explicit wishes were being overwhelmed, overrun, ignored. |
| Leo: Right, right. |
| Steve: And so Never10 gave people control. And of course when they came out with 11, and people said "I don't want that," then instead of doing Never11, which didn't have the same rhyme to it, I thought, well, if they're going to do 11, they're going to break their promise. I'm sure we knew that 10 was the last Windows ever. But then, oh, no, no one ever said that. Okay. Well, then, instead of doing that, I just - I created InControl, which would use the officially documented corporate policy controls to prevent Windows from being changed. So of course that's called InControl. Anyway, I do feel, I felt both of those things. In 2020, it was I don't want 10. Now I don't want to leave 10. So, yeah. Guilty as charged. |
| Leo: That's just the way we are. People who have curly hair want straight hair. People who have straight hair want curly hair. It's just you can never win. You can never win. |
| Steve: Anyway, I got a kick out of that. Whoever put that together, it was a great observation, that it's like, first we didn't want it; now we don't want to not have it. |
| Leo: We just want control. That's what we really want. |
| Steve: I think that's exactly right. Exactly. We want to be able to say what happens with our machines. Once upon a time, remember, Leo, DOS had like four files, and we knew what every file on our hard drive or floppy drives were. |
| Leo: Yeah, remember autoexec.bat and config.sys? Remember that? And win.ini? Remember that? |
| Steve: And msdos.sys? And io.sys or something. |
| Leo: Oh, my. That's going way back, yeah. |
| Steve: And it's like, we knew what all that stuff was. And now I don't think there is any person alive, no one person, who could tell anybody what the files in their Windows machine are. It's just, you know, it's a sprawling civilization all its own. |
| Leo: It's an ant farm. |
| Steve: Anyway, so Donn, one of our listeners, Donn Edwards, started us off here by writing: "Dear Steve, last weekend I noticed that Gmail's spam filter rules had changed dramatically. I send a short, software generated, email message to a Gmail address every five minutes to test the operation of my mail server. It consists of two lines, with no HTML whatsoever." And he provided them: "eMailtimer sent on" and then a time stamp, date and time. And then "Automatic version 0.8.0.928." And he says: "The subject line is equally innocuous." And he provided that. And he said: "On Saturday 20th of September, Gmail suddenly decided to treat ALL these messages as spam. I eventually added a filter to Gmail to never send messages from this address to spam, since the 'Not Spam' button had no effect whatsoever." And he sent me a little screen clip and obscured the email address. And he said: "Perhaps you should advise Gmail users to do this for securitynow@grc.com just in case." He said: "Keep up the good work, and thank you for so many years of great content! Best wishes, Donn Edwards, Johannesburg, South Africa." |
| Leo: Another trick, a lot of newsletters say this, is add it to your contacts list because often if it's in your contacts list, people will say, the spam filter will say, oh, you know them. But, you know, I think part of this is what Gmail does now is it - and I know this because people who run, try to run their own email servers come up against this all the time. Gmail is constantly blackholing IP addresses if they're not, you know, if ever they send any spam, or even nowadays if they're just not a known emailer. So if you're running your own server, it's very unlikely you're going to be able to get through to Gmail. And then of course you have to have DMARC and, you know, all of the authentication, what is it, SPF, DMARC, and I can't remember the third one. |
| Steve: DKIM. |
| Leo: Has to be set up properly. |
| Steve: I have them all. And so what's significant here is that I've been mailing 19,000 pieces of email for a year every week with no trouble at all. And so... |
| Leo: Does it come from your server? |
| Steve: Yeah. |
| Leo: Or do you use it - yeah. |
| Steve: Directly from mine because I'm not - because, well, yeah, because I like to have control. So, and all of the people who last week said I've never had a problem getting your email. Suddenly it went to spam. So what clearly happening is that something changed. And it was also disheartening that Donn reported that using the "not spam" button caused a problem. Okay. So I was glad, bottom line, that my attention was brought back to this because I haven't needed to think about any of this since late last year when I set everything up and did the mailing to all of SpinRite's 150,000-plus past purchasers. I remembered that there was a Google Postmaster Tools for monitoring what Google thinks about email coming from GRC. |
| Leo: Oh, that's smart. |
| Steve: So I went back to pull up a chart of the last 120 days. And I've got it in the show notes. Now, this is very interesting. Okay. In the chart that you're showing above, every light vertical line corresponds to a Monday of the week. Now, remember that for more than the past four months I've been dumping around 18 to 19,000 pieces of email once per week, every week, every Monday. So what we notice, looking at this chart, is there is no correlation between the spam reports - so this is Google's user reported spam rate for email ostensibly coming from GRC. But there's no correlation between those Monday light vertical lines and this chart of spam. That is, for example, there were like one, two, three, four, five, there were like five weeks in a row where it's 0%. And then there are a couple reports later in the week. So the conclusion here is that email from GRC is being spoofed, meaning that there are people sending email pretending to be from GRC, pretending, you know, like with an @grc.com suffix as if it came from us. And in this instance here, GRC was suffering from the fact that we send so little email that even a small bit of spam by count equals a large percentage, which appears to be the only thing that Google and others are tracking. Now, the puzzle is that I've always had, since I began doing this more than a year ago, GRC - actually GRC's own server, because I've been running my own server from the beginning. So I put DKIM and SPF records in DNS years and years ago. So that's always been there. And GRC's DMARC... |
| Leo: These are authentication policies; right? |
| Steve: Yes. SPF stands for Sender Policy Framework. So an SPF record in DNS indicates which physical servers by IP address and domain name are valid originators of email from GRC. And so that record says grc.com and client.grc.com because my email server for architectural reasons emits email from a different IP address than grc.com or www.grc.com. And so that SPF record indicates who is a valid originator of GRC.com email. Nobody else that attempts to send email to some service like Microsoft or Google or whatever from another IP address will be generating valid mail from GRC. The DKIM is an actual cryptographic signature of a set of headers in GRC-originated email. So every email that GRC sends actually contains a signature which can be verified from the public key which is published through DNS. So what the DKIM record in DNS is, is the public key, which allows any recipient of email to use that public key which we publish through DNS to verify the signature that envelopes that set of headers to verify they've not been changed. So what that does is very strongly prevent anybody from spoofing those headers. Nobody else will have the private key that GRC's server has. So there's no way for them to produce a signature which qualifies for any headers which differ. So this is strong protection. So the puzzle that I had was, with all this in place, how can Google be saying that it's getting any spam from me? It ought to be checking these things and ruling them out as just spoof, as crap, and just dropping them. Doing some further research, I believe that I was not using the strictest of all possible enforcement policies. Turns out that there were two other arguments which could be part of my DMARC. So I said SPF is Sender Policy Framework, which tells anyone who asks which servers can, which physical servers by IP and domain can originate mail. DKIM is published as the public key which is used to verify the signatures of the headers. DMARC is the policy statement. It's the thing that specifies what to do if the DKIM and/or the SPF don't match up. And so DMARC is the enforcement, specifies the enforcement policy. The reason you have to have that is that it's very easy to get this stuff wrong. I mean, this is - there are, like, there are many companies out on the Internet that their entire business model is telling people how to do this, like setting this up and handling it for them and that white glove service that you pay hundreds of dollars for that, you know, it's like, okay. But, you know, I've been here forever, so I can figure this out. Anyway, the point is you may need, while you're getting this thing all working, you may need to tell people I want to publish this stuff, but if you're not happy with what it says, don't reject the mail, just report that to me. So the other thing that DMARC has is you're able to provide reporting email addresses where the results of these tests are sent back to you so you can work on getting it all right before you tell people, okay, it's all working, we now want you to just reject any email that isn't verifiably from our email server or servers. Anyway, there was - they called it "alignment." And unless you specifically say that you want to reject unaligned DKIM and/or SPF, then they call it - you have a "relaxed policy." I wasn't specifying strict alignment. And so it turns out now - so a lot has happened in this past week, as you may be able to tell. I turned on monitoring. I've been collecting reports every day. I've been looking at what's going on. It turns out that there were people spoofing GRC because I did not have the strictest alignment. Alignment says that the "mail from" domain must be the same as the domain that is specified when you connect to GRC's server. So those headers must be aligned with the domain specified by the server. Turns out they weren't being. And so all this work I had, it was there, but it wasn't rigorously forcing rejection of anything. So what happened yesterday is that 19-plus thousand, or no, I'm sorry, almost 19,000 pieces of email went out. Gmail didn't bounce anything. So I don't think that's because of any of this. I think, given that I and other listeners said suddenly Gmail was routing things to spam that it never had before, I think Google screwed something up. I think someone tripped over a cord somewhere in Gmail Central, and for a brief period of time, which just happened to be last weekend when our listener Donn mentioned that this was happening to him, a bunch of other listeners said they saw the same thing, and of course I did my mailing on Monday, and they all went into the spam bucket, where they never had before. Google fixed that. But I'm getting ready to announce the DNS Benchmark, so I don't want Google to get upset with me when I start sending out, you know, 150,000 pieces of email. And so I'm - now we'll see. This chart that they have has about a three-day lag to it. And it's only a couple days ago that I made these changes in DNS and got everything locked down tight. The reports I'm now receiving from all the different recipients of email from GRC indicate that there was misalignment, and the fact that I'm now saying I want to strictly enforce alignment, they're now dropping email that they would have allowed to their users. So GRC should have zero false positive spam events now. And I just wanted to share this with any of our listeners. I know that a bunch of our listeners are running their own email servers. You just want to make sure that - and by all means, my DNS is public. So you can go to, like, MX Toolbox, and they've got a DMARC button there. Put GRC.com in, it'll dump out, it'll show you the exactly DNS records that we're now publishing. And it is really locked down tighter than a whatever. Tightly. Anyway, so I think I've got it figured out. And I think what happened last week was an anomaly on Google's end, but I'm really glad for this runaround because it did cause me to wonder why is Google thinking I'm sending any spam? And it's clearly not false positives from GRC's mailings because there's like a run of five weeks in a row where there's 0% report. And it's when I'm not sending anything that a few come in, you know, one or two. And unfortunately that's a large percentage because I'm not sending anything. So I think the mystery is solved. And it'll be interesting to see when I'm ready in a few weeks probably to tell the world about the DNS Benchmark to do another big mailing. We'll see how that goes. But again, 19,000 email every week goes out with zero trouble. So I think that's been solved. |
| Leo: I think that by itself might be an indicator, you know, to Google. They might say, wow, that's a lot of traffic we're seeing from the same IP address. Maybe it's - do they still have the black hole? Remember they used to have these black hole lists like maps and orbs? |
| Steve: Yup. |
| Leo: Are those still around? Because that was problematic. If you'd get on that list, man, you'd never be able to send email again. I mean, it was just problematic. |
| Steve: Correct. Yeah. And it was very difficult to get yourself off of it. |
| Leo: Right. |
| Steve: And so those things predate this really strong authentication. |
| Leo: I think SPF, DMARC, and DKIM are really good. Right? |
| Steve: Yes. Once you have those. And again, I can understand how many people don't want to deal with this. So they just want to run their mail out through Mailchimp or AWS, you know, Amazon has a, what is it, SES service where they do all that for you. I tried that. Oh, and Postmark is the service that I used when I was initially doing like the first mailing I had done ever. You know, I don't remember now how many hundreds of thousands of email addresses I had collected. But I get it. I mean, you have to really want to do this and understand what IP your email will emerge from your network on, and have reverse DNS set up for that. It takes a lot to get it done. But, you know, I enjoy that. So this has been an interesting hunt for me. And I just like, you know, now I'm going to watch that graph in a week and see whether in fact I have nipped all of these other spammers who are spoofing GRC in the bud because, I mean, that's what you want. You don't want anybody sending email on your behalf, certainly not using GRC's reputation and, you know, for phishing emails or to send malware to people. You absolutely don't want that. So I think probably I closed the last little loophole there, and we'll know in a couple weeks. Mac Observer's headline was: "Apple is Turning on a Powerful Safari Anti-Tracking Tool for Everyone." And the coverage opened with the sentence: "Apple is widening Safari's privacy shield. Starting with iOS 26 and macOS Tahoe 26, advanced fingerprinting protection is enabled by default in every tab, not just in Private Browsing." Now, okay. We know that Mozilla also just claimed to have improved their fingerprint protection, which caused me to check my updated Firefox against the EFF's excellent "Cover Your Tracks" website which, sadly, informed me that my Firefox browser still had a unique fingerprint. Even though Mozilla said they'd improved it. Well, apparently not improved enough. So upon seeing this iOS 26 claim, and of course having recently been disappointed by Mozilla, I headed right back over to coveryourtracks.eff.org with my iOS 26 updated phone. And remember that I had purchased that phone, well, I purchased an iPhone 16 earlier this year during that initial panic over Chinese tariffs that might be hitting us. I did not update that to iOS 26 because I didn't want all that Liquid Glass nonsense, and I won't until Apple allows us to turn that off because I don't need it. But my iPhone 12 could be updated to iOS 26, yet it's too old to run the Liquid Glass UI. So, and I have to say, Leo, I like the features. It's got a little more - it has sort of a fit and finish polish that, you know, after all these years you'd think they would have done everything they could. But just little subtle details of, like, lines around things and stuff that are nice. |
| Leo: Yeah, yeah. |
| Steve: Anyway, so using iOS 26, going over to coveryourtracks.eff.org, and it's 100% success. Blocking tracking ads, yes. Blocking invisible trackers, yes. And protecting you from fingerprinting. And it says, "Your browser has a randomized fingerprint." Significantly, I changed nothing about my default browser settings. And CoverYourTracks reports that I am now strongly - I have strong protection against web tracking. So we know the importance, actually the critical importance of defaults. Defaults are what matter. And so what Apple has done is for everybody, by default, they now have strong tracking protection enabled in iOS 26. They said: "Fingerprinting uses subtle device and browser traits to identify you across sites. Safari now standardizes and 'noises' more of those signals by default, making it harder for trackers to single you out while you browse normally." That is, I should mention, it used to be available under private browsing mode only, not normal. And that's the other big change. They not only made it better, but they made it universal. They wrote: "Safari reduces access to high-entropy web APIs commonly abused for fingerprinting and limits script-written storage and navigational state reads. Practically, that translates into fewer stable identifiers for tracking scripts and less durable 'stickiness' across sessions. This doesn't change how Link Tracking Protection works in Mail, Messages, and Private Browsing. It also doesn't remove normal cookies from sites you sign into. If something breaks on a niche site, you can temporarily relax protections and try again." So if you go to Settings > Safari > Advanced - you have to scroll all the way down to the bottom of the Safari settings page. The very last thing there is Advanced. Then under that is Advanced Tracking & Fingerprinting Protection. What you want to do is confirm that it's set to "All Browsing." It could be set to "Off" or to "Private Browsing." Should be on "All." And on a Mac, it's under Safari > Settings > Advanced, and it's "Use advanced tracking and fingerprinting protection" you want to set to "In all browsing." So my iPhone 16, the most recent iPhone, it's still running the last iOS before this jump to 26, which was 18.6.2. So I decided to see how it compared, that is, what was the last iOS before they fixed this and jumped to 26 doing. I had also never messed with Safari's settings there, so its "Advanced Tracking & Fingerprinting" was still set to "Private Browsing," which had been the default for Apple until then. I changed it to "All browsing" and then went back over on the iPhone 16 still running iOS 18. I went back over to the "CoverYourTracks" site. I'm getting blocking of tracking ads and invisible trackers, but I'm told that Safari under that last iOS before the move to 26 is presenting a non-unique fingerprint to the world. Now, I have to say it's way better than Firefox's. Cover Your Tracks says that my latest Firefox browser is unique among every one of the 301,784 other browsers that have visited that site during the past 45 days. Not good. So it's no problem, you know, nobody would have any problem following me around the Internet using fingerprinting. However, it adds that this means it's providing at least 18.2 bits of entropy. By comparison, among those same 301,784 other browsers that Cover Your Tracks encountered during the past 45 days, iOS 18's, that is, the pre-26, iOS 18 Safari shared a fingerprint with fewer than one out of every 2,340 browsers. So everyone using any version of Safari on iOS or Mac before this latest 26, iOS 26, would also be well served to change their browser's anti-tracking and blocking to "All Browsing." You know, why not? It's not perfect protection, which is what 26 is offering. But still, rather than a unique fingerprint, which is what Firefox is still giving me, among 301,784, now iOS at least gives me a unique fingerprint among one out of every 2,340. So I'm sharing with a large population of other Safari users as opposed to being unique on the Internet. So an improvement. And Leo, I've talked a long time. We're already a half-hour in. |
| Leo: Which is also an improvement. |
| Steve: We're going to look at how Cisco's SNMP actually stands for "Security? Not My Problem." |
| Leo: Not my problem. I love that. |
| Steve: Okay. So I was reminded of the old joke that "SNMP" stood for "Security's Not My Problem." |
| Leo: It's normally Simple Network Management Platform or Protocol, something like that. |
| Steve: Protocol. |
| Leo: Protocol. |
| Steve: Yup, exactly. It's a joke, well, because of course. |
| Leo: Maybe it's not a joke. Yeah. |
| Steve: And it's kind of not SNMP's fault, but kind of is. Anytime the name of a widely used, ancient Internet protocol begins with the word "Simple," you can bet that the "S" would never be confused with standing for "Security." And that is nowhere more true than SNMP. The original RFCs which specify the operation of SNMP date from 1988; and, believe it or not, it was never intended to be used in the long term. |
| Leo: Wow. |
| Steve: It was originally created - that's right, that's how these things happen; right? - as a quick hack stopgap solution because the work that some other groups were doing was believed at the time to be far too burdensome and unimplementable, you know, they were just, like, creating a massively complex system for doing what SNMP does. That's actually why they called it Simple Network Management Protocol. They were saying, no no no no no, we don't need all that complexity. We just want something simple. So SNMP was throw together quickly without any essential effective security, like now; okay? What do I mean by that? Like DNS, which was designed to be also at around the same timeframe to be lightweight and low overhead, SNMP uses UDP packets. And also like DNS over UDP, SNMP has no encryption or eavesdropping on the machines of the time. So SNMP was thrown together quickly without any real security. Like DNS which was designed to be lightweight and low-overhead, SNMP uses UDP packets and also like DNS over UDP, SNMP has no encryption or eavesdropping protection whatsoever. And what security there is takes the form of a simple cleartext password whose textual string must match the one stored in the SNMP-equipped device, and SNMP server which is being queried. It's true that later SNMP v3 did add privacy and encryption and better authentication finally. But it was a long time coming. And it's often the case that no one bothers to set it up because they just go, well, SNMP, it's simple; right? Supposed to be. Right. The trouble is SNMP is also incredibly useful. And even though it was designed in 1988 as a throwaway temporary ad hoc just until something better comes along, nothing better ever did. So it's still what everyone uses. I've talked about that cute little, SoftPerfect is the publisher, NetWorx, N-E-T-W-O-R-X is the application name, that little network monitor, it's able to watch the SNMP counters on my network LAN interface to show the entire network's bandwidth use. Network interfaces count all the bytes coming and going in 64-bit counters, and SNMP can be used to query the state of that counter, the value in that counter at any time. So simply by polling it periodically, you're able to get the current count. And by looking at the difference between two counts and the time difference between polling intervals, you're able to determine what the bandwidth is across the interface during that period of time. So, you know, it is, yes, it's simple. But it's also incredibly useful. That little client which is running on my Windows machine is sending UDP packets to port 161 of the LAN interface, and the router's little SNMP server is examining those packets, seeing that I'm requesting the interface's received and sent byte counts, which it then sends back to the client in a returning UDP packet. So no privacy, no security. It's meant to be used internally, not meant to be publicly exposed. So you can imagine where we're headed with this story and Cisco. SNMP presents a treelike structure which can be explored by any patient client to discover all of any network's devices and their settings. This includes things like all of its interfaces, all of its routing, and ARP tables, the IP addresses, and the network masks of its interfaces. The way this was designed, network engineers wanted network access to the settings of all of their devices. SNMP provides that. And it's obviously - that information is nothing you would ever want anyone to have access to. So turns out it's even worse. It's not just about querying devices. It also supports setting and changing a device's settings, all remotely and all over the network. And remember, by default, it uses insecure plaintext UDP. So it has always been a security disaster just waiting to happen. Here's, in fact, what Wikipedia has to say in a couple paragraphs under their heading of "SNMP Security," which we already understand is an oxymoron. They wrote: "Because SNMP is designed to allow administrators to monitor and configure network devices remotely, it can also be used to penetrate a network. A significant number of software tools can scan the entire network using SNMP; therefore, mistakes in the configuration of the read-write mode can make a network susceptible to attack. "In 2001, Cisco released information that indicated that, even in read-only mode, the SNMP implementation of Cisco IOS is vulnerable to certain denial of service attacks. These security issues can be fixed through an IOS upgrade." And remember here iOS was the original Cisco term for Internet Operating System. Got nothing to do with Apple. Wikipedia finishes this little segment, saying: "If SNMP is not used in a network, it should be disabled in network devices. When configuring SNMP read-only mode, close attention should be paid to the configuration of the access control and from which IP addresses SNMP messages are accepted. If the SNMP servers are identified by their IP addresses, SNMP is only allowed to respond to these IPs, and SNMP messages from other IP addresses should be denied." In other words, again, IP-based access control. It is the strongest protection that exists. And it just doesn't get enough attention. And they finish, saying: "However, IP address spoofing remains a security concern." Right, because UDP you don't need roundtrip packets that TCP requires in order to authenticate the IPs of the endpoints. So UDP, as we know, is completely spoofable from its source IP. Okay. So in other words, SNMP is and has always been a security disaster. If SNMP is not actively needed and in use, its service should never be running. And the IP addresses of anything using SNMP should be filtered so that only authorized clients can obtain access to a device's services. Unfortunately, as Wikipedia points out, being carried by UDP allows spoofing, and so source IPs can remain a problem, although you're not going to get any information back forensically if you spoof the source IP. It's going to go back to where the server believes the UDP packet came from. So all of that foregoing would mean that no network engineer would ever consider placing any system that published SNMP onto any public network. And this, of course, brings us to Ars Technica's headline last Thursday: "As many as two million Cisco devices affected by actively exploited zero-day," and their sub-head: "Search shows two million vulnerable Cisco SNMP interfaces exposed to the Internet." Unbelievable. What year is this? This is not 1988. This is 2025. The actual number, revealed by a Shodan search for the string "CiscoSystem," which is what it responds with on port 161, is 2,303,370. At one point in their reporting Ars tells us: "The vulnerability is the result of a stack overflow bug in the IOS component that handles SNMP (simple network management protocol), which routers and other devices use to collect and handle information about devices inside a network. The vulnerability is exploited by sending crafted SNMP packets." Note the phrase in Ars Technica's reporting, "inside a network." SNMP has no business being enabled on the public-facing interface of any network equipment. And if you absolutely have to have it, then you absolutely have to filter it so that only known queriers are able to do so. Despite that fact, 2,303,370 individual Cisco devices respond to a Shodan query of their port 161 with the string "CiscoSystems." I would be very surprised to learn that more than 2.3 million individual network engineers could or would have deliberately enabled the SNMP service - which they almost certainly have no need for anywhere - on their Cisco device's Internet-connected interface. And they probably didn't. Unfortunately, this is readily explainable as yet another example of what can only be incredible hubris today, in this day and age, on Cisco's part. I'm sure that, when asked, they would reply as they have before that their equipment assumes its use by qualified and trained network engineers, and that the guidelines enumerated in their optional, of course, "How to harden the security of your new Cisco device" guide should always be followed - even though, of course, it's not required, and there's no requirement to do so. The reason Cisco's IOS has such a legacy of trouble is that its design philosophy was born back in 1984 with the company's founding by a pair of Stanford University computer scientists. Little thought was given to "security" back at the dawn of the Internet, as we've often noted. And the design of Cisco's IOS - as I said, Internet Operating System - reflects that that lack of security in its implicit assumption that IOS would only be in the hands of and configured by and used by professional network engineers. For example, even today, any internal services, such as SNMP or HTTP, that run in the device are, by default, available to all of the device's interfaces. Again, believe it or not, any service that is turned on inside a Cisco device by default is available to all the interfaces. A Cisco IOS device has no intrinsic notion of LANs and WANs. Those are all just interfaces equal and viewed by Cisco as network ports. The earlier devices, before the early 2000s, actually had all of their various services running by default, they were on and available on all of the device's interfaces until and unless the service was explicitly shutdown with a configuration command such as "no ip http server." Remember that GRC, back in the earlier days of the podcast, Leo, while you and I were doing the podcast, I originally used a Cisco device. I had a pair of 1.54Gb T1 trunk lines running to my home. |
| Leo: And we thought that was pretty fancy. |
| Steve: It was like, whoa. 3.8Gb, yeah. |
| Leo: Megabits. No, it was megabits; right? It wasn't gigabits. |
| Steve: Yeah, oh, my god. Oh, you're right, it was megabits. Was it megabits? |
| Leo: It was megabits. |
| Steve: You're right, it was. I said "gigabit" because I couldn't believe it was megabit. |
| Leo: Megabits. |
| Steve: That's - I've got really something stuck, tickling. |
| Leo: Well, I think it's the gigabits that are stuck in your throat. And I don't blame you. Those things really don't go down easy. |
| Steve: Oh. Thank you. Anyway, I remember explicitly configuring my Cisco router, placing a "no ip http server" line into the router's configuration file in order to prevent that unwanted service from running and being present on all of the device's interfaces. Now, thanks to Cisco's long legacy of apparently assuming that only highly trained network engineers would be configuring their devices, today, in 2025, more than 2.3 million of Cisco's IOS-powered routers are exposing their SNMP services to the public Internet for anyone who wants to poke at and query. And unfortunately, the world has learned that until they're patched - and, you know, what chance is there of that ever happening today, 2.3 million routers? I mean, it's the classic example of something being in a backroom closet somewhere and long forgotten. A stack overflow that's present inside all of those routers' SNMP packet processing is exposing those devices to what is now an actively exploited zero-day attack. Patches are available from Cisco. Doesn't matter. It's unbelievable. So the takeaway for our listeners is to be very certain that if any of our listeners are responsible for a network containing any publicly-facing Cisco IOS-based routers, be absolutely sure, first of all, that you're running the latest version of IOS, and then be absolutely certain that, if that router has SNMP, you must explicitly block its access to any ports connected to the Internet. What happens is Cisco did update their IOS so that these services are no longer running by default. Instead of having to turn them off if you don't want them, you do need to turn them on if you do. But if you do turn them on, they by default bind to all the interfaces of the router. So you then need to go through and create access control lists, ACLs, which explicitly deny access to that service from that port across all of them. I mean, there is a high bar for securing a Cisco IOS device, and it's clear that 2.3 million people, they probably turned SNMP on because they wanted access to it from inside their LAN, never appreciating that by default it's also leaking out onto the public Internet unless they do something about it. I mean, it's, again, this is not the way secure networking equipment should ever be designed today. But it's going to take, what, probably another decade before Cisco says, huh, you know, maybe we should block these services unless they explicitly allow them on the ports. What a concept. Unbelievable. |
| Leo: Shocking. |
| Steve: Speaking of vulnerabilities, okay. Everything changed in the last week, as far as I can tell. But I want to bring people along to, like, where we were and what's been happening because they may not have changed for everyone yet. There's a great deal of uncertainty currently surrounding Microsoft's plans, as we know, for Windows 10 and the availability of the next year's worth of security updates courtesy of their ESU, their Extended Security Updates program. The world is asking that Microsoft give it more time to migrate from Windows 10 to 11. It would be ideal if Microsoft were to allow Windows 10 machines to be upgraded to Windows 11. That would beautifully solve their OS version fragmentation problem. I'm sure they could cook up some story about having made a breakthrough in Windows 11 that now allows it to miraculously run on all that older hardware that's currently running Windows 10 and was believed to be stuck there. But oh no, now you can run Windows 11 on it. That would be great. But if that cannot or will not happen, I thought that Stacey made a very strong point in her open letter to Microsoft which we shared last week. She noted that someone might have purchased a brand new PC containing Windows 10 as recently as 2022 whose hardware Microsoft has deemed unworthy of running Windows 11. So now they have a PC that's only three years old that's about to lose access to its constant IV drip drip drip of security updates, many of which are critical, and all of which are of Microsoft's own making. As Stacey wrote so eloquently, it doesn't seem right, and it also breaks with the expectation Microsoft has previously set of a 10-year life for systems running Windows. I bring this up again as we approach the middle of next month - October 15th; right? - because it appears to be possible for existing Windows 10 non-enterprise edition end users, that is, people who should quality for this, to push their machines over, like into the enrollment for the next year of free ESU service. I had a Windows 10 instance last week that was current with all of its updates, and it was logged into my Microsoft account, but it had not yet received Microsoft's offer to enroll in the forthcoming year of Extended Security Updates. It wasn't clear what it was waiting for, or when that might happen, if it would. We've heard that the ESU enrollment invitation is being handled as a gradual rollout, so I thought, well, okay, maybe it's just waiting for that. I have to be more patient. But some Windows explorers have come up with a sequence of steps that appear to hurry the process along. So a week ago I wanted to experiment with that. The short version is it worked. That machine, which was not offering me enrollment in the ESU program, did, after I did a little bit of fiddling. So if you're still running Windows 10, this may have changed for you since last week. But you could still wait to see what happens automatically. Maybe it already has. There were instructions posted to a forum thread at the AskWoody website. The thread is titled "How to extend Windows 10 Support now published by Ghacks," and that thread was very active. Many people jumped on this. The thread refers to the well-known Ghacks.net site, where back on July 24th Martin Brinkmann, who's the guy there, posted a series of ESU enrollment screen shots. Now, the only trouble is, many people were not receiving the offer in the first place. Well down the thread at AskWoody_MVP with the handle of "abbodi86" posted some step-by-step instructions under the title "Here is a way to force-enable Consumer ESU Feature." I did those things, and it worked. It successfully induced a Windows 10 machine where I was not invited to enroll in ESU to invite me. I have a link to that posting which in the AskWoody forum, but there's more. This same "abbodi" individual has created a very nice and comprehensive set of resources at GitHub which includes powershell scripts, ample background material, and also the same manual steps down toward the bottom which I originally used. I've got the link in the show notes, and I also made it this week's shortcut of the week. So you can find that GitHub page at grc.sc/1045. That will transport you over to his GitHub page. And armed with the information there, you should be able to get any qualifying consumer Windows 10 machine enrolled and ready to continue receiving the next year of updates without interruption. Now, since then, just this morning, I tried two other machines. The one that I'm using to talk to us on, which is a Windows 10 machine that had never been offered enrollment before, when I turned it on this morning, it was. And a different Windows machine, a Windows 10 machine, gave me the similar experience, different from what I had last week. Now, without me doing anything, it's offering me enrollment. So it may be that I was just jumping the gun here last week, as were thousands of other people who were impatient, and that Microsoft has now, you know, inscrutably as they are, finally gotten around to doing this. So maybe this is all a non-issue. For what it's worth, if you have a Windows 10 machine, and it's Home, Pro, Education and Pro Education, you know, the non-enterprise editions, this will cause it to give you the enrollment. But it looks like Microsoft is going to get around to doing it for everyone anyway. It is worth noting, and I was conscious of this because I'm using my single Microsoft login, and I think I've now enrolled three different Windows 10 machines. There is a limit of 10 enrollments per Microsoft account. So since I've got Windows everywhere, I've got to be a little conscious of that. I'm not sure what my MSDN developer credential gets me. I guess I'm going to find out. But I'm going to make sure that the main Windows machines that I am using are able to upgrade. As I said, it wouldn't be the end of my world if I was no longer getting the free updates. It's like, okay. But if I can, I might as well. So anyway, now everybody knows everything I know about ESU. And it looks to me like no one will have to do anything. But if you're not being offered it, there is a way which is now proven, and it's worked for many people, to get that ESU to kind of give Windows a little kick in the butt to get it to make you the offer. One last bit of news before we leave this. The news out of what's known as the European Economic Area, the EEA, which includes everybody in the EU member states plus Iceland, Liechtenstein, and Norway, is that for them, Windows 10 machines for everybody there will continue receiving Windows updates, presumably under the extended service updates program, but not necessarily, it could just keep going, unless Microsoft might think better of all this and just give everybody updates. Who knows? But the point is, without them having to do anything whatsoever. No PC backup, no Bing Brownie points, no PC settings synchronization, none of those little things that Microsoft was telling us for a while. They don't have to do anything. |
| Leo: Oh, good. |
| Steve: It turns out that, for them, Windows 10 updates will be truly and completely free with no strings attached due to pressure from an organization called Euroconsumers, which is a major EEA, that's again European Economic Area, consumer protection NGO, which questioned the legality of Microsoft's offerings compared to the EU's new Digital Markets Act (DMA). And the best news is that the organization is not finished pushing Microsoft. They're now demanding that Microsoft provide additional years of ESUs to home users, you know, consumers beyond next year and the now-expected October 13, 2026 cutoff. So the DMA is doing all kinds of things for our organizations. I heard you talking during MacBreak about it and Apple with the DMA. |
| Leo: Apple really resents being told what to do, yeah, yeah. |
| Steve: Yeah. |
| Leo: As I'm sure Microsoft does now, frankly. |
| Steve: Well, and this is the overarching issue of our time, Leo, is governments are telling technology... |
| Leo: Right. |
| Steve: ...what to do with their legislation, whether it's age restrictions or decrypting messaging or, you know, whether or not we're able to cause, you know, make people jump through hoops to get extended security updates. It's, you know, there's a real clash here of wills. |
| Leo: Yeah, yeah. |
| Steve: Okay. After our next break, I'm going to tell people about the $6 TLS certificates that I found. I bought one. I'm using it. |
| Leo: But do they expire in three months? |
| Steve: No. You still get 398 days. |
| Leo: Oh, good, all right. |
| Steve: So you get 13 months, until March 15th. |
| Leo: All right. |
| Steve: Okay. So I wanted to share another recent discovery of mine: $6 TLS certificates issued with the current maximum allowed 13-month lifetime. Everyone knows about the revoked.grc.com website I created many years ago to demonstrate that the web browsers of that era were completely ineffective in their checks for certificate revocation. You know, what really spurred me was that Google was saying, oh, our Chrome browser, we've got that all - it's like, no, you don't. You're lying to the industry. So to demonstrate that fact, the revoked.grc.com server there is deliberately serving a revoked certificate. I mean, the certificate's no good. Yet browsers don't care. At the time they didn't. They've gotten much better now, and it looks like Bloom filters are now working. The trouble was, last year's deliberately revoked certificate was expiring, and it needed to be replaced. And since that simple facility has become pretty popular, it receives about 500 visitors a day, it made sense to me to keep it alive. It turns out it's possible to automate both the issuance and the revocation of certificates using the ACME automation protocol. So at some point in the future I imagine I'll cook up some way of always using a freshly ACME-revoked certificate for the revoked.grc.com site once I've been forced to move all of GRC's other TLS certificates over to Let's Encrypt, you know, we talked about this before, due to the industry's inexorable and I think unnecessary march toward shorter certificate lifetimes. But I'm not ready to do that today. Today I want to get the new and much improved DNS Benchmark wrapped up. So I just wanted to do what I've been doing, which is to purchase and immediately revoke a single certificate for that site. For many years, DigiCert has been my certificate supplier. So I went there first. They no longer offer the least expensive and least verified simple DV, you know, Domain Validation certificates. That's what Let's Encrypt produces. I suppose they wisely decided not to attempt to compete with Let's Encrypt's free ACME automation certs. Okay. But that leaves OV (Organization Validation) as DigiCert's least expensive option where their price for a single one-year OV certificate is now a breathtaking $324. Okay. So paying $324 for a certificate that would never even be valid, you know, I'm going to revoke it before I put it online, would be pouring money down the drain. So I went looking around for any widely trusted certificate which I could purchase for a reasonable price. That search brought me to, I kid you not, cheapsslweb.com. |
| Leo: Well, of course. There's where you needed to go. |
| Steve: That's what you want, cheapsslweb.com. |
| Leo: Wow. |
| Steve: And cheap they are. $12, paid one time, gives you the right to issue certificates for the domain of your choice as often as you like for two years. So that works out to $6 per domain-year. |
| Leo: They look like they're a reseller. They're not the certificate... |
| Steve: They are. They are. That's exactly what they are, Leo. They are a budget basement reseller. But their certificates are trusted. |
| Leo: They work. Okay. |
| Steve: Yup. They work. So they offer a five-year purchase for $20, which would bring the price down to $4 per year. But remember, the near-term schedule for maximum certificate life shortening means that two to three years is likely to spell the end, like two to three years from today is likely to spell the end of manual certificate issuance and management because it just becomes too frequent to be practical. Okay. So here's - remember what the story is. Until March - oh, and in case you're curious, I went with the - it was up near the top. |
| Leo: We don't like Comodo; right? We don't want to use Comodo or Sectigo. |
| Steve: I think it was that first one, Certera. |
| Leo: You want Certera, yeah. |
| Steve: That one. And so you see it says $3.99 per year, and buy now. Except that's the five-year price, where you're throwing away money because nobody wants to be - in four years from now, you've got to be changing your certificate every month. And so forget that. |
| Leo: Right. |
| Steve: So I went with the two-year plan. |
| Leo: Oh, there you go. |
| Steve: Which was the $5.99 per year. |
| Leo: That's $6 per year, okay. $12 total. |
| Steve: Yeah. So you can see that you buy two years for 12 bucks; right. Okay. So here's the way - here's the strategy here. So until next March 15th, certificates are allowed to have a 398-day life. So 13 months. Right? But the CA/B forum requires that to be cut in half, to just 200 days, on March 15th, next March 15th, then again cut in half to 100 days a year later, and then so that would be in 2027. And then finally down to 47 days two years later than that, in 2029, four years from now. Okay. So depending upon how resistant you or your application, whatever it may be, might be to automation, which, you know, automation will be pretty much required after March 15th of 2029, when certificates will only be allowed to have a 47-day maximum life, you might want to do this two-year plan. So two years, which you can purchase for $12. Now, under that plan, you would purchase and begin using that certificate now. Then you'd re-issue, or issue another certificate shortly before next March 15th of 2026, when you can still do so for another full 398 days. So that gives - so you get a half a year between now and then. Then you get a full year from then, as long as you do it before March 15th, you can make a certificate last 398 days. Then you issue a 200-day certificate a year later, shortly before March 15th of 2027. Again, March 15th of 2026 dropped it to 200 days, but you made your certificate the day before, so you can do it for a full year. But when it comes around to March 15th, 2027, it's about to drop to 100. So just before March 15th of 2027, you reissue the certificate again for 200 days. Now you go 200 days. And before that certificate expires, you need to get going with automation. But this allows you essentially a full two years from today to have useful, fully honored and recognized TLS certificates for $12 from cheapsslweb.com. Anyway, so if you're not ready yet to invest the time and effort to move to Let's Encrypt's ACME automation for whatever reason, you know, I'm not, I've got other things to do, I wanted to let everyone know that this downward pricing pressure that Let's Encrypt has clearly been placing on the traditional DV (Domain Validation) certificate market, has resulted in extremely inexpensive, yet still widely trusted, manually issued and installed domain validation certificates while they last. I would not want to be in that business in a couple years, but it's still there now. You know, it won't be feasible to do manual issuance after March of 2029, but certificates issued just before those various deadlines will be able to live long enough for manual management to still be feasible for another couple years. And I have a feeling that's what I'll be doing. Okay. I wanted to follow up a bit on the status of this crazy Jaguar Land Rover cyberattack and what takeaways there are from that, since it's quite a harrowing story. What I saw reported in the Risky Business Newsletter was the following. They wrote: "The UK government has agreed" - the UK government - "has agreed to underwrite a 1.5 billion pound loan" - 1.5 billion pounds loaned - "to Jaguar Land Rover to help the carmaker deal with the increasingly costly aftermath" - I'll say - "of a recent cyberattack that has crippled its production and shut down factories for almost a month. "The underwrite was approved on Sunday after a visit from UK Business Secretary Peter Kyle to the headquarters of JLR (Jaguar Land Rover) and its main supply chain firm Webasto this week. JLR fell victim to a ransomware attack, supposedly from the Hellcat group, on August 31st. Production lines at all JLR factories have been shut down ever since, and are expected to last into October," meaning shutdowns into next month. "While it looked like another largely benign ransomware attack" - I don't know if any ransomware attacks are benign - "that hits the back office, and the company then needs to reinstall some accounting systems to get back into order, this was not it. Not at all. Systems like CAD, engineering software, and product life-cycle software, payments tracking, customer car delivery systems, the works, went down. The incident has turned into a legitimate catastrophe for both the company, its suppliers, and even the British economy as a whole. "With production lines ground to a halt, hundreds of small companies that supplied Jaguar parts and various services also had to slow their pace and even put workers on leave. Several of the smaller ones are facing bankruptcy and were expected to go under, since several had just 'days of cash' left in their accounts. "With no car sales and no secondary economic activity being generated by its supply chain for an entire month, the Jaguar Land Rover cyberattack is likely to impact the UK's economic growth itself. The company alone employs over 34,000 people, with another 120,000 working throughout its supply chain. According to a recent report, the company also did not have a cyber insurance policy at the time of the attack and will likely have to foot the bill for the attack and subsequent revenue losses. Just Jaguar Land Rover itself is expected to lose 'hundreds of millions of pounds,' according to reports, which explains the need for an underwrite in the realm of 1.5 billion pounds." Okay. So we're not on the inside. We cannot definitively say why and how this happened. But the fact that the company was not carrying any insurance against cyberattacks, and that whatever happened was able to so deeply and so thoroughly nuke its operational capabilities, all that at least strongly suggests that the management of Jaguar Land Rover was not taking the reality of today's cyberattacks seriously enough. They may have felt that carrying cyberattack insurance would be prohibitively expensive. But one has to wonder how they might feel about that decision today. We've also seen cyber insurance companies themselves becoming increasingly involved in the organizations they're being asked to insure, setting operational requirements to minimize their and everyone else's risk. So it may have been the case that Jaguar Land Rover's observable cyberattack readiness was so poor, as now appears to be the case, that any prospective insurers were forced to quote either ridiculously high premiums and/or capping their liability to a point that carrying insurance under those terms didn't make any sense. The big takeaway lesson for all C-suite executives - and I sincerely hope that this, you know, this startling Jaguar Land Rover news reaches them - is that the maintenance of true cyberattack readiness is no longer something that can be just given lip service, then dismissed when the time comes to set budgets. The unfortunate reality is that today's cyber-threat landscape has truly and significantly increased the cost of doing business. This means that, one way or another, today's enterprises are going to pay, either in advance for preemptive protection and cyber insurance, or in the form of post-attack ransoms, possibly serious downtime, and reputational harm. And Leo, I heard you mention that you guys had some discussion of this on TWiT, or on an earlier podcast? |
| Leo: Yeah, not last Sunday, but a week ago Sunday. I have to remember who was - I think it was Father Robert was talking about this. As you know, he's very interested in security. Jaguar is owned by Tata, the big multinational, Indian-based multinational. |
| Steve: Right. |
| Leo: And he said that they're - it was his understanding that their security was flat, that they didn't have segmented architecture. They didn't have, you know, they basically had a perimeter fence. And once bad guys got in, they had complete control of the network and lateral movement and all that. It was just a flat network. That was his understanding, anyway. And I didn't... |
| Steve: And remember it was a week or two ago I was talking about the principle of least required privilege. |
| Leo: Yes, yes. |
| Steve: Where, you know, every entity on the network should only have access to those assets that it must have. |
| Leo: It's really a cautionary tale. You've just got to - yeah. |
| Steve: It's easy, it's so easy to plug a whole bunch of routers and switches together and put everyone on the same LAN. And it's like, oh, look, everybody can, you know, where do you want to print? What do you want to do? Anybody can do anything. But your, you know, your physical facility door access controls, you know, can be exploited by some low-level assistant in shipping if they click on the wrong link. |
| Leo: Yeah, that's not good. |
| Steve: No. It's a whole brave new world. |
| Leo: It's a very old-fashioned, yeah, this is a very old-fashioned way of doing it. And it's my guess that Tata just doesn't invest in modern security. And this is the thing. |
| Steve: Well, and there it is. You don't invest in - yup. |
| Leo: Taxpayers have to foot the bill for this, which is, you know, shameful. |
| Steve: Wow. Wow. |
| Leo: Yeah, yeah. |
| Steve: Okay. A headline in TechCrunch would give anyone pause. Last Wednesday they posted a story. Listen to the headline. Headline is "Neon, the No. 2 social app on the Apple App Store, pays users to have their phone calls recorded and sells that data to AI firms." |
| Leo: Oh, for training. Sure, why not? Why not? |
| Steve: Okay. What could possibly go wrong? |
| Leo: How much do you get, though? |
| Steve: Okay. Well, that's an interesting story. It's surprisingly a lot. And I don't think it can possibly hold. |
| Leo: That's suspicious if it's a lot, yeah. |
| Steve: Here's what TechCrunch reported. They said: "A new app offering to record your phone calls and pay you for the audio so it can sell the audio data to AI companies is unbelievably," they wrote, "the No. 2 app in Apple's U.S. App Store's Social Networking section. The app, Neon Mobile, pitches itself as a moneymaking tool offering 'hundreds or even thousands of dollars per year' for access to your audio conversations. Neon's website says the company pays 30 cents per minute when you call other Neon users, and up to $30 per day maximum for making calls to anyone else. The app also pays for referrals. The app first ranked No. 476 in the Social Networking category of the U.S. App Store on September 18th, but jumped to No. 10 by the end of last Monday, according to data from app intelligence firm Appfigures. "Last Wednesday, Neon was spotted in the No. 2 position on the iPhone's top free charts for social apps." |
| Leo: I'm not surprised. |
| Steve: I know. |
| Leo: Yeah. |
| Steve: They know kids. They know today's kids. "It also became the No. 7 top overall app or game early on Wednesday morning and became the No. 6 top app. According to Neon's terms of service, the company's mobile app can capture users' inbound and outbound phone calls. However, Neon's marketing claims to only record your side of the call unless it's with another Neon user. That data is being sold to 'AI companies,' Neon's terms of service state, 'for the purpose of developing, training, testing, and improving machine learning models, artificial intelligence tools and systems, and related technologies.'" So I guess AI models had a whole Internet full of text, but what they didn't have was a whole Internet full of audio data, people speaking. And so the entrepreneur behind this, some guy in an apartment in New York - I'm not kidding - decided, hey, that's a great idea. Anyway, we'll get to that in a second. So they said its high ranking within the Apple App Store, meanwhile, is proof that there is now some subsection of the market seemingly willing to exchange their privacy for pennies, regardless of the larger cost to themselves or society. "Despite what Neon's privacy policy says, its terms include a very broad license to its user data, where Neon grants itself a 'worldwide, exclusive, irrevocable, transferable, royalty-free, fully paid right and licensed (with the right to sublicense through multiple tiers) to sell, use, host, store, transfer, publicly display, publicly perform (including by means of a digital audio transmission), communicate to the public, reproduce, modify for the purpose of formatting for display, create derivative works as authorized in these terms, and distribute your recordings, in whole or in part, in any media formats and through any media channels, in each instance whether now known or hereafter developed.'" In other words, you have given it the right to impersonate you explicitly in this license. |
| Leo: Oh, yeah. That's interesting. |
| Steve: They said: "That leaves plenty of wiggle room for Neon to do more with users' data than it claims. The terms also include an extensive section on beta features, which have no warranty and may have all sorts of issues and bugs. Though Neon's app raises many red flags" - gee, you think? - "it may be technically legal." Well, sure, if the user says you can record me and do anything you want forever without limitation with my audio. Click here. Then, yeah. "Jennifer Daniels, a partner with the law firm Blank Rome's Privacy, Security & Data Protection Group, tells TechCrunch: 'Recording only one side of the phone call is aimed at avoiding wiretap laws. Under the laws of many states, you must obtain consent from both parties to a conversation in order to record it. It's an interesting approach,' says Daniels. "Peter Jackson, cybersecurity and privacy attorney at Greenberg Glusker, agreed, and tells TechCrunch that the language around 'one-sided transcripts' sounds like it could be a backdoor way of saying that Neon records users' calls in their entirety, but may just remove what the other party said from the final transcript. "In addition, the legal experts pointed to concerns about how anonymized the data may really be. Neon claims it removes users' names, emails, and phone numbers before selling data to AI companies." That's probably fine. Who cares? I mean, you've given them your voice, everything you've said. "But the company doesn't say how AI partners or others it sells to could use that data. Voice data could be used to make fake calls that sound like they're coming from you" - yeah, no kidding - "or AI companies could use your voice to make their own AI voices. "Jackson said: 'Once your voice is over there, it can be used for fraud. Now this company has your phone number and essentially enough information they have recordings of your voice, which could be used to create an impersonation of you and do all sorts of fraud.' "Even if the company itself is trustworthy, Neon doesn't disclose who its trusted partners are or what those entities are allowed to do with the users' data further down the road." And we just read that license agreement. You've given them permission to do anything with your voice anytime for any purpose they could ever imagine, forever. "Neon is also subject to potential data breaches, as any company with valuable data may be. "In the brief test by TechCrunch, Neon did not offer any indication that it was recording the user's call, nor did it warn the call recipient" that they might be recorded. "The app worked like any other voice-over-IP app, and the caller ID displayed the inbound phone number, as usual." They said: "We'll leave it to security researchers to attempt to verify the app's other claims. "Neon's founder Alex Kiam did not return a request for comment. A business filing shows that Kiam, who is identified only as 'Alex' on the company website, operates Neon from an apartment in New York. A LinkedIn post indicates Kiam raised money from Upfront Ventures a few months ago for his startup, but the investor did not respond to an inquiry from TechCrunch as of the time of the writing." So then they ask: "Has AI desensitized users to privacy concerns?" They said: "There was a time when companies looking to profit from data collection through mobile apps handled this type of thing on the sly. When it was revealed in 2019 that Facebook was paying teens to install an app that spies on them, it was a scandal. The following year, headlines buzzed again when it was discovered that app store analytics providers operated dozens of seemingly innocuous apps to collect usage data from the mobile app ecosystem. "There are regular warnings to be wary of VPN apps, which often aren't as private as they claim. There are even government reports detailing how agencies regularly purchase personal data that's 'commercially available' on the market. Now AI agents regularly join meetings to take notes, and always-on AI devices are on the market. But at least in those cases, everyone is consenting to a recording, Daniels tells TechCrunch. "In light of this widespread usage and sale of personal data, there are likely now those cynical enough to think that if their data is being sold anyway, they may as well profit from it. Unfortunately, they may be sharing more information than they realize and putting others' privacy at risk when they do. "Jackson said, finishing: 'There is a tremendous desire on the part of, certainly, knowledge workers and frankly, everybody to make it as easy as possible to do your job. And some of these productivity tools do that at the expense of, obviously, your privacy, but also, increasingly, the privacy of those with whom you are interacting on a day-to-day basis.'" Okay. So I have several reactions to this. |
| Leo: I can guess. |
| Steve: Although I know I'm not talking about this audience, many people really don't care about their privacy all that much. I've received sufficient feedback through the years from the people who take the time to listen to this podcast to know that the great majority of our listeners would have no problem being characterized as 'old school' as regards their privacy and concerns for online security. But we're the extreme cases. I think the huge majority of people really do not care. So I'm not surprised to learn that an app that promises to pay up to $30 per day in return for having one's voice recorded and sold is succeeding. It's not difficult to imagine this app spreading like wildfire across school campuses. And the bonus of increasing the payout if both parties are using the service is such a clever way of getting the system to go viral. What surprises me is the size of the payout amount, which seems quite high, and I would be surprised if it turned out to be sustainable at that level. So there may be some early adopter bait-and-switch going on here, where the payout rate will eventually drop once the system has been widely established and adopted. Also, how are the funds sent back to Neon's users? I downloaded the app to see what I could learn, but there was no option other than signing up, giving it my phone number, which being something of an avid listener of this podcast myself I was unwilling to do. |
| Leo: You've learned from yourself. That's good. |
| Steve: That's right. There's an echo in here. So I got no further than that, so that remains an open question to me. How are users paid this $30 per day? The last thought I have is that, as I'm sure would be the case for many of our listeners, I would have a big problem with not being informed that my voice was being surreptitiously recorded and sold by whomever I was speaking with on the other end of a conversation. They say that's not happening, so we have to take them at their word. Not only is it just creepy, but voice authentication promises to be a serious problem in the future. You know, when you combine AI's ability to convincingly converse with generative AI's ability to on-the-fly spoof the voice of anyone it has a sufficiently mature sample set for, all the pieces are in place for trouble. Some time ago I told my office manager and bookkeeper, Sue, that she must verify with me in writing, via our internal email, anything she believes I've instructed her to do verbally that regards moving money. And we've been practicing that for some time. |
| Leo: That's good. That's really good. I like that. |
| Steve: I have told her that I will never tell her not to confirm in writing, and that no emergency is too great for verification first. So we've been doing that for years. Anytime I have a conversation with her and tell her to do something, she follows up by sending me an email, and our GRC email is internal, it goes to no external services or servers. And so I know that may seem extreme and inconvenient, you know, sort of like freezing one's credit reporting, but these sorts of simple measures can make the difference between being a victim or not. |
| Leo: Oh, no. We get email every day instructing our accounting department to pay some bill or other that's bogus. It happens every day. |
| Steve: Yup. |
| Leo: You have to do it. You have to do it. |
| Steve: Yup. Yeah. And I hold a bunch of trademarks, and one of the scams is that trademarks are published publicly, and so there are firms that go through public trademark registries and just send out bills to trademark holders to the physical addresses that are registered, saying it's time to renew your trademark. Send $1,800 to this address, and we'll take care of it for you. It's like, what? I have an IP firm in L.A. that does this. You know? But so I see how much of this bogus nonsense there is. |
| Leo: There's so much. |
| Steve: And it just must be that in large firms some accounting departments just pay whatever invoice comes in. |
| Leo: Well, it doesn't have to work much. Just once in a while. Right? |
| Steve: Right. It's like spam. Spam mostly doesn't work. But enough of it does that - and since it costs nothing to send it... |
| Leo: Exactly. |
| Steve: ...spam we have. |
| Leo: Yeah, it's amazing. |
| Steve: Wow. I wanted to correct or at least clarify something that I said about the decentralized social media service Bluesky and its age verification. We know that Bluesky has suspended all of its services in Mississippi, just across the state, due to that state's nutty "only proven adults can access any social media" law. Which, again, as I said, that's just, what? And I wondered, like, is Meta just ignoring this? You know, it's like, okay, come sue us? You know, because Bluesky is a small group. And so they thought, okay, we have to obey the law. I guess Meta's just thumbing their nose at it and saying... |
| Leo: I don't know. That's a really good question. I don't know what they've implemented. Yeah. |
| Steve: Yeah. And we also recently noted that Bluesky would be doing the same thing in the states of South Dakota and Wyoming as they have in the UK, where there is a saner law. In the UK and in those two states, only access to adult content, not all content, just adult content, then requires some proof of age. So that's more reasonable. Okay. Then yesterday I ran across another update on Bluesky in TechCrunch. They began their report saying: "The social media network Bluesky will begin verifying users' ages in the state of Ohio to comply with new regulations, starting on Monday, September 29th." That's yesterday. "The company, which offers an open and decentralized competitor to X and Threads, says it will enable the Kids Web Services' age verification solution in the state. This is the same solution that Bluesky is already using in South Dakota and Wyoming to comply with similar laws. "Bluesky announced the move in Ohio on Sunday via its Bluesky Safety account, and in an update to last month's blog posting about the matter. The changes come as a number of U.S. states are rolling out their own age verification laws to protect children from online risks, given the lack of federal guidance. The Ohio law, meant to protect kids from pornography, will require users in Ohio to upload a copy of their government-issued photo ID or other personal identification before accessing adult content. This includes the type of adult content that can be found on social networks. "KWS" - that's the abbreviation of Kids Web Services - "KWS will provide the technical infrastructure that allows Bluesky to verify users' ages by offering multiple ways for them to do so beyond only uploading a government-issued identity document. According to its website, KWS also lets users verify by facial scans, payment cards, and more." Okay. I had previously assumed incorrectly, or at least intimated, that Bluesky's use of something called KWS, Kids Web Services, was some homegrown solution that they had cobbled together as a means of verifying age. But TechCrunch reported it as an outside service. And, indeed, that's what KWS is: www.kidswebservices.com, all one word, kidswebservices.com. I learned that KWS has been around for quite a while. Four years ago, in fact, today, four years ago today on September 30th, 2021, they posted a piece under the headline "Making the Internet (and metaverse) safer for kids with free parent verification for all developers," where they explained: "Today, one of the biggest challenges for developers and content owners is enabling access for young audiences." Okay. But now putting this into a temporal context, remember that was four years ago, long before all this recent state and federal legislation began blowing up in our face. So what was the need back then? It was access to video game content. The year before they posted this, KWS merged with Epic, with Epic Games. They said: "In order to enable features which may require personal data, such as content personalization, navigation, or push notifications, children's privacy laws like COPPA and GDPR-K may require you" - 'you' meaning developers, you developers of online gaming - "to obtain the consent of parents and in many cases verify that the parent is an adult. This is called verifiable parental consent. Securing verifiable parental consent creates a user experience where a child has to educate their parent, the parent has to go through the registration process, then verify their identity, and only then grant permission to their child. As painful to get through as the sentence is to read." Yeah. "And this has to be repeated every time a child wants to access a new digital experience. "Many developers look at the complexity (and cost) of the parent verification process and choose to simply avoid young audiences entirely. Large developers can afford the luxury to build their own solution, or license ours. Small developers don't have the luxury. Our Kids Web Services (KWS) platform already powers parent verification for some of the biggest games in the world, including Fortnite and Among Us. KWS delivers the most frictionless parent experience in the industry, thanks to its innovative ParentGraph. Once a parent is verified using KWS, they never need to provide their verification details again for any other service using KWS technology, minimizing personal data processing and providing a better user experience for both parents and players. Today, the ParentGraph includes millions of pre-verified parents and is growing rapidly. "While we are heartened to see more technology companies thinking about access and safety for their younger audiences, the future of the Internet and growth of the metaverse requires kidtech tools to be available to everyone. The ability to execute at this kind of scale is exactly why we joined Epic Games last year." So I was curious to learn how their parental verification worked. Elsewhere in their FAQ, answering the question "What type of verification methods does KWS use?" they explain: "KWS continuously optimizes and adopts new parent verification methods and vendors. Our verification team continuously researches, tests, and adds new methods and vendors to raise the standard of our parent verification service. We offer developers and parents methods that are as inclusive and widely accessible as possible, while minimizing personal data collection. "Depending on the child's location, our current verification methods include the following: Credit Card/Debit Card Verification." And for that they use Stripe. Stripe has an age verification service, so they sub that out to Stripe. "Facial scan; Document ID scan; Social Security Number - in the U.S. an SSN, or CPF or CURP checks; an i-PIN (available only in the Republic of Korea); and cell phone (available only in the Republic of Korea)." So one of the reasons this system was so appealing to Bluesky and will likely be appealing to many others is that it is 100% free of charge, regardless of the usage volume. Anyone, any developer, is free to use this established system rather than needing to build their own. For parents whose kids wish to have access to Epic's games, this meant that they only needed to go through the annoying process of proving they were an adult one time. And the site does talk a lot about data minimization, hashing identities, and so forth. I didn't spend any time digging into the details of the system's operation because I sincerely hope that in the long term its operation will not matter. That is, I hope it's an example of the sort of stop-gap measure that websites and online services will be driven unfortunately to adopt in the short term until we obtain the standardization that we need. We don't have that today. There's nothing that Bluesky can use, so they're using this third-party service that, if nothing else, you know, is well established. So I think, you know, I mean, nobody wants to give their credit card or a facial scan or anything. The whole thing seems kind of flaky. But it does give Bluesky the ability to say that they're protecting their adult content with a system. They didn't have to roll their own. They just, you know, made an API call to the KWS servers, and they're able to do this for no charge. |
| Leo: Yeah, I mean, in order to talk to the federal government, I have to use ID.me; right? I mean, this is... |
| Steve: Right. |
| Leo: We're kind of used to this idea. Do you know anything, I mean, is KWS cool? I mean, are they good? I don't know anything about them. Not that I know anything about ID.me, either, except that the IRS requires it. |
| Steve: Yeah. And, you know I've got my California Digital Driver's License in my phone. |
| Leo: Right. Me, too. |
| Steve: And it is able to do age verification and age assertion. |
| Leo: Right. |
| Steve: So as soon as, I mean, we're just waiting for these pieces to come together. Unfortunately the legislation is not waiting. And I guess you could argue that unless we had laws that force the technology to move, we know how slowly technology moves, Leo. Maybe it would never happen unless we had, you know, legislators screaming about it and forcing ad hoc solutions, and websites going dark across states. |
| Leo: Right, right. Well... |
| Steve: It's a mess. |
| Leo: It sounds like, though, we're getting somewhere. We're getting closer to a possible solution. |
| Steve: Yes, yes, yes. I do think - I think what we need is states to widely adopt digital licenses. I think digital driver's licenses... |
| Leo: That's a good way to do it, yeah. |
| Steve: Yes, because you already are known to your state. And then allow your phone to assert your age to a third-party website. |
| Leo: Right. |
| Steve: And that can be done without identifying who you are at all. Absolutely anonymous. |
| Leo: I'd rather get that information, that verification from the state and the federal government or any private company. So I think you're right. I think that's the best of a bunch of imperfect solutions. |
| Steve: Yeah. Okay. The Internet scanning company Censys, spelled C-E-N-S-Y-S, posted last Wednesday that their comprehensive Internet scanner had identified 10,600 publicly accessible instances of Ollama large language models just flapping in the breeze. Just out there for anybody to query. |
| Leo: It's pretty easy to do that by accident. I use Ollama, and it sets up a web server, which should be local; right? |
| Steve: Well, yes. |
| Leo: It's a 192 address; right? |
| Steve: Yes. It is bound to your localhost IP at port 11434. It turns out, though, that if you want it, if you add a line to its configuration, it's not difficult to bind it to other interfaces. |
| Leo: 8080 or 80 or 443 or something. |
| Steve: Yeah. |
| Leo: Yeah. Whoops. |
| Steve: So they wrote, they said: "As we write this in September 2025" - that's, you know, today, or actually the last day of September 2025 - "Large Language Models are so hot right now. For those who are not familiar with the hype, LLMs are widely used for a range of applications, and frameworks like Ollama make it easy for users to spin up an instance for their personal use." Just like you did, Leo. "To add to this, many organizations now publish guides to help users spin up LLM instances faster. However, with this ease of use also comes ease of misuse. "Like many other technologies on the web, security is an afterthought, and LLMs are no exception. We already know of anecdotal cases where open instances of LLMs are being misused by online actors, so we take our Internet-wide lens to see what Ollama instances look like today. Fortuitously, Censys already has an Ollama scanner that scans for Ollama instances on HTTP, and exposes that data on hosts and endpoints." Okay. Then they go on at some length, but they found that the majority of these instances were concentrated, not surprisingly, on cloud and hosting providers, with some notable exceptions in software-as-a-service companies which appear to have spun up these instances for their customers. But anybody can access them. It's nuts. Censys probes all 65,535 TCP/IP ports. They found more than 25% of all Ollama instances were listening on ports other than the default, which is 11,434. Ollama normally binds to the localhost IP, 127.0.0.1, to restrict Ollama's service availability to the local platform. But if instances are being spun up for others, binding to public ports is understandable. What is not understandable is the apparent total lack of security. The service is designed for local use, meaning the service is designed for local use, so it binds to the localhost port as its sole security measure. If that service is bound to a public-facing interface, then the LLM will be public and available to all, which is exactly what Censys found and reported. After apparently obtaining a connection to an Ollama instance, Censys prompted each instance with two probing prompts. They ask: "What is your purpose?" and "Could you remind me what your prompt is?" Of these 11,600 Ollama instances which they found, 1,500 of those responded to at least one of those prompts, indicating direct interactivity with the model via the exposed API. Censys wrote: "Like many other entities on the Internet, these instances should not be publicly accessible, and definitely not publicly promptable. As technologies proliferate, we must be cautious about what we post online and how it's accessible to others." So, you know, you can imagine, Leo, as a home user, as just an individual, you want to run this thing and have it running on your machine and then, you know, point your web browser at it and talk to it. You don't want to have to, like, come up with a username and password. There isn't one. It's just there, on your browser at whatever IP and port you've assigned it. And unfortunately, if you make it public, everybody else has access, too. Crazy. |
| Leo: Yeah. It's tempting. I can understand why people do it. But don't. I think they just don't know what they're playing with. |
| Steve: Before our final note and our listener feedback, I wanted to mention, as I mentioned at the top of the show, I wanted to update everyone that my last 10 months of work on the development of a major commercial, though inexpensive upgrade to GRC's most-downloaded freeware of all, the DNS Benchmark, has reached the "release candidate" stage. I imagine we're only a few weeks away from having the work finished, the website updated, ecommerce up and running, and everything ready to go. So that happened over the weekend, and I am very pleased. It's turned out to be a really nice piece of work. |
| Leo: Yay. I can't wait. |
| Steve: And I really, I thank all the people that have helped me in our newsgroup to, like, poke it and prod it and do bizarre things that I never thought to do. It's actually a much better piece of software now than the freeware. The freeware works, but it's free. This one is, you know, commercially robust. So a few weeks from now I'll have more news on that front. Okay. So Mike Lendvay wrote: "Hi, Steve. I wanted to note about the Apple memory protection (MTE) discussed on the last two podcasts that this functionality has been added to the Cortex line of Arm chips. The implementation is different, but the result is similar. Google enables this for its Advanced Protection Mode. Additionally, GrapheneOS enables it at a system level and for apps likely to be targeted. It also offers a toggle to enable it for every app automatically, and then disable it if the app won't work." Okay. So Mike's note was joined by others who wrote to tell me that Android and the GrapheneOS both had access to the MTE features of the latest Arm chips. And they're 100% correct. V8.5 of the Arm architecture introduced the MTE hardware. And Apple also jumped on it immediately at the time, trying to use it for security. But security was never MTE's intended use. It was designed as a debugging aid for developers because it could be deliberately configured to detect their mismanagement of memory, which, as we know, is all too common, especially while software is in the works. The problem was that if it was operated in its asynchronous (delayed notification) mode, that was useful for developers, but not for security, which needed to prevent any misuse before it was allowed to occur, not to notify afterwards when it might well be too late. And operating MTE in fully synchronous (immediate blocking) mode incurs a significant performance overhead, which makes it impractical to use everywhere all the time, or even often. So Apple first worked with Arm to extend the concepts of MTE after, you know, based on what they learned from trying to use it as soon as the 8.5 Arm architecture came out. And that created EMTE, the Extended MTE. Then they decided to commit, because they still couldn't get what they wanted, that is, performance and security both. Then they decided to commit the chip real estate resources needed to take those concepts, which had been proven to work, but still introduced excessive overhead when used for security enforcement, and that resulted, that work resulted, that hardware commitment, to the A19 chips and what Apple called MIE, Memory Integrity Enforcement, which is not available to anyone else at this point except Apple. So it's true that generic Arm chips such as the Cortex family do now have MTE, but it needs to be used very sparingly when it's employed in synchronous mode for security enforcement. You can use it asynchronously. You get notified of a memory problem, but in some cases it could be before, you know, after that memory problem has been used for an exploit. And Apple just said no, we need this thing to operate all the time and operate synchronously. So that was why they extended the Arm architecture as they did in a way that nobody else has. At least not yet. And as I said last week, having thought about it further, I'm not sure that it makes sense for anybody else to do it. I don't think Google and Samsung or anybody else probably ought to bother because it is, you know, it's a massive investment in order to get just that last .0000000001 of the people. You know, the highly targeted people. Apple just - they've got somebody there in Cupertino who just refuses to have a single compromise. And the rest of us get the benefit of that; right? We're not... |
| Leo: Yeah, it's good for their business. I mean, this is, you know, people trust them because of this, yeah. |
| Steve: Yes. Exactly that. And it means that we're not having to update our iOSes often because they've got to update iOS for everybody when they find some little problem that might affect almost nobody. And so this just means it's going to be a more stable OS. I think it's great. Mick Fink said: "Hi, Steve. I tried experimenting with Passkeys. We use Microsoft Office and Azure at work, and because Entra would not let me install a Passkey directly on my Mac for whatever reason, I added it instead to my Microsoft Authenticator app on my iPhone. Here are the two login flows, side by side: Username & Password versus Passkey. "Okay. Username & Password. Open password manager. Click the Launch button for my Microsoft account. Username and password are filled in automatically. Right. A window comes up with a two-digit code that I have to enter into my MS Auth app. Pick up my phone, unlock phone with six-digit code. Click on the authenticator app on my phone. Reenter my phone's device code for the MS Auth app. That is, the six-digits again to unlock the Auth app. Enter the two-digit code. Tell my computer yes, I would like to remain signed in, and I'm in." Okay. That sounds like a lot. He demonstrates the Passkeys as worse. He says: "Now, let's do this again with a Passkey. Click on login bookmark on my computer. Pick an account. I have two accounts. Let's use the Passkey one. Click the Next button on the 'Face, fingerprint, PIN or security key' welcome screen. Click on where my Passkey is saved. Not on my Mac. I couldn't do that. So let's click on the phone option. I receive a QR code to scan. Unlock phone with six-digit code. Click on MS Authenticator app. Enter six-digit code again for MS Auth app access. Click on the QR code scanner button. Point the camera at the computer screen. The QR code is seen and registered. MS Auth app says: 'Your iPhone needs to connect to this device in order to sign-in with a Passkey.' "Phone's Bluetooth," he said, "was already enabled, otherwise that would be more clicks. So Click the Continue button to permit MS Auth to proceed with permission. Sign in by clicking the Use Passkey button on my phone. Enter six-digit phone code yet again. Tell my computer, yes, I would like to remain signed in." He said: "Now the computer screen finally shows me that I am logged in. Is it any wonder why Passkeys are not popular yet? Love your show. Mick Fink." So it did occur to me, looking at that, that using Face ID for all those various intermediate authentication stages would make things easier. The trouble is, and the trouble that he's basically highlighting, there are so many places where abuse could be inserted into the flow, that we're stuck needing to continually re-authenticate, switch devices, arrange inter-device communications, and jump through hoops. I'm sure that Mick's point is to acknowledge the enhanced security, but to wonder whether it's really worth all the trouble? And I can really see his point. The biggest threat was having a single password that people used everywhere. Right? Remember, Leo, the old days 20 years ago. It was what's your password? Monkey123. |
| Leo: Right. |
| Steve: It's like, okay. Or password was most people's password. Because no one gave a crap back then. |
| Leo: Didn't matter. |
| Steve: But, yeah. Password-based password managers, I mean, browser-based password managers solved that problem, and we've had them for years. It's tempting to wonder whether we shouldn't have just left well enough alone with that. Having a Passkey is unquestionably useful when super-security is called for. But that's really comparatively rare. Right? Since I'm the only person who uses any of my own PCs, I have every single site logging me in permanently anyway. Yes, I need to authenticate to my computer when I boot it up. But once it's on, all the sites know me. Whenever I need to do anything important, such as managing investments, I'm required to respond on the fly to email and a phone message loop, a one-time password, and go through all that effort in order to even be working with a PC that it's previously seen. So I guess my takeaway is, since no one is forcing, yet, Passkeys upon us, and since they are truly more hassle to use, don't use them when they're not something that you really need. It may seem cool in the beginning, to like use a Passkey. But as we've just seen, it puts you through a lot of extra effort every time you need to authenticate yourself, which may not be all that important for most of the sites you use. And also, using Passkeys in same-device mode, which this guy's system for whatever reason would not allow him to do, if it had been on his Mac it would have been a lot easier. Same device mode, you know, where you don't need to coordinate multiple devices and a separate MS Auth app that you need to authenticate to three times, that, you know, makes it much easier to use. So his was probably a worst-case situation. |
| Leo: Yeah. This is not how I use Passkeys at all. I have it in Bitwarden, and it's easier... |
| Steve: Right, right. |
| Leo: ...then just doing a password because I just, you know, I enter the - it depends on the site. Some sites make it harder, I agree. But most sites... |
| Steve: Right. There is not a uniform flow. |
| Leo: Right. Most sites, after I enter my email address, will say - there's a button that says "Use Passkey." Bitwarden handles it from there, and I don't have another click. I'm done. It's easier to me than a password. So I prefer Passkeys if sites make them available. Now, I have to say there are some places like Amazon where you still have to enter in for some reason, your six-factor authenticate code, after you enter the Passkey. It's like, what is that adding? Nothing. |
| Steve: Nothing. |
| Leo: What are you doing? So it isn't - that's part of the problem is it's still early days on Passkeys. In theory. They should be more convenient, I think. |
| Steve: We'll get there. |
| Leo: Yeah. |
| Steve: We'll get there. Yeah, and I guess I think that maybe he doesn't have a choice with his company. |
| Leo: Maybe that's it. |
| Steve: And Entra and the MS Auth. |
| Leo: That's the problem. |
| Steve: But all that MS Auth nonsense, yeah. |
| Leo: That's the problem. It's Microsoft. If you're using - the normal person using a password manager, you know, I use Bitwarden. I use Passkeys whenever possible. And because Bitwarden's everywhere, or 1Password or whatever, you know, whatever you choose to use... |
| Steve: Whatever your tool. |
| Leo: It's on everything. It's not tied to your phone specifically. It's on everything. That's very convenient. It seems to me it's more convenient. But maybe it's just me. I don't know. GitLab also requires a one-time password after logging in with a Passkey. So maybe there's something going on. Amazon and GitLab know that - I don't - that's what Darren's saying. I don't - it seems odd. GitHub makes it so easy. It's just great. I love it. |
| Steve: Chris Forrester, a listener, said: "Hello, Steve. After listening to the last few weeks' discussions on age verification, I had a thought I'd like to have your input on. I realize the onus is currently being heavily placed on the provider of age-restricted content, similar to physical locations such as restaurants, bars, and convenience stores which are required to proactively assert a user's age prior to selling them alcohol. However, as has been pointed out several times, this is not the physical world being dealt with in these discussions, and this problem is going to be fought as an unacceptable burden by the providers. Episode 1044 really brought that home to me." Actually, last week's episode really registered with a lot of our listeners. He said: "Is it reasonable to believe that we will begin seeing a turn to the client as being the responsible party? For example, let's say there's a single PC in a household of four individuals. That PC is a shared device and has a single username. Perhaps these are non-techie people who don't think that's a problem in and of itself. Perhaps it's a grandparent who allows their grandkids to use the PC whenever they come over. "I believe it's possible we will see laws enforcing strict user account controls in order to enforce age verification requirements, where each account is associated with an age verification service of some kind, and the abuse of those restrictions is punishable by law. Basically, each account becomes a vault only accessible by the intended user. "It seems like this would fall in line with more real-world scenarios such as, say, a liquor cabinet, where the responsible adult is considered fully liable when accessed by minors. I don't like or agree with it, but I feel like this is a real possibility of where the longer road is leading. I was a TechTV watcher when I was a kid." |
| Leo: Awww. |
| Steve: "And I've been a weekly listener to Security Now! since 2007 and cannot begin to tell you how much I've learned from you and Leo over the years. You two are 100% responsible for my career in security-focused software development, and I would be honored to have a mention on the podcast. If that were to happen, feel free to use my name! Looking forward to Episode 2,000. Thanks. Chris Forrester." |
| Leo: Thank you, Chris. |
| Steve: So Chris, welcome to, what, 18 years of the podcast. So, glad to have you. |
| Leo: And now fame and fortune await. |
| Steve: So what Chris suggests is an interesting extension of the notion I shared last week where a user's browser is aware of its user's date of birth. It never discloses that date. But by using some future W3C browser API extension, a website is able to ask for that information. Rather than giving it over freely, the browser informs its user that it's being asked for their age, and the user can then decide whether this is a reasonable request based upon where they are, and they would be free to decline. Now, presumably, if the user had not in some way authenticated themselves to the browser already, the prompting for their age would then require that, too, them to authenticate themselves to the browser somehow. So what Chris has added to this model is that our authenticated operating system logon sessions would provide that authentication. Our OS account, for example, such as Microsoft now has us logging into them all the time, might possess a confirmed date of birth which a browser running on the system could inherit from the logged-on user and then only need to confirm whether the user wishes to let the site they're visiting know, you know, what their age bracket is. And conceivably, browsers could also be preset with a "never ask," "always ask," or "always just say yes" setting to decide how to handle such remote age requests, depending upon the user's preference. So it might just be done for you automatically, very much like the Do Not Track or the GPC signals that our browsers give out in their headers. So anyway, I'm with Chris, and I'm sure with those who are listening, that this is all a big mess. But, you know, laws are being written, whether we like them or not. And we're already seeing services and sites that we use either pulling up stakes or working to remain online and compliant with these emerging laws. We need standards desperately. Brian Tanner wrote: "Hey, Steve. A while back you pointed to a video by an LLM guy that was a soup-to-nuts explanation of how the whole LLM system works. Try as I might, I can find neither the reference nor the video. Could you point again, please? Brian." Absolutely. I'm sure that Brian was recalling the amazing presentations created by Grant Sanderson, the "Animated Math" wizard over at 3blue1brown.com. Go to 3Blue1Brown.com, in both cases use just single characters for the numbers, you know, so the digit 3, B-L-U-E, the digit 1, brown.com. Then click on "Neural Networks." You'll see a big grid of topics. That's where the tutorials that I talked about before are located. And they are, they're as good as you remembered. I've got a link to the first one, just to get you started, in the show notes down here on page 20, if you're interested. But anyway, 3blue1brown. And there's a bunch of stuff that's fantastic at that site, not just the LLM stuff. But Neural Networks is the series that takes you from the beginning all the way through. |
| Leo: I also, yeah, this is the Neural Networks. I have a recommendation, as well. I like, and I've mentioned this before, Andrej Karpathy, who was at OpenAI, one of the founders, went to Tesla, does AI there, he's a very, very smart guy. This is a 3.5-hour lecture on how LLMs work that includes training, includes the latest in reinforcement learning and how that works. |
| Steve: Wow. |
| Leo: Once you watch the 3Brown1Blue, I think this would be the next step because this is from an actual AI researcher and scientist. And his understanding of this I think is very deep. |
| Steve: How do we find that? |
| Leo: It's his channel on YouTube, Andrej... |
| Steve: Yeah, but - okay. So K-A-R-P-A-T-H-Y? |
| Leo: T-H-Y. And it's a deep dive into LLMs like ChatGPT. All of his videos are great. But this one, deep dive into LLMs, it's seven months old, and it's had 3.6 million views. |
| Steve: Yes. |
| Leo: And I think it's because it is - it certainly, I felt like, taught me what I needed to know about how LLMs work, you know. And as a result, I think it made me a better user of LLMs because I understood better what they could and couldn't do. |
| Steve: Yeah. Nice. |
| Leo: But I like, I also like the one - this 3Brown1Blue is really good. |
| Steve: Yeah, 3blue1brown is a perfect... |
| Leo: 3blue1brown, right. It's a great channel, yeah. |
| Steve: Is a great, well, and that particular series, I think they're 15 minutes each, and it's a great introduction to the technology. And it sounds like then Andrej's would be, as you suggested, a follow-on, yeah. |
| Leo: It's very deep. I mean, but then you're going to understand how these things work, which I think is something people want; right? |
| Steve: Ryan Lloyd asked: "Hi, Steve. I watched a video linked to in Episode 1044 on the digital age verification implementation from the EU." Oh, that, that's the little video that we played, the two-minute, 46-second video. He said: "I found it interesting, working closely with companies in this space." He said: "I can't help but think there is one major oversight in this privacy-preserving approach, however. There appears to be no biometric/liveness verification that occurs at any point during the workflow. It appears to just be proving an identity card to the app, or to just be providing an identity card to the app. It seems to me a user could easily obtain such an identity numerous ways: borrow from their parents, reuse from their cousin, obtain on the Internet from a Reddit forum or black market." He says: "Young people facing a blockage in gaining access to restricted content material tend to be resourceful, so I'm struggling to see how this approach will really help ensure end users are kept out. It feels like this is less about verifying the age of the user behind the screen as it is about verifying the user can obtain a scan of an identity artifact that is of age. I welcome your thoughts on this. I had similar concerns when you raised the idea of browsers bearing the burden of age verification in the future. My feeling is that, even if a browser implements this, the browser has no guarantee that the user with physical access to the device is the same user who verified their age at some point in the history of setting up the browser, unless you wish to inconvenience every site with re-verification using liveness techniques. Thanks, Ryan." And I agree with everything that Ryan observed. Our listeners will recall how many times I've noted that to truly solve this problem, I mean, if you really want to solve it, any assertion of identity must be closely bound to some effective biometric authentication. If we don't do that, we're just creating another easily bypassed solution, the result being that everyone is inconvenienced while the actual problem remains unsolved. What we learn is just how difficult it is to bring real world solutions into the cyber world, you know, kicking and screaming. Lee MacKinnell said: "Hi, Steve. I decided to see if I could block my browser's access to localhost, so I asked Google and got this result." And he put a link to a superuser.com question. And the question was: "I am migrating to Firefox from Safari and noticed that websites, any website that I visit, has permission to attempt to make connections to localhost ports." Like, Leo, any website you visited could query your Ollama instance, for example. |
| Leo: Ahhh. |
| Steve: He says: "Is there a way to configure Firefox to block such connections? Safari already does this natively." Good old Apple. And the response is: UBlock Origin has this capability, but it is not enabled by default. To enable it, enable Filter lists, then go to Privacy and Block Outsider Intrusion into LAN. Block outsider intrusion into LAN under the Privacy setting for filter lists in uBlock Origin. Not surprising that old Gorhill was there before us and already has that built in. He said: "This always works for Chrome-based browsers like Brave, as it is also a setting in the UBlock Origin Lite version." So even if you can't use full any longer under Chromium-based browsers that are using the third-generation schema for extension add-ons, you can still do this in Lite, the Manifest 3. So that's Lee MacKinnell, Brisbane, Australia. Thanks very much for the tip, Lee. Appreciate it. And finally, Joey Albert. He said: "Steve, October 14." And then he gave me a link to the Windows end-of-support announcement. And he said: "We use" - and it's clear from his posting, "we" meaning our enterprise - "use 0patch, and it makes sense. The TSR patches in RAM and reapplies all patches when rebooting. So the subscription makes sense. It's like subscribing to streaming services. If your subscription expires, no more music." He said: "0patch is $41, translated from euros which they charge. Windows 10 support is $30 for consumers, but not for businesses. For businesses it's $61 for the first year and doubles each year after. It stops after three years. So 0patch is a bargain." Meaning instead of going 61, 122, what, 244 for the third year, 0patch for an enterprise is just $41 in euros. And that goes for five years, by the way, not stopping after three. So anyway, I thought that Joey's point was a good one. We need to remember that all of this Win10 ESU stuff is only for end-user consumers, not for commercial business users. None of this, I think, as far as I know, none of this applies to enterprise users who have Windows 10 Enterprise, as far as I know at this time. Of course as we know the situation is very fluid, so who knows. And Leo, that's 1045. |
| Leo: Wow. What a great show. I wish you would do these more often. I really... |
| Steve: I think we'll do it every week. How about we do it every week? |
| Leo: Maybe can we do it on Tuesdays? |
| Steve: How about we do it every week on Tuesdays and maybe for 20 years? |
|
 | Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy. |  |
| Last Edit: Oct 03, 2025 at 15:35 (45.98 days ago) | Viewed 12 times per day |