| ||||||
Description: Let's Encrypt drops its long-running email notifications. Microsoft's new "Unexpected Restart Experience." Microsoft's response to last year's massive CrowdStrike outage. Windows 10's extended service updates will sort of be free. Russia-sold iPhones MUST include the RuStore app. Lyon, in France, says bye-bye to Windows, hello to Linux. The U.S. Gov gets more serious about memory-safe languages. A new unbelievable AI malware scanner evasion technique. A new pair of Cisco 9.8 and 10.0 vulnerabilities. The current state of post-Elon government cybersecurity. PNGv3, Swift on Android, and the Samsung email purge. Andy Weir's "Hail Mary" movie trailer. And a close look at the pervasiveness of web browser tracking fingerprinting.
High quality (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-1032.mp3 |
SHOW TEASE: It's time for Security Now!. Steve Gibson is here. We have some very interesting things to talk about. Will Apple agree to Russia's demand that they add the Russian Store? Lyon, France says goodbye to Windows, hello to Linux. And then we'll talk about how hard it is to hide your identity on the Internet. Web fingerprinting the topic. Security Now! is next.
| Leo Laporte: This is Security Now! with Steve Gibson, Episode 1032, recorded Tuesday, July 1st, 2025: Pervasive Web Fingerprinting. It's time for Security Now!. You wait all week for Tuesday, and now it's here. Yes, time to find out what's going on in the world of security and privacy. And it's all thanks to this guy right here, Steve Gibson, the man in charge, GRC.com. Hi, Steve. |
| Steve Gibson: Hey, Leo. Great to be with you again for what happened to June? July 1st, the... |
| Leo: What happened to the year? |
| Steve: Yeah. |
| Leo: We're halfway through. How did that happen? Wow. |
| Steve: Yeah, yeah, yeah. Well, once upon a time you would forget to change the date that you put on your checks whenever they used checkbooks. |
| Leo: What's a check, Steve? |
| Steve: I know. I know. Those days are gone. |
| Leo: I have a checkbook, but I very rarely need to use it, yeah. |
| Steve: And we used to joke that it would, like, it would take until March for someone to stop writing, like, the previous year. |
| Leo: 20, yeah, 12 or something. It's been a while, yeah. |
| Steve: Yeah, exactly. Not a problem anymore. But now it's just like, what? Where does - where - what, what? Anyway, one thing that I'm glad for when I work all week and release another build of the Benchmark, like I just released build, I think it was release 26 on Friday evening. And I looked back, and I was glad to see that I had released 25 only, like, it was on the 20th. So it was exactly a week before. And it was like, oh, I got a lot of work done in that week. Because to me it feels like, you know, I released it a long time ago, and I didn't really achieve that much. But when I realize, oh, that was only a week ago. So sometimes that time dilation effect works in your favor, I guess is all I'm saying. We're going to be talking about the pervasiveness of web fingerprinting, but I didn't think that title would fit anywhere, so I squeezed it down to Pervasive Web Fingerprinting. |
| Leo: I think that works, yeah. |
| Steve: A group of five researchers did some experiments that have never been done before. We're familiar with fingerprinting. We've talked about it. Panopticlick is that site that the EFF created to sort of raise the awareness of the fingerprinting problem. The thing that's tricky about it is that traditionally it had been passive. Like, you know, web browsers, whenever they make a query, they dump a bunch of headers into the query, things like the user agent, and it contains a whole bunch of stuff. They used to, like, include the screen resolution under the presumption that, well, the web server could serve content tuned to the user's screen resolution, so that was there. There was like a lot of metadata that wasn't about the query, it was about the users' environment, and that advertisers and other trackers who are desperate to, like, profile people, track them around the Internet, would use all of those things as beacons. Well, then we upped the ante when scripting began to happen more pervasively. The worldwide web group just seem unable to stop with the features already. And so they keep adding more crap that nobody needs to JavaScript. And all of this stuff is like, well, you could use it if it was important to give someone a different web page if they were facing south than north. I mean, it's like, what? But unfortunately all of that is additional metadata that is now able to be pulled by scripting. So the brute force sort of approach of how much fingerprinting is going on was to ask, well, how much sort of sketchy web JavaScript is being used to pull all these sorts of things that no one really needs? So everyone's been assuming that fingerprinting has been super pervasive because there's all this now JavaScript which is pulling all this excess crap out of a person's environment, you know, the individual person's side, you know, client-side environment. No one until now has linked changes in that to changes in advertising behavior to prove that these things are actually tracking beacons, and these guys did. So we're going to talk about that at the end. But we're going to talk first of all about Let's Encrypt dropping their long-running email notifications. Microsoft's new, I love this euphemism, Leo, "unexpected restart experience," which Windows users... |
| Leo: Oh. |
| Steve: Yeah, that was not a crash. That was an unexpected restart. |
| Leo: An unexpected restart, that's all. |
| Steve: That's right. We're just going to give it a happy shiny name. Also we have Microsoft's response to last year's massive CrowdStrike outage. And the backpedaling, kind of, that we've been expected about Windows 10 extended service updating stopping in the middle of October. Turns out Microsoft realizes, whoops, we might be in trouble here. So there's a little change in policy. Turns out that Russia-sold iPhones must include the Russki store - actually, it's RuStore - app. France's Lyon says is saying bye-bye to Windows and hello to Linux. We've talked about some other, I think it was Danish regions that were doing that. Also, the U.S. government is getting even more serious about memory-safe languages. We have a new and truly unbelievable - as in, really? - AI malware scanner evasion technique which has come to light. Wow. And believe it or not, Leo, even after last week, we have a new pair of Cisco 9.8 and 10.0 horrible vulnerabilities that the world has just been made aware of. So buckle up. |
| Leo: After last week, man, geez. |
| Steve: I know. Also there was a piece about the current state of post-Elon government cybersecurity, and essentially the downstream consequences of what has happened to CISA that, you know, without getting into politics, this is what actually has happened, and we need to talk about that. So we're going to. And I'm going to turn off my screen blanker in a minute. Also we've got PNGv3, a brief touch about Swift on Android, the coming Samsung email purge. We've going to do a little touch into sci-fi by mentioning Andy Weir's "Hail Mary" movie trailer, which just dropped yesterday. And then, as I said, we'll close with a close look at the pervasiveness of web browser tracking fingerprinting. Now we have much stronger concrete evidence of that and are able to calibrate it. And what I learned, and this is perhaps the most important or interesting thing, is exactly what premium advertisers will pay to websites if the advertisers are able to identify their users. We've got a number. |
| Leo: Oh, that's interesting, yeah. They're always pushing us to do that. We can't do it. |
| Steve: I know. |
| Leo: We don't do it. But they always want it. I don't think, you know, I think there's a lot of evidence it doesn't make a difference, that they think it makes a difference, but it doesn't make a difference, targeting. |
| Steve: Well, we've got some numbers. |
| Leo: Yeah. Well, they, no, I know they think it does, and they're willing to pay for it. Anyway, we'll see. All full speed ahead with Security Now!. All right, Steve. I've got a Picture of the Week all cued up. I haven't looked. |
| Steve: So thank you. I gave this the caption "We're left with the impression that 'Fire Exit Only' is not taken very seriously." |
| Leo: Okay. I'm going to scroll up and give you my honest reaction. |
| Steve: "We're left with the impression that 'Fire Exit Only' is not taken very seriously." |
| Leo: Okay. And I like the admonition on the door. Here you go. |
| Steve: So, yeah. For those who are not seeing the show notes or video, this is clearly a well-marked door with a big EXIT sign hanging over it, a big all-caps block letters FIRE EXIT ONLY, so it's very clear. Now, what this doesn't have is one of those "Alarm will sound" things if you, you know, try to exit. So that's missing, which is probably a part of the story here, because underneath this FIRE EXIT ONLY in all block letter red caps it says: "Please close this door quietly, as guests may be sleeping." |
| Leo: Yeah, so... |
| Steve: So, right. |
| Leo: We don't want to wake them up with a fire or anything. |
| Steve: We would not, we wouldn't want the door slamming because of the fire exit being used to rouse anybody. And I can't see what that sticker is below the... |
| Leo: It's says camera is in use, you're being watched. |
| Steve: Oh, okay. Well, and there is a handily located fire alarm pull just to the left. |
| Leo: Right. As you run out the door... |
| Steve: As you're exiting, yes... |
| Leo: Don't slam the door, but you might want to pull that alarm. |
| Steve: To let other people know, yeah, you're leaving with a purpose. |
| Leo: Yeah. Please, close this door quietly. |
| Steve: That's right. |
| Leo: Thank you very much. |
| Steve: And almost, I was going to - about to say almost all of our listeners, but that certainly is not the case. Many listeners loved this week's xkcd, which we'll be featuring next week. |
| Leo: Oh, okay. |
| Steve: Because apparently it was spot-on for this podcast. |
| Leo: I haven't seen it yet, but I look forward to it. |
| Steve: So for those who haven't yet sent me this week's xkcd, I have seen it. |
| Leo: Don't. |
| Steve: And everyone will. Okay. So this notice from Let's Encrypt made a lot of sense to me. Their announcement was last Thursday, which read: "Since its inception, Let's Encrypt has been sending expiration notification emails to subscribers who have provided an email address to us via the ACME API." They said: "This service ended on June 4, 2025." So don't go looking for any emails. They said: "The decision to end the service is the result of the following factors." And they list four. "First, over the past 10 years, more and more of our subscribers have been able to put reliable automation into place for certificate renewal." Well, okay. That's good. I assume you didn't even try to use Let's Encrypt unless you had automation in place. And lord knows, once you have to renew your certificate every fourth hour, then you're really not going to have a choice. "Second, providing expiration notification emails," they wrote, "means that we have to retain millions of email addresses connected to issuance records. As an organization that values privacy, removing this requirement is important to us. Third, providing expiration notifications costs Let's Encrypt tens of thousands of dollars per year, money that we believe can be better spent on other aspects of our infrastructure." No argument there. "Fourth, providing expiration notifications adds complexity to our infrastructure, which takes time and attention to manage and increases the likelihood of mistakes being made. Over the long term, particularly as we add support for new service components, we need to manage overall complexity by phasing out system components that can no longer be justified." So 100% in agreement. And again, if you're looking for automated certificate issuance, you know, what you need is notification from your end if your certificates are not being refreshed by Let's Encrypt, as opposed to email from them reminding you that it's time to update your certificate. So, you know, it always seemed a little wonky. Okay. So they finished their announcement, saying: "For those who would like to continue receiving expiration notifications" - and again, why? - "we recommend using a third-party service such as Red Sift Certificates Lite," which was formerly known as Hardenize. They said: "Red Sift" - that's R-E-D space S-I-F-T - "monitoring service providing expiration emails is free of charge for up to 250 certificates." So that seems like a good thing. "More monitoring options can be found at," and then there is a URL, a LetsEncrypt.org URL, so letsencrypt.org/docs/monitoring-options. So anyway, I'll just pause to note that the idea of, you know, for belt and suspenders, of having a third-party looking at your site's certificate expiration, and presume... |
| Leo: That's a good idea, actually, yeah. |
| Steve: I haven't looked at what Red Sift is. I think that's a great idea. |
| Leo: It's still a Let's Encrypt certificate. It's just Red Sift is monitoring it. |
| Steve: Correct. Correct. And why not do that? You know, I mean, and so presumably you can tell them, let me know if my certificate expiration ever shortens to less than whatever you would expect it to be. So, you know, what, a day or something. And hopefully it would never come down to that. But yeah, I mean, I get fantastic email from DigiCert, so I'm not worried. But hey, again, belt and suspenders? Why not add a free outside service that is looking at your certificates also. And when it sees that there's not much time left, and presumably you can set what that is, sends you a notice. So yay. They said: "We've deleted the email addresses provided to Let's Encrypt via the ACME API that were stored in our CA database in association with issuance data. This doesn't affect addresses signed up to mailing lists and other systems. They are managed in a separate ISRG system unassociated with issuance data. Going forward," they wrote, "if an email address is provided to Let's Encrypt via the ACME API, Let's Encrypt will not store the address, but will instead forward it to the general ISRG mailing list system unassociated with any account data. If the email address has not been seen before, that system may send an onboarding email with information about how to subscribe to various sources of updates. "If you'd like to stay informed about technical updates and other news about Let's Encrypt and our parent nonprofit, ISRG, based on the preferences you choose, you can sign up for our email lists below." And this to me looks like a good thing. I would imagine a bunch of our - because clearly - I'm just interrupting myself. Clearly the world is going to be switching to ACME. We just aren't being given a choice... |
| Leo: Yeah. |
| Steve: By the worldwide, by the browser, CA/B, the CA/B group, the CA Browser Forum. They're saying bring this down. And actually, this is being driven, we know, by Apple, for reasons that still elude me. But okay. It's happening. So they have five mailing lists that can optionally be subscribed to: The Brighter Bytes, which is the ISRG Newsletter; Let's Encrypt Technical Updates, that seems like a cool thing to subscribe to; Let's Encrypt Service Statistics, why not? Also the Prossimo, which is their updates about their memory safety project. And Divvi Up is updates about our privacy-respecting metrics project. So five newsletters. To me, the two Let's Encrypt newsletters, the technical updates and the service statistics, especially the technical updates. I'd like to know, like, you know, when things are about to change. So I'm not yet moved to Let's Encrypt. I know that DigiCert offers ACME services; and so, you know, I'm a loyal kind of guy. I probably want to stay with DigiCert. But I know that, you know, Let's Encrypt is, what, 70% of the web now. And that's only going to grow as certificate lifetime basically forces people into automation. That's clear that that's where you have to go. Otherwise you just spend all your time messing with certificates. And that's also kind of a fraught process. So anyway, I've got a link at the top of page 2 of the show notes to this announcement page, which at the bottom of that announcement page is a form into which anyone can supply an email address with those five checkboxes to subscribe right there to any of those newsletters and update notifications. And again, as I said, makes a lot of sense to me. They basically removed email notification from their ACME API. It probably made sense in the beginning. It's proven, it's working, and now they're beginning to shorten these update intervals. So you end up getting spammed by your certificate provider because your certificates are having to get changed so often. So makes sense. Okay. We're not calling it, as I mentioned at the top of the show, Leo, a Windows "crash" anymore. No. To everyone's great relief, I'm sure, Windows will no longer crash. |
| Leo: Oh, what a relief. |
| Steve: No. However, Windows users may experience the occasional what Microsoft is now officially calling an "unexpected restart experience." And this of course puts me in mind of Space-X's term for when one of their rockets explodes on the launch pad. You may have heard this referred to as an "Unplanned Rapid Disassembly," that's the abbreviation URD. Sometimes it's known as the RUD, which is the Rapid Unplanned Disassembly, both referring to the same event. Also, the good news here is that Microsoft's infamous BSOD, beloved to all of us techies everywhere as the Blue Screen Of Death, well, it's changing its appearance, but fortunately not its abbreviation. They've changed the screen background color to black. So the official Unexpected Restart Experience will be unofficially the Black Screen Of Death. So we still get to call it the BSOD, those of us who have been around for a while. Newbies will be experiencing an Unexpected Restart Experience. Under the heading "Now it's easier than ever to navigate unexpected restarts and recover faster," in their Windows Experience Blog last Thursday Microsoft shared with us, they said: "A key trait of a resilient organization is the ability to maintain productivity and minimize disruptions. But when unexpected restarts occur, they can cause delays and impact business continuity." Wow. |
| Leo: Yeah. |
| Steve: Yeah, wow. "This is why we are streamlining the unexpected restart experience." So Leo, not only is it not going to be a crash, it's an unexpected restart, but it's going to be a streamlined... |
| Leo: Streamlined. |
| Steve: Yeah. |
| Leo: You'll hardly even notice it's happened. |
| Steve: Just go refill your coffee mug. "We are also adding quick machine recovery, a recovery mechanism for PCs that cannot restart successfully. This change is part of a larger continued effort to reduce disruption in the event of an unexpected restart." Well, the first time I read that, I thought, this sure sounds, you know, the PCs that cannot restart successfully sounds suspiciously like a response to that massive CrowdStrike outage that we all talked about, and many people, actually our listeners, experienced nearly a year ago. It was July 19th of 2024. So then Microsoft continues and makes that a little more explicit. They said: "The Windows 11 24H2 release" - which is the current one - "included improvements to crash dump collection which reduced downtime during an unexpected restart to about two seconds for most users." |
| Leo: They're not getting rid of the unexpected restarts. They're just making it faster. |
| Steve: Yes. It's streamlined. |
| Leo: Streamlined. |
| Steve: They're greasing it. "We're introducing a simplified user interface," you know, I saw it, it's a black screen with one line. Instead of a bunch of, you know, all that hex that bothered people, like what does that mean? |
| Leo: Yeah. Can't do anything with it anyway. |
| Steve: Should I be writing this down somewhere? |
| Leo: Exactly, yeah. |
| Steve: Yeah. I mean, that caused a great deal of angst. They said: "The updated UI improves readability" - I guess they made the type larger - "and aligns better with Windows 11 design principles" - oh, yeah, the type's definitely bigger - "while preserving the technical information on the screen for when it it's needed." Oh. "The simplified UI for unexpected restarts" - well, apparently they just removed the crash completely. They did a search and replace across the entire web, you know, environment, it's now unexpected restarts - "will be available starting later this summer on all Windows 11 version 24H2 devices." Now they get to the other part. "In the case of consecutive unexpected restarts, devices can get stuck in the Windows Recovery Environment, impacting productivity and often requiring IT teams to spend significant time troubleshooting and restoring affected devices." Right. Last July 17th, anyone? "This is where quick machine recovery," and that's just QMR for those of you who are keeping score with abbreviations - "quick machine recovery can help. When a widespread outage affects devices from starting properly, Microsoft can broadly deploy targeted remediations to affected devices via Windows RE, automating fixes with QMR and quickly getting users back to a productive state without requiring complex manual intervention from IT." In other words, Microsoft is now taking over next time something like CrowdStrike happens. And they will fix this in the field through their recovery environment, through some mechanism, which they're not going into any greater detail at this point. So what we definitely have is Microsoft's response to, and solution for, last year's massively widespread CrowdStrike event. Which is, you know, just good news. They conclude, writing: "We are excited to announce QMR will be generally available this summer, together with the renewed unexpected restart functionality. QMR supports all editions of Windows 11 version 24H2 devices. It is enabled by default for Windows 11 Home devices; IT admins will be in full control and can enable it" -and I would imagine should - "by default for Windows 11 Pro and Enterprise. Later this year, Microsoft will release additional capabilities for IT teams to customize QMR." So yay. We have quicker recovery from those "unexpected restarts," the tired old blue screen is turning black, and the response to preventing another widespread CrowdStrike-like event coming from Microsoft, which is all great. Now, as I'm sure every one of our listeners knows, because it's a date of great fascination, a very important and interesting date is creeping toward us. Microsoft has previously announced that they will stop providing free access to many more years of otherwise available Windows 10 security updates - meaning fixes for their own software mistakes - but that up to three years of updates can be purchased from them. So now we'll be paying Microsoft to cure the vulnerabilities that they have left behind in Windows 10. Of course, normally we could just upgrade to Windows 11. The only problem with that is that, despite the fact that any machine that's able to run Windows 10 can run Windows 11 - after all, Microsoft tells us that Windows 11 is faster and more efficient than Windows 10, so it would run better on the same hardware. But Microsoft long ago arbitrarily decided to attempt to force their Windows 10 users to abandon their existing perfectly working hardware by setting higher machine requirements for Windows 11 than for Windows 10. Anyway, I know I'm a broken record on this, but this just feels so wrong to me. But here we are today with the end of service life of Windows 10 approaching steadily, while more than half of all Windows systems remain running Windows 10, even though 11 has been available now for quite some time. How can that be? Well, it must either be that Windows 10 users do not want to upgrade, or cannot upgrade. But this leaves Microsoft with a practical problem. As it is, it appears that somewhere around half a billion PCs are just going to keep right on running Windows 10, even after Microsoft deliberately terminates support for Windows 10. And that's not a good look for Microsoft because it's their own software security bugs that they are saying they refuse to patch for somewhere around half a billion PCs. They have those patches ready to go, since they will be selling them to those who are willing to pay. But just not to everyone else who is equally deserving and will become increasingly vulnerable over time as new Windows 10 zero-days are being discovered in the unmaintained Windows 10 code base. So it wasn't too surprising when we received the news last Tuesday the 24th that Microsoft had blinked and figured out a face-saving way of punting on the termination of patches, at least for the first year of patch outage. Here's what Microsoft wrote last Tuesday. Under Extended Security Updates for Windows 10, they said: "For individuals: An enrollment wizard will be available through notifications and in Settings, making it easy to enroll in ESU (Extended Security Updates) from your personal Windows 10 PC. Through the enrollment wizard, you'll be able to choose from three options: First, use Windows Backup to sync your settings to the cloud at no additional cost." That's literally one of the choices. And if you do that, you get extended security updates. Or, two: "Redeem 1,000 Microsoft Rewards points. And then you get extended security updates for no additional cost. Or, three, if you don't want to do either of those, you don't want to use Windows Backup, you don't want or don't have 1,000 Microsoft Reward points, you can then pay $30 U.S. for extended security updates for Windows 10." Then they said: "Once you select an option and follow the on-screen steps, your PC will automatically be enrolled. ESU coverage for personal devices runs from October 15th, 2025, when it would otherwise have expired, that is, when Windows Updates would have expired for that machine, through October 13th of 2026." So you get a year. "Starting today," they said, "the enrollment wizard is available to the Windows Insider Program and will be rolling out as an option to Windows 10 customers in July, with broad availability expected by mid-August." So by middle of next month everyone's Windows 10 machine should have been updated. There will be a wizard available to allow you to follow those steps. In other words, if you agree to use Windows Backup to sync your settings to Microsoft's cloud, you'll be entitled to the free year, first year of ESU at no charge. Or, if you somehow have 1,000 Microsoft Reward points accumulated you can... |
| Leo: I have 58,000 accumulated, so I'm set. |
| Steve: Baby, you can upgrade everybody you know. |
| Leo: Ironically, I don't have any Windows 10 machines. But if I did... |
| Steve: Exactly. |
| Leo: ...I'd be set. |
| Steve: Now, I just checked when I was writing this yesterday, and I somehow have earned 1,944 points despite using Edge and Bing as little as humanly possible. But I do recall that I did give Edge a try for a while. I was seduced by its support for vertical tabs. But it did something that broke something, or something didn't work, which moved me back to Firefox. So perhaps while I was there I racked up some Microsoft Brownie points. But anyway. |
| Leo: It's easy to do. |
| Steve: I'll be glad to use them to keep the updates flowing, you know, because I'm sure as heck not paying Microsoft $30 just as a matter of principle. And actually... |
| Leo: That first option's interesting. What is it? I don't get it. |
| Steve: I know. It's basically, well, we're going to make you do something so that it's not really free. |
| Leo: It's not free. You still... |
| Steve: And Leo, I don't know how much time you spend, like, messing around with Windows. But they are pushing this backup. Like, it is weird. |
| Leo: It's just settings; right? It's not like hundreds of gigabytes or something. |
| Steve: No. Well, and that's what I don't know. They're saying Windows Backup to sync your settings. Why do they want to sync my settings? Is it so that if I, like, between different Windows machines, I guess? |
| Leo: Yes. So, yeah, every machine you install. They used to do that as a matter of course. |
| Steve: They are really, anyway, they're pushing this cloud backup thing. I know that every time one of my Windows 10 machines gets a big update, it resets that Windows 10 setup. And I again need to tell it, I need to tell Microsoft that, no, I don't want to synchronize Windows with my Android phone, which I don't own. I'm forced to decline some Xbox nonsense, and then fight them not to have them back up my machine to the cloud, and thank you very much. |
| Leo: It's just... |
| Steve: So, yeah. In any event, Windows users who have a Microsoft account can open Edge, just as I did, and click their icon or picture in the upper right. You'll see a dropdown showing your current Microsoft Rewards points on the little panel. If you've got more than a thousand, you should be able to cash them in, or just let Microsoft sync your updates, if you haven't already. Maybe if you already have, you know, you don't even have to go through all this. I don't know. It'll be interesting to see how this goes. Anyway, it was kind of a - it was a slick trick. Microsoft basically has decided, whoops, we can't just make people pay $30. Not half a billion Windows 10 machines which we're telling people they can't upgrade to Windows 11. So they did blink. |
| Leo: They blinked. |
| Steve: Yeah. |
| Leo: It's probably some tax thing, like they can't give it away, so they have to make you do something. Just some silly thing. |
| Steve: I just think that, you know, a year ago they figured they were - Windows 10, oh, Leo, have you seen those rounded corners on the dialogs? You have to have those. It's a whole different experience. And the menu in the bottom center of the screen? Oh, it's so much better than that stinky old Windows 10 when it was over on the left. So, oh, and those shadows, they're much better shadows than we had under 10. So really, who would not want 11? And Leo, it's a bigger number. By just adding one. |
| Leo: I decided, you know, there is - it just hurts in general that perfectly good hardware, it's worse with phones than it is even with computers, but perfectly good hardware is obsoleted, not because the hardware is in any way obsolete or malfunctioning, but because they want to make more money. |
| Steve: They're telling us 11 is faster and more efficient. Well, so, it should run better. Yeah, it should run better on the same hardware that Windows 10 did. |
| Leo: Oh, yeah. Yeah, good point. |
| Steve: So let me have it. And then of course we know we have Rufus, where you're able to select some checkboxes telling it to remove the TPM check and other things. And it works just fine on that stinky old hardware. |
| Leo: Most people, you know, normal people probably wouldn't. |
| Steve: But, no. But it does, it completely... |
| Leo: Tells you. There's no technical. |
| Steve: ...unmasks the emperor that's, gee, you know, what's that hanging out there in the breeze? |
| Leo: I decided, I don't know, this might be crazy, but I decided I'm going to get a Linux box with maximum capability so that it'll maybe outlast me, you know, for the last 10 or 15 years. And then thin clients everywhere. And I'll have one computer for the whole house. I've got Ethernet everywhere. I've got networking everywhere. And just use thin clients. I mean, I'll probably just use the whatever laptops I've got until they wear out, and then I'll replace them with thin clients. So I have one PC, it's running Linux so I don't have to worry about this folderol. |
| Steve: When I remote into - we have so much bandwidth now, when I remote into GRC's desktops at Level 3... |
| Leo: Like they're local. |
| Steve: I forget, I mean, I just, like, I forget that I'm not using the computer whose fans are spinning. |
| Leo: Exactly. Exactly. Yeah, well. Yeah. |
| Steve: Let's take a break. |
| Leo: Okay. |
| Steve: And then we're going to talk about what Russia is doing with Apple, and what is RuStore? |
| Leo: Incidentally, you are still freezing. Not as frequently, but the freezes are still there. |
| Steve: Okay. I have one more thing I can fix. I will deploy... |
| Leo: It isn't as frequent. That's the good news. But just a second ago you froze like this. |
| Steve: No, not a good look. I'll try to talk with my mouth closed, and that way I won't... |
| Leo: Freezes never are a good look. That's just the way it is. All right. We're going to have more with Steve Gibson and Security Now! momentarily. All right. Let's continue on, Mr. Gibson. |
| Steve: Okay. So an article on the Russian Izvestia site published last Wednesday has the headline "Apple of contention: The State Duma ordered Apple to install RuStore on devices." And for those not well versed in Russian government structure, as I was not, the State Duma is the lower house of the Federal Assembly of Russia, which is the national legislature of the Russian Federation. It's similar in function to other lower houses of parliament in bicameral systems. The article said: "State Duma deputies have ordered the American corporation Apple to install the unified Russian RuStore app store on their devices when selling in Russia. Deputies of the State Duma in the second and third readings adopted a law that, from September 1st, 2025" - so this coming September 1st - "will prohibit Apple and other manufacturers of technically complex products from restricting the installation and use of the Russian RuStore app store on smartphones and tablets sold in Russia. "The law obliges devices to provide the ability to install, update, and pay for applications through RuStore, and also prohibits blocking programs from third-party sources and imposing restrictions on payment methods and pricing policies." Basically, you know, they're going to require Apple to open their phones for RuStore-based apps with no say over what the RuStore is able to contain. They wrote: "These measures are aimed at combating what they're calling anti-competitive practices of foreign companies, primarily Apple and Google, which restrict access to domestic services. The parliamentarians propose to make it possible to install the Russian RuStore app store on devices sold in Russia and purchase and install applications from domestic developers through it. "iPhone owners in Russia will be able to install apps not only through the App Store, but also through RuStore, a single Russian app store. This will affect banking programs, messengers, games, and other services developed by developers from the Russian Federation. In addition, Apple will be prohibited from limiting the functionality of such applications or blocking payment transactions within them." Boy, this is a big change, of course, from the way it's traditionally been. "Some applications are already installed in gadgets by default. Therefore, as Aleksey Govyrin, a member of the State Duma Committee on Small and Medium-sized Enterprises, explained to reporters, the new law is aimed at ensuring that no one can restrict the operation of these programs or prevent them from installing others through the Russian RuStore store. Not only applications are affected, but also their functioning, namely updates, user interaction, available settings, and allowed payment methods. "If the device blocks the operation of applications from RuStore or interferes with their use, this will be considered a defect in the product, giving the right to a replacement, repair, or refund. Thus the law removes hidden barriers for Russian applications on foreign gadgets sold in Russia. According to data at the end of 2024, RuStore surpassed the App Store audience in Russia in terms of the number of users. The store was installed on 80 million devices. Currently, RuStore is available on all Android devices, while iPhone users are prevented from doing so due to Apple's policy. The new law aims to eliminate this disparity and ensure the same conditions for all users, regardless of platform. At the same time, the law does not provide for a ban on the sale of iPhones in Russia. Its purpose is to create fair competition, not to limit consumer choice. "Anton Gorelkin, first deputy chairman of the IT Committee of the State Duma and Chairman of the Management Board of ROCIT, expressed confidence that Apple would comply with the requirements of the new law on pre-installing the Russian RuStore app on its devices. According to him, the company has all the technical capabilities to integrate RuStore, as well as an obvious desire to maintain its presence in the Russian market." And Leo, I'm very interested in what you think this means. I mean, will they do it? Will Apple... |
| Leo: I don't think the Russian market is huge for Apple. In fact, I'm trying to remember, I don't know how much they play in the Russian market. |
| Steve: As opposed to Android. |
| Leo: Yeah. I'm trying to remember. I guess they are still a presence, but it's a small percentage of their business. |
| Steve: So you think they just might blow it off? |
| Leo: They could easily do that. They certainly don't want to install a third-party app store, although the EU is making them do that. |
| Steve: That was my point, was I was wondering whether these barriers are beginning to crumble. |
| Leo: Yes. |
| Steve: And Apple's just having to capitulate. |
| Leo: Every country is doing it; you know? It might be just the way it is with Apple, yeah. |
| Steve: In which case maybe they're just going to go, well, okay. We'd rather have what we can get. |
| Leo: If I were Apple, I'd just install it. They have a perfect out. They have to obey the laws of the land. And if it's a law they have to install RuStore, they're going to install RuStore. |
| Steve: Yeah. In a little bit of follow-up, I did some digging around. Apparently some phone-selling Russian retailers worry that forcing mandatory RuStore pre-installation might undermine iPhone sales, interestingly enough... |
| Leo: Oh, yeah. |
| Steve: ...and potentially push Russian buyers toward grey-market imports, which are unaffected by the law. |
| Leo: That's a good point. That's a good point. It happened in China, yeah. |
| Steve: Because they don't trust their own government. |
| Leo: That's a very good point, yeah. They don't want the RuStore. |
| Steve: Right. Because that means, you know... |
| Leo: Because honestly, it might not even be a store. It's probably just spyware. |
| Steve: Right. |
| Leo: Right? Doesn't, I mean, who cares about the store? I just want to get an app on the phone. |
| Steve: Right. |
| Leo: Right? |
| Steve: So the French city of Lyon, which is France's third largest city by population, has announced its intention and plans to migrate away from Windows solutions as part of a push for digital sovereignty. Following other such efforts throughout Europe that we've talked about previously, Lyon plans to replace Windows with Linux, Office will be replaced with an open-source alternative called OnlyOffice, and MS SQL with PostgreSQL. Lyon will be joining the Danish cities of Aarhus and Copenhagen in their work to replace U.S. tech products with open-source alternatives. And the European Union itself, as a whole, it turns out, is looking to migrate away from Azure to an EU-based cloud provider. So Leo, as you just said, the world, she is changing. And, you know, countries are saying, wait a minute. I think what's happening is initially all of this tech stuff seemed like magic. And so governments didn't want to mess with it. They didn't understand it. They're like, oh, well, we don't know what to do. You know, this is just this is all very high-tech. But once you get comfortable with it, it's like, wait a minute. Why can't we just say we want this? And then, you know, the legislators do that. So, yeah. This next update I'm going to share further supports the observation that we are in the process of witnessing the comparatively rapid end of the use of non-memory-safe languages, especially in areas where bureaucracy reigns and the specification for a commercial system's implementation language can be created and enforced. We talked about this not too long ago because this is not a passing fad, and it's not going away. In other words, the days of authoring code in C and C++ when maximum security is required - and really these days when is it not required? - those days are coming to an end. There are two primary facilitators of this change. The first is that our appreciation for the historical troubles we have had as a consequence of the use of with non-memory-safe languages has been maturing. The statistics don't lie, and they do serve to indict non-memory-safe languages as being the primary underlying cause for these problems. The second nail that's being pounded into the coffin of non-memory-safe languages is the development of truly fantastic and increasingly well-proven fully memory-safe languages. You know, it wouldn't mean much to say "You cannot use C or C++ anymore" if there weren't terrific alternatives. But the likes of Rust, Go, Java, C#, Swift, Kotlin, and Python are showing that the only reason C and C++ are still being used today is inertia. It's true there are many forms of inertia. There's training-base, knowledge-base, code-base, experience-base, library-base, and others. But inertia, being inertia, is an insufficient justification and rationale, and it's ultimately going to lose. Anyone starting out today would be well advised to pick up and begin using a language of the future, rather than any language of the past. So here's what the joint announcement from CISA and the NSA said. And I chose, because they co-publish these, I chose the NSA's instance. So "FORT MEADE, Maryland - The National Security Agency and the Cybersecurity and Infrastructure Security Agency (CISA) have released a joint Cybersecurity Information Sheet (CSI) to highlight the importance of adopting memory-safe languages (MSLs) in improving software security and reducing the risk of security incidents." They said: "Memory safety affects all software development and is a critical aspect to a holistic approach to security. Adopting MSLs (Memory Safe Languages) will directly improve software security for all. "The CSI, titled 'Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development,' details these various benefits of MSLs, citing several examples and case studies, and highlights the additional advantages that MSLs bring to reliability and productivity. Reducing memory-related vulnerabilities is critical; and the consequences of not addressing memory safety vulnerabilities can be severe, including data breaches, system crashes" - or unexpected restarts - "and operational disruptions. "MSLs incorporate built-in mechanisms, such as bounds checking, memory management, and data race prevention, to guard against various memory bugs and vulnerabilities. Without these safeguards, such weaknesses could be exploited by malicious actors. By embedding these safety features directly at the language level, MSLs prevent memory safety issues from the outset. "The authoring agencies" - meaning NSA and CISA. "The authoring agencies urge organizations to consider whether adopting MSLs is practical for their circumstances, and provides adoption approaches and engineering considerations to ensure effective implementation of MSLs into their software. MSL adoption does not require existing code to be completely rewritten" - and I'm a little skeptical about that, but okay - "and the report provides guidance to leverage interoperability to integrate with existing codebases. Further..." |
| Leo: If you have unsafe codebase, it doesn't matter if the new stuff is safe. |
| Steve: Yeah, yeah, I think, what? Okay. |
| Leo: Maybe AI can just rewrite all that. |
| Steve: Actually, I have to say, Leo, I confess when I thought, how could it not need to be rewritten, it's like, oh, let AI rewrite it and screw it up so that you never know what's going on. |
| Leo: I don't know where the memory's going. |
| Steve: That's right. They said: "Further, the report also details ways non-MSLs can be made safer in cases where adopting an MSL is not practically feasible." Then they finish: "To strengthen national cybersecurity and reduce memory vulnerabilities, software producers, especially those for National Security Systems (NSS) and critical infrastructure, should utilize this guidance to plan for and begin using MSLs for their software systems." Now, I've got a link in the show notes to the full report. I'm not going to go into it now because we've talked about this, you know, extensively. It's a 19-page PDF. We know about use-after-free vulnerabilities, buffer overflows, and dangling pointers. But this official government document contains very compelling charts and terrific historical data which makes an extremely strong case for the use of memory-safe languages. So if there's some "higher up" that our listeners, any of our listeners need to convince that this is what the company, their enterprise should do, printing and dropping this document on their desk might do the trick. |
| Leo: Or just give them a clip of this show. Problem is, if you have a giant code base, like, say, I don't know, Microsoft, written in C and C++... |
| Steve: I know. |
| Leo: That's challenging. |
| Steve: Although we know that Microsoft is beginning to reimplement in Rust. And they're finding, you know, no speed degradation, and dramatic improvement in safety and security. |
| Leo: Is Java memory safe, or Java... |
| Steve: It is. It is. |
| Leo: It is. How about Java - it has garbage collection, doesn't it. How about JavaScript? |
| Steve: I wouldn't call JavaScript, not really call it a language. You know, it's... |
| Leo: I do want to point out that Common Lisp is memory safe. If you wanted to use Common Lisp, I know where to get it. |
| Steve: Don't use Common Lisp. |
| Leo: Okay, fine. Fine. Is assembly language memory safe? |
| Steve: No. |
| Leo: Fine. |
| Steve: No. And in fact in the show notes I said, as I've suggested before, what today is a recommendation and a suggestion is 100% guaranteed to become a requirement for any and all future government purchases. |
| Leo: Probably true, yeah. |
| Steve: Probably federal, state, and even local. So the time to develop expertise in memory-safe coding alternatives is now. And I finish by writing: "It's clearly foreseeable that before long, driven by growing concerns over security, C and C++ will be joining Assembly language in the dustbin of coding history." |
| Leo: I doubt it, but okay. If you say so. |
| Steve: So I love C. |
| Leo: It should. I'm sure there is a way to add type checking to C and make it memory safe. |
| Steve: Assembler has type checking. I use a strongly typed assembler. |
| Leo: Okay. |
| Steve: It catches mistakes for me all the time. |
| Leo: It's kind of to prevent malloc and strcpy and things like that. |
| Steve: Oh, you can still get in bad, bad trouble. I mean, it's, you know. I mean, and I think the problem is throwing a newbie into the deep end with C or... |
| Leo: Look at these pointers. You can access anywhere in memory. |
| Steve: You can just get yourself so tangled up. So newbies should start off with a Rust language, you know, like use Rust. And only if you really, really, if you've paid your dues, if you understand the use of synchronization objects, and you really, really understand what you're doing, then yeah. I mean, again, the problem is mistakes happen. There's no arguing that using a memory-safe language prevents those mistakes, prevents even the guru from missing something when they were, you know, decaffeinated or didn't have enough sleep, they were trying - they were rushing to reach a deadline and so, you know, forgot to update their regression tests. |
| Leo: I can promise you that these companies are not going to abandoned these ancient code bases. They're going to adopt band-aids like link checkers that look for memory leaks and things like that. |
| Steve: Leo, COBOL is not on the list, only because it's been forgotten about. |
| Leo: It's memory safe, though. |
| Steve: It's still in use. It's still in use. |
| Leo: Isn't it memory safe? I think it is. |
| Steve: Oh, no. No way. |
| Leo: No? |
| Steve: No. |
| Leo: It's not high - it's too high level a language to... |
| Steve: It may be because basically you write, would you please consider adding these two variables. |
| Leo: Exactly. Exactly. |
| Steve: And the compiler [crosstalk]... |
| Leo: I'm sure Fortran is not memory safe. I'll guarantee you Common Lisp is because you just don't have access to memory in that way. I don't know. It's got garbage collection in it. I don't know. |
| Steve: I'm tempted to say anything that's built on top of sort of a generic, you know, LLVM is probably going to be safe. |
| Leo: Probably safe. |
| Steve: Because it's going to have garbage collection, and it's going to be managing your allocation and so forth. Although a lot of the fancy languages have a lot of support for... |
| Leo: Do-it-yourself memory allocation? |
| Steve: Garbage collection and counting references and dereferences and so forth. |
| Leo: Yeah, yeah. |
| Steve: Okay. It's time for another break. Then I can't wait to tell you about this new AI scanner evasion technique. You're just not going to believe it. It's so - the idea that this could work just is going to make your head explode. |
| Leo: Is AI memory safe? No. |
| Steve: Not for them. |
| Leo: On we go with the show. I want to hear about this scanner evasion. |
| Steve: Okay. Now, I'm not making this up. |
| Leo: Okay. Okay. |
| Steve: This is hard to believe, but it's true. Cybersecurity researchers at Checkpoint, we know them, they're the real deal, you know, and we're nowhere near April 1st, so really. |
| Leo: Okay. I believe you. |
| Steve: They discovered a malware strain that actually embedded AI prompt injections into its code in an attempt to evade detection by gullible AI-based malware scanners. |
| Leo: Oh, my god. |
| Steve: Which are apparently a thing now. Okay. It's difficult to share this news without chuckling; but, okay, it's true. The malware attempts to instruct AI scanners by putting into their code "ignore all previous instructions" and return a "no malware detected" result string by literally, I mean, they're literally placing those prompts into the code. And I have to say it occurred to me that this detection evasion should be known as the "These are not the droids you're looking for" method. But this really happened. So they literally, they assume that gullible AI will see "ignore all previous instructions" and return a "no malware detected" and obey those commands. So the malware itself is no joke. It opens Tor-based backdoors on infected Windows systems. So nobody wants to get this on their computer. But I'm amazed if AI-based malware scanners are going to see that and go, oh, whoops, I guess this is okay. These are not the droids we're looking for. Checkfirst reports on a new Kremlin-backed propaganda campaign. Their headline was "Operation Overload: An AI fueled escalation of the Kremlin-linked propaganda effort." Their reporting is not very long. They wrote: "The Russian propaganda operation targeted at media organizations and fact-checkers is still going strong. Operation Overload, which we first documented," they wrote, "in June 2024," so a year ago, "is now leveraging AI-generated content, impersonation techniques, and is expanding to more platforms such as TikTok and Bluesky. Telegram and direct emails to newsrooms remain a daily dissemination technique used to attempt to create a sense of urgency among their targets. Since we last published an update about the operation last September, some legitimate outlets regularly fall in the trap," they wrote. "This latest report is the third in a series published by Checkfirst and Reset Tech, offering a deeper, sharper analysis of one of the most sophisticated current propaganda operations targeting Western democracies. Building on findings from our previous investigations," they said, "the new edition reveals an alarming surge in both volume and complexity of coordinated false content. "Since September '24, we've recorded over 700 targeted emails and nearly 600 unique pieces of falsified content disseminated across platforms including Telegram, X, Bluesky, and most recently now TikTok. This material, often AI-generated or deceptively edited, impersonated renowned individuals or media brands, using the identities of over 180 people and institutions to sow confusion, manipulate debate, and overload fact-checkers. Our latest findings further document techniques faking the voices and identities of journalists, public figures, and respected institutions, complete with counterfeit logos and branding. "Telegram continues to serve as the campaign's central distribution hub, but the disinformation now circulates more widely through hired amplification networks on X, fake media personas on Bluesky, and viral engagement-farming content on TikTok." Because, you know, Leo, the more places you see it and the more often it's seen, the more it's true. Right. Anyway, they said... |
| Leo: Especially if you see it on TikTok, yes. |
| Steve: Oh, well, it's on TikTok. |
| Leo: That's got to be true. They can't lie on TikTok, I think. |
| Steve: They said: "At the heart of the campaign lies a focused effort to interfere in elections and the wider political landscape in Ukraine, France, Germany, and most recently Poland and Moldova. The increasing use of AI-generated content is a sign of the adaptation of operatives to a wider available toolset" - and everyone of course saw this coming; right? We knew AI was going to get involved - "in an effort to sow even more confusion. Despite previous warnings and growing evidence, platforms' responses remain worryingly uneven. Bluesky has taken action against the majority of accounts involved, while X continues to underperform in enforcement and risks non-compliance with the EU's Digital Services Act (DSA)." They said: "We call for urgent platform accountability, especially from X, which is legally bound under the DSA to mitigate systemic risks, yet continues to host clearly illegal content. We also encourage impersonated individuals and organizations to exercise their rights and demand action via formal reporting mechanisms. We urge journalists and fact-checkers to be wary of inadvertently amplifying falsehoods by reporting on isolated fakes. When discussing misleading content linked to Operation Overload, we encourage them to always provide clear context and flag the broader campaign behind it. Without decisive intervention from platforms, regulators, and civil society, the integrity of public information - and of our elections - remains under threat." In other words, "why we can't have nice things." And I was thinking about this. You know, some of the stuff that we share on this podcast can be somewhat depressing. I'm not generally upset by the abuse of techie stuff, I guess, since it feels as though it's science and math, and it is inherently tractable. You know, we can understand the root causes of use-after-free vulnerabilities and fix them. We can block ports to vulnerable services, and that's that. But the abuse of social media platforms to deliberately confuse and dilute the truth, and to flat-out fabricate to deliberately hurt other trusting participants seems to me, I don't know, it's inherently slippery and intractable. You know, there's no port we can block. So it just - I guess I feel sad that this is how our beautiful technology is being abused. |
| Leo: Yeah, yeah, I agree with you. |
| Steve: Because, you know, the techies created all this to be great, and it's, you know. On the other hand, I guess it just demonstrates that it's become, it's gone mainstream, and this is what happens to things that go mainstream is everybody gets to use it for their own purposes, good or bad. Okay. So I wanted to give everyone a heads-up about, believe it or not, another recent pair of very, very bad, as in 9.8 and 10.0, I mean, let's not take these numbers lightly; right? I mean, this is like, really, this is house-on-fire level CVSS scores. And these are Cisco remote code execution vulnerabilities, again. |
| Leo: Nice. |
| Steve: I know. Cisco's own disclosure from their site, which is what I quoted from, describes CVE-2025-20281 as a "Cisco ISE API Unauthenticated Remote Code Execution Vulnerability," where they write: "A vulnerability in a specific API of Cisco ISE and Cisco ISE-PIC could allow an unauthenticated remote attacker to execute arbitrary code on the underlying operating system as root. The attacker does not require any valid credentials to exploit this vulnerability. This vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vulnerability by submitting a crafted API request. A successful exploit could allow the attacker to obtain root privileges on an affected device." And that one was the CVSS 9.8. The 10.0 is successively numbered, so it's 20282, which Cisco describes as "Cisco ISE API Unauthenticated Remote Code Execution Vulnerability." And for that one they write: "A vulnerability in an internal API of Cisco ISE and Cisco ISE-PIC could allow an unauthenticated, remote attacker to upload arbitrary files to an affected device and then execute those files on the underlying operating system as root." Yikes. "This vulnerability is due a lack of file validation checks that would prevent uploaded files from being placed in privileged directories on an affected system." In other words, you can put any file the attacker wants anywhere they want, including privileged directories. "An attacker could exploit this vulnerability," they write, "by uploading a crafted file to the affected device. A successful exploit could allow the attacker to store malicious files on the affected system and then execute arbitrary code or obtain root privileges on the system." In both cases, as ever, and as before, Cisco has released software updates to address these problems, and they note that there are no workarounds to suppress or disable the vulnerability. Now, I'm quite certain that I beat up on Cisco enough last week to have driven my point home and for that to last for a while. But it's worth noting that here we have two new fresh critical 9.8 and 10.0 remote access complete root-level system takeover vulnerabilities that are only catastrophic because anyone in the world, anywhere in the world, is able to access any of these systems that may be exposed to the public Internet. The most important point from last week's rant was that this is absolutely never necessary. It could never be a problem if Cisco demonstrated the wisdom to never allow any wide-open source IP access. There's just no need for it. Last week we examined a different pair of vulnerabilities which have been widely exploited by Chinese attackers to infiltrate our networks pervasively. We first covered the news of one of those two vulnerabilities 18 months before. So here we are again today, with another pair of potentially catastrophic vulnerabilities, and Cisco's advice is to please read their optional device hardening guide. How long will it be before we're learning that these two new critical vulnerabilities remained largely unpatched in Cisco's deployed gear, despite the availability of free software update patches, and that once again more systems have fallen to attackers as a result? When will this cycle of mistake and attack change? No matter what Cisco does today, I understand, no matter what they do today to improve their policies, the effects will take a decade or more to finally percolate throughout the world. There's a long legacy tail for these devices. But if they don't start getting it right now, it will never change. I just don't know what they could possibly be thinking, when they could fix it now, and they still don't. |
| Leo: Yeah. I don't get it, either. They need a giant fine. |
| Steve: Yeah, yeah, exactly. I mean, they're just saying, oh, well, everybody has problems. We've responsibly fixed the problem. But as I made very clear last week, that's not good enough. |
| Leo: Yeah. |
| Steve: With the fact that we, I mean, we're seeing the proof, the evidence, that it is not good enough. Saying here's a patch for the mistake, the patches aren't getting deployed. And so their customers are being infiltrated by Chinese threat actors. So yeah, saying, oh, well, you know, we made a patch available, and we have a hardening guide, and everyone should do that, it's like, is there more they could do? Yes. They could make it impossible for anyone in the world to access those APIs, which only select sources should be able to possibly access. But they don't. You know, they're not doing enough. They're not doing all they could. And so I think you're right, Leo, they need to be held accountable at a higher level. We need to change the standard because the current standards are obviously not enough. And here again, 9.8, 10.0, oh, updates available. How many people are going to, you know, do it? |
| Leo: Yeah. |
| Steve: So I'm sure that all of our U.S. domestic listeners are aware that I keep politics out of this podcast. That doesn't require much work on my part for the simple reason that politics for its own sake would be off topic for us. No one comes here to listen to my opinion about the state of the U.S. political scene. This is a podcast about security and privacy and the interesting technologies that surround those topics. That said, earlier this year our newly elected U.S. President Donald John Trump let loose the world's richest man, Elon Musk, upon the federal government with the charter to find and eliminate as much waste, fraud, and abuse as he could find, anywhere and everywhere he believed it existed. This was a process unlike anything this country has ever seen before. Generally and historically, our political leaders appear to be so stuck that nothing is ever really able to change. There's also a well understood tendency for bureaucracies to grow without limit, as individuals at the tops of departments always ask for larger appropriations because with a larger budget comes increased political power and sway. So it might be that within this chronically calcified environment, Trump's deliberate strategy of turning a bull loose in the china shop was the only way to effect change. And it's undeniable that many things were changed almost overnight. Lots of people are happy that happened, just as plenty of others believe that it was insane and reckless. I'm a citizen spectator, and all I can really say is that it's been quite a show so far, and that I'll be interested to see what all comes of this. The one area of the functioning of our government that is of direct bearing to this podcast is the effects that these events have had on the U.S.'s preparedness, cybersecurity defense, and posture. As might be expected, anytime staffing is significantly cut back, there's at least a disruption, at the very least, while the survivors and their management wait to see what's coming next and then begin to rejigger their new resources to figure out how to hopefully get the most important work done with the resources that they now have. It's for this reason that I decided to share last Wednesday's reporting from an organization we've quoted in the past, Cybersecurity Dive, about the effects so far and at this stage of that inevitable "rejiggering" effort. As might be expected, things seem a bit hectic on the ground at the moment. Their report's headline was "Suspended animation: U.S. government upheaval has frayed partnerships with critical infrastructure," and their subhead reads: "Recent federal cuts, reorganization, and other disruptions have alarmed industry leaders, who say the government is a less reliable partner even as cyberthreats increase." So here's what their interviews with many people involved on the ground and their reporting found. They wrote: "The Trump administration's chaotic overhaul of the federal government has seriously weakened the public-private partnerships that protect U.S. critical infrastructure from cyberattacks and physical disasters. Massive workforce cuts, widespread mission uncertainty, and a persistent leadership void have interrupted federal agencies' efforts to collaborate with the businesses and local utilities that run and protect healthcare facilities, water treatment plants, energy companies, and telecommunications networks, according to interviews with 14 representatives of those four critical infrastructure sectors, four former senior government cybersecurity officials, and multiple infrastructure security experts. "Government leaders have canceled meetings with infrastructure operators, forced out their longtime points of contact, stopped attending key industry events, and scrapped a coordination program that made companies feel comfortable holding sensitive talks about cyberattacks and other threats with federal agencies. 'The partnership is in suspended animation,' said a healthcare industry representative who, like most others interviewed for this story, requested anonymity to discuss sensitive matters. 'The partnership, at the end of last year, had reached a level of maturity that was promising, and now that's all been pulled back.' "The result, experts and industry officials say, is reduced trust between the public and private sectors, a diminished understanding on each side of the other side's needs and concerns, a declining capacity to plan for future attacks, and a growing national vulnerability to debilitating hacking campaigns all at a moment when the Trump administration's intervention in Israel's war with Iran has raised fears of retaliatory Iranian cyberattacks on U.S. critical infrastructure. 'We're seeing something unprecedented in cybersecurity, a government deliberately deciding to disinvest in its capabilities,' said Michael Daniel, the president of the Cyber Threat Alliance, who served as President Barack Obama's cybersecurity adviser. 'I don't see how this retrenchment can do anything other than make us worse off.' "Nation-state hackers and cybercriminals have repeatedly breached and sometimes disrupted U.S. critical infrastructure in recent years, including in key sectors of healthcare, energy, water, and telecommunications. These intrusions have heightened fears about companies' readiness to withstand more serious attacks, as well as underscoring the urgency of government efforts to assist them. But under the Trump administration, agencies' engagements with their critical infrastructure partners have varied widely, with some conversations continuing while others have almost entirely stopped. "The Department of Homeland Security's elimination of the Critical Infrastructure Partnership Advisory Council (CIPAC) framework in March has been the most seismic disruption. CIPAC allowed government and industry representatives to discuss sensitive cybersecurity information including about companies' security vulnerabilities without meeting standard transparency requirements that would expose that information to the public. Without CIPAC, critical infrastructure operators have dramatically reduced their sensitive cyber conversations with the government, according to a wide range of industry representatives, all of whom described the dissolution of CIPAC as disastrous. The absence of CIPAC 'creates this big fear' and poses 'a huge risk' for companies that want to share cyberthreat information with the government, said an industry representative in the energy sector. 'There's that doubt of are we sharing too much?' "CIPAC's demise forced the telecommunications sector to suspend or modify several projects it was working on with the government, causing a significant impact, according to a communications sector representative. The sector had to take on more responsibility for an Internet routing security initiative previously led by the White House, pause research on artificial intelligence-powered threat intelligence, and freeze a collaboration with the National Security Agency on nation-state attacks. The interruptions come as telecom companies reel from China's Salt Typhoon campaign of extensive and alarming intrusions into their networks. "Federal agencies are working on a replacement for CIPAC that would broaden the range of private-sector participants in meetings, according to multiple industry figures, who said it was urgent that the government launch that replacement as soon as possible. The oil and natural gas industry is currently refusing to share the products of its cyber working groups with the government 'until we are assured that we have those CIPAC protections,' according to an energy industry representative. In the meantime, the industry canceled its spring meeting with the government because companies didn't know what they'd be able to safely share. Sector leaders have scheduled another meeting in anticipation of a CIPAC replacement; but if that fails to materialize, the industry doesn't expect cyber conversations with the government at that meeting to be very productive. "DHS declined an interview request for this story, and the department did not respond to a question about the CIPAC replacement. The Trump administration's changes have also undermined some cyber information sharing, the cornerstone of the public-private partnership keeping critical infrastructure safe from hackers. "Because the private sector operates most critical infrastructure, it knows more than the government does about how that infrastructure works, what cyberattacks are occurring against it, and what the impact of a successful intrusion would be, according to John Riggi, the National Advisor for Cybersecurity and Risk at the American Hospital Association and a former FBI cyber partnership official. The industry, in turn, relies on the government to supply both unique foreign intelligence and cyberthreat information for which it would otherwise have to pay private firms. Small infrastructure operators with threadbare security budgets are especially dependent on this free information from the government. "But information sharing 'is taking a minor hit,' according to Errol Weiss, chief security officer at the Health-ISAC, the industry's information sharing and analysis center. The pace of alerts from the Cybersecurity and Infrastructure Security Agency (CISA) and the FBI 'definitely looks like it's slowing down a bit,' Weiss said. Riggi described a delay in receiving threat intelligence from CISA 'because of the leadership change,' though he said sharing with the FBI 'continues to be very robust.' "Threat briefings are still occurring, industry figures said, but their frequency has become uneven as relationships with agencies have grown strained, and federal workers have retired or been laid off. 'They definitely tapered off,' said a water industry representative. EPA Press Secretary Brigit Hirsch said the agency has continued to provide briefings 'with the same cadence' as in the past. "Trump's federal travel restrictions have also made it harder for government employees to attend industry events and tour infrastructure facilities. 'It's difficult to get them to meetings,' Weiss said. It took a long time for government officials to get permission to attend the industry's annual tabletop exercise on Thursday, which will game out how the country would respond to a major cyberattack on healthcare facilities. "At the same time, Trump has continued a project that former President Joe Biden launched last year to speed up the pace of briefings. The Critical Infrastructure Intelligence Initiative, run by CISA, and the intelligence community provides cleared industry officials with a classified readout on the threat landscape on the first Wednesday of every month. A second water industry representative called it an improvement over the briefings for smaller groups of industry leaders at biannual sector leadership meetings. No agency has seen more change under Trump than CISA, according to experts and industry figures. "Congress created CISA in 2018, under the first Trump administration, to serve as the hub of the government's cybersecurity partnerships with U.S. infrastructure operators. But CISA's efforts to counter misinformation during the 2020 election transformed it into a conservative bogeyman, and the second Trump administration quickly began targeting the agency, freezing its election security work, pushing out roughly one-third of its 3,300-person workforce, ending threat-hunting contracts, and proposing even deeper cuts. Now, infrastructure operators say they barely recognize the fledgling but ambitious agency they had gotten to know over the past six years. 'With CISA, there is no partnership. It's gone,' said a second energy industry representative. 'We can't even seem to get meetings with the necessary folks there.' "CISA's recent cuts 'have severely affected the agency's ability to engage meaningfully with industry stakeholders,' said Jen Sovada, general manager of the public sector at the operational technology security firm Claroty. CISA spokesperson Marci McCarthy said the agency 'remains fully committed to its core mission of securing the nation's critical infrastructure and enhancing cybersecurity resilience,' adding that 'public-private collaboration is defined by outcomes such as reduced risk, improved response, and strengthened trust, not by the number of meetings.' "But CISA employees say they're deeply frustrated with the changes and reductions at their agency. 'We are at a bit of a standstill,' said one CISA staffer, who requested anonymity to speak freely. 'People are adjusting to having lost a good chunk of their workforce. We're trying to find the new "normal," given the departures and changing mission parameters.' "The Joint Cyber Defense Collaborative, which the agency launched in 2021 to make its public-private partnerships less conversational and more operational, has seemingly fallen dormant. 'I have not heard a peep from JCDC the last few months,' said the first energy industry representative. The industry spent two years working with JCDC on a 'multi-part' effort to address state-backed cyberattacks on midstream gas pipelines, this person said, but the nearly completed project hit bureaucratic snags toward the end of last year, 'and now I have no idea the status of it.' "A public-private task force focused on securing technology supply chains, co-led by CISA and the IT and telecom sectors, has effectively shut down following the loss of CIPAC. The task force's high-level meetings 'have gotten canceled every week,' a telecom industry representative said. Trump's cuts have also forced out many of CISA's regional advisers, who serve as field liaisons connecting infrastructure operators with the agency's free guidance and services. As a result, CISA has 'gone off the grid' in many states, the first water industry representative said. 'If all your CISA folks leave in your state, who are you supposed to call? Nobody's communicating that.' "The loss of CISA advisers undermines infrastructure operators' readiness to fend off cyberattacks, according to industry representatives who recounted these advisers providing briefings, participating in tabletop exercises, advertising free CISA services like vulnerability scans, and serving as emergency resources. 'Water system operators were trained to reach out to those CISA points of contact,' said the first water industry representative, 'and now they don't know who to contact. So either information that needs to get to the government is not getting there, or it's taking longer.' "In addition to the struggles at CISA, infrastructure operators have also reported problems with the specialized Sector Risk Management Agencies (SRMAs) that help various industries deal with cyber and physical threats. Around the time of the change in administrations, the EPA and CISA canceled a series of planned meetings with state water overseers, according to a third water industry representative. Hiccups like this have compounded what industry leaders said was the EPA's already anemic ability to help the sector withstand attacks. Hirsch, the EPA press secretary, said the agency 'will continue prioritizing staffing and resources' for cyber support, adding that EPA considers cybersecurity 'one of its highest priorities.' "Meanwhile, the healthcare community is deeply concerned about the future of cyber aid from the Department of Health and Human Services. The Trump administration is demoting and restructuring the HHS wing that handles the department's SRMA work. 'It seems like they've taken a step back,' a healthcare industry representative said. 'The sector used to meet regularly, sometimes weekly, with HHS to discuss critical infrastructure cybersecurity,' Weiss said, 'but since the new administration, all of that's gone.' HHS did not respond to multiple interview and comment requests for this story. "Members of the energy sector said their cyber partners at the Department of Energy and the Transportation Security Administration, which protects oil and gas pipelines, were trying their best but facing political headwinds. The second industry representative said 'DOE is busting its butt' to help industry despite a lack of leadership support, while the remaining staffers at the TSA are 'trying really hard to save the ship.' DOE and TSA did not respond to requests for comment. 'There is a degradation of support that's happening,' said Caitlin Durkovich, who served as Biden's deputy homeland security adviser for resilience and response. "As Trump appointees have pushed to shrink their agencies, key points of contact for infrastructure operators have left the government, leaving companies and their trade groups in the dark about who to call for cybersecurity help. Those departures have eroded important trust relationships between the public and private sectors. 'If I get a phone call from somebody at CISA who's worked incident response efforts with me, I'll drop everything and take that call, because I know it's important. And likewise, if I call them, they're going to answer my call,' Weiss said. 'If we don't have the ability to interact on a regular basis like this, and the players change, we're not going to have those relationships.' "And it's not just trust that takes time to build. Departing staffers 'had built up substantial knowledge about the sectors they worked with,' said Daniel, the former White House cyber adviser, 'and the government has now lost the benefit of that expertise, which will be difficult to replace.' As they navigate canceled meetings and missing points of contact, industry officials say they're not waiting around for the government to tell them how to protect their sectors. 'It's become even more evident that the private sector's got to take an active role here because of all the cutbacks,' Weiss said. "Infrastructure operators proudly tout the fact that they, not the government agencies, already have most of the technical expertise necessary to operate and protect their systems. But they worry about filling any void in information sharing left by a shrinking government. Some critical infrastructure communities are now worried about what would happen in the event of a devastating cyberattack. "'If there's a major sector incident, I worry about the response capability of the government,' Weiss said. With the current level of support from the government, one water industry representative said, a widespread intrusion into water systems 'could be disastrous.' Asked about the government's ability to help contain a major hack in the natural gas sector, the second energy industry representative said, 'I no longer know.' "This industry pessimism has only exacerbated the alarm that many cyber experts feel about recent events. 'We really can't afford to roll back the capabilities and strength that come from public-private collaboration,' said Phil Reitinger, president and CEO of the Global Cyber Alliance. 'The risk is too great.'" So, you know, there's a great deal of handwringing, and the question to ask would be whether CISA and the various other agencies that were pared back or eliminated were needed, can be replaced, and certainly how we move forward from here. At this moment in time it sounds as though we're somewhat more vulnerable and uncoordinated than we're going to be in the long term. We'll figure out, I think, you know, I mean, it sounds like government support has shrunk. Infrastructure agencies are scrambling to pick up the slack. It seems to me the biggest problem is the loss of private/public partnerships and communications. They're just, you know, that got broken. And so that needs to get figured out and put back together. |
| Leo: And there's also a bunch of institutional knowledge which is gone. |
| Steve: Yes. Actually, the loss of institutional knowledge is the biggest concern. People who are now in the government, especially newly appointed people at the top, just don't have the background. They don't have the history to help guide their departments. |
| Leo: And this is a microcosm of what's happening all over the federal government right now, in science, healthcare, so many other areas. It's a political revolution. I don't think it's a positive one. Some people do. I don't think we're saving money. And if we are, we're spending it in other ways. We're definitely not reducing deficits. So it's hard to explain it, to be honest. |
| Steve: Yup. |
| Leo: But there it is. |
| Steve: Anyway, we've sort of been dancing around this, and this report, with a lot of interviews, gave us a good sense for CISA. And everybody knows, I mean, I didn't expect CISA to be as wonderful as it has been. I mean, it's been amazing. I mean, I love their characterization where they talked about how like for the last six years, you know, it just - it was wonderful. And, you know, I hope it is able to retain that because... |
| Leo: Well, we'll see. |
| Steve: ...it's done a lot of good. |
| Leo: We'll see. I mean, you know, the future is coming at us pretty darn fast. |
| Steve: It is indeed. |
| Leo: We will see what happens. |
| Steve: So is our next sponsor. |
| Leo: Yes, it's here, as a matter of fact. We'll take a little break, come back with more Steve Gibson and Security Now!. We're so glad you're watching. Back to Steve. |
| Steve: Okay. So just a quick note that the W3C, our Worldwide Web Consortium, has just released Version 3 of the PNG, the Portable Network Graphics image format. It supports animated PNGs... |
| Leo: Oh, great, just what we need. |
| Steve: ...HDR graphics, and EXIF metadata. And actually, Leo, it was animation that was the only thing that GIFs or GIFs or however you want to pronounce it, that was the one advantage they had because you had to use a GIF if you wanted animation. |
| Leo: That's true. That's true, yeah. |
| Steve: So now we're going - it'll take a while for this v3 spec to get out in the world and tools to be developed and... |
| Leo: PNG is much better, too. It's a much smaller format. |
| Steve: Yes. |
| Leo: It's much better quality. It's time to phase GIF out, I think. |
| Steve: Yes. I'm glad. And I think this will probably put the nail in the coffin because it was only the animation that was GIF's benefit. I did want to mention in passing, I noted that you guys touched on it on MacBreak Weekly that Apple's language Swift is being ported to Android. Apple is assisting in the effort. I agree with your appraisal that, like... |
| Leo: It's open source, yeah. |
| Steve: That, like, okay, you know, yeah, right. It's technically not theirs, but it's the language that they promote. And so it'll be nice to have it on that platform. |
| Leo: It's memory safe; right? |
| Steve: Yes. It is a good language. It is one of the... |
| Leo: It's very good. It's functional. |
| Steve: It's a modern great language. |
| Leo: Object oriented, yeah. |
| Steve: And also while we're just on the subject of Android, I wanted to quickly note for any of our listeners that might be affected that Samsung will be purging all of their users' inactive accounts at the end of this month, the end of July. Any Samsung account that has not been logged into for the past two years will be purged and permanently forgotten by Samsung. And, you know, it makes sense. Google, Yahoo, Photobucket, and others have done something similar. So anyway, I just wanted to say that, if anybody who might wish for some reason to retain an old dormant Samsung account, you have till the end of this month just to log in and let them know that you're still alive, and then they won't cancel it. |
| Leo: That's all they want you to do. Are you still alive? Let me know. |
| Steve: A listener of ours, Walt Stoneburner, a man of few words, sent this. He said: "Thought you might enjoy this." And then all I got was a YouTube link. And he signed off "Walt in Ashburn." However, the subject of his email, since he used GRC's email system, the subject read "Project Hail Mary TRAILER." |
| Leo: Yeah, baby. |
| Steve: Oh. Now, our listeners... |
| Leo: Nine million views already in one day. |
| Steve: Yes. |
| Leo: Look at that. |
| Steve: Yes. Back in 2011, Andy Weir wrote "The Martian." |
| Leo: Wonderful book. |
| Steve: A book which many of us read and loved at the time. |
| Leo: Yes, yes. |
| Steve: You know, it was funny and geeky and full of actual science. Then four years later, Ridley Scott directed Matt Damon's terrific performance in the movie of the same name. And the movie was terrific, too. It cost about $108 million, that is, "The Martian" cost $108 million to make. It got positive reviews from critics, and it grossed over $630 million worldwide, which brought it to the 10th highest grossing film of 2015, and that was Ridley Scott's highest grossing film to date. |
| Leo: Really. More than "Alien." |
| Steve: Which surprised me. I know. I would have thought that "Alien" would have blown that away. |
| Leo: Yeah. |
| Steve: It was also named by the National Board of Review and the American Film Institute one of the top films of 2015. And it got seven nominations for the 88th Academy Awards. Then, four years ago, so in 2021, Andy Weir gave us "Project Hail Mary." |
| Leo: We interviewed him when that came out, and I remember him talking about this movie because they bought the rights to it before he even published the book. |
| Steve: After "The Martian," why wouldn't you? |
| Leo: Yeah, exactly. |
| Steve: I mean, it's a little bit like Michael Crichton, where every novel he's ever written has had a movie made. |
| Leo: Oh, yeah. Andy's very happy, yeah. |
| Steve: Yeah. And as for "Project Hail Mary," you know, many of us read it, or listened to it being read to us. |
| Leo: Highly recommend the audiobook of it because they do a really good job with, well, I can't tell you what they do a good job with. |
| Steve: No, we have to be careful about spoilers. And in fact you made the comment that the trailer does have some soft spoilers in it. |
| Leo: Yeah, don't watch the trailer, yeah. |
| Steve: So, right. |
| Leo: If you haven't seen - if you haven't read the book. |
| Steve: If you've read the book, yes. So anyway, I made a GRC shortcut, although obviously anybody could find the trailer on YouTube, grc.sc/hailmary. That'll bounce you right to the official YouTube trailer. And Leo, it looks so fun. The same screenwriter who wrote the screenplay for "The Martian" also wrote "Project Hail Mary," and it's Drew Goddard is the guy. |
| Leo: He did a great job with "The Martian." In fact, there's a line in the movie that wasn't in the book, that Andy Weir always gets credit for, everybody assumes it was in the book. You know, when your astronaut says "I'm going to science the [blank] out of this." |
| Steve: Uh-huh. |
| Leo: That's in the movie, not in the book. So... |
| Steve: Well, and I loved it. And I don't remember, it looks to me like some liberties were taken. But at one point Gosling, who stars in... |
| Leo: That's the only thing I'm unhappy about this. I'm not a Ryan Gosling fan. |
| Steve: I don't mind him. He looks fine. Anyway... |
| Leo: He's right for the part. |
| Steve: He says: "I put the 'naut' in astronaut." And he says... |
| Leo: That's from the book. I think that's from the book. |
| Steve: Oh, it is? He's like, completely freaked over the idea. He says: "I can't even moonwalk." |
| Leo: He does not want to be there. He doesn't even want to be there, no. |
| Steve: Anyway, it looks like - and so it is coming out six days before I turn 71, on March 20th, because my birthday's on the 26th. So we do have to wait nine months, unfortunately. But it does look like a fabulous movie. |
| Leo: It was a Stacey's Book Club pick from Episode 7 in January. And you could go to Triangulation and watch my interview with Andy Weir. And he talks about the fact that they optioned the movie and that Ryan Gosling was going to be in it. He also was very happy about the directing team. And I'm not sure if they're still... |
| Steve: We don't have Ridley Scott again. We have a pair of directors. |
| Leo: Yes. Yeah. They did "The LEGO Movie." He liked them a lot. He was very happy with the brothers, I think, the two people who are doing it. |
| Steve: Well, I will read it again before the movie. |
| Leo: And folks, again, don't watch the trailer if you haven't read the book. Read the book. |
| Steve: Yeah. You really need - you need to read the book. The book is easy and fun and breezy. |
| Leo: And there's a lot of surprises. |
| Steve: And oh, you remember, it has a wonderful ending, Leo. |
| Leo: I know. |
| Steve: It's got just a really, I mean, it's a - my wife is reading it now because before I met her "The Martian" came out, and she had read the book and watched the movie many times because she's a bit of a science geek, too. So she loved "The Martian." |
| Leo: Lisa and I, I'll never forget, listened to "The Martian" as we were driving a Jeep in Hawaii on the Hana, the crazy Hana Highway. |
| Steve: The back road? |
| Leo: Yeah, that back road. |
| Steve: Yup. |
| Leo: And I'll never forget it. I mean, and we loved it so much. It was such a good book. Love it. |
| Steve: So we're going to get another really great movie. And I have to say I was, as I said to you, I was upset by "Jurassic Park" when I saw the movie because I had read the book. And there were some scenes that, as they say, got left on the cutting room floor, which were, I still think to this day, people don't know some things that were in the book that you should really know. And when I - so I'm watching the movie. I had just reread the book before seeing the movie, and it was like, whoa, whoa, wait, wait, wait, wait, wait, wait, wait, wait. You just skipped over something really important. |
| Leo: Oh, I've got to read the book now. I don't think I've read it. I've read a lot of his other stuff. |
| Steve: Anyway, so I don't know that's not going to happen for this movie. So I would seriously recommend, unless you have, like, some reading phobia that you, you know, read the book. And then, you know, you'll get the visuals with the movie. Because, oh, that's the other - we see a ship, Leo. Oh, what an awesome-looking ship. |
| Leo: Now, my general philosophy, especially with science fiction, is always, the book is always going to be better than the movie, only because it's in your mind. And you can't construct anything in reality like your mind can do it. Not every book is better in the book. But most science fiction books, I would say, read before the movie for sure, yeah. |
| Steve: Yeah. I've found that to always be the case. |
| Leo: Yeah. |
| Steve: And one last piece of feedback from Sean O'Brien, while we're on the topic of science fiction. Sean O'Brien wrote: "You may or may not know that 'Colossus' is a science fiction trilogy which is a decent read..." |
| Leo: I didn't know that. |
| Steve: ...he said, "although it's been about 50 years since I read it." Now, Sean, I don't know how old you are. But you were, maybe you were a tyke while you were reading the "Colossus" trilogy. |
| Leo: He's probably our age, Steve. I hate to say it. |
| Steve: Yeah, I know. He could have been 20, and then he'd be my age, yeah. |
| Leo: Yeah, exactly, exactly. |
| Steve: Anyway, I just wanted to say it didn't occur to me that it could be - that there was more than that one story. So that suggests that we might get something more than that conclusion in the movie, which was mildly disheartening and a little depressing because, you know, it left something up in the air. So maybe the second and third books of the trilogy put that to rest. I don't know. Okay. So we're going to talk about web fingerprinting, but let's just get our last sponsor in here, and then I will do this uninterrupted. This [crosstalk]... |
| Leo: This will be quick and easy. |
| Steve: ...two hours. |
| Leo: Back to you, Mr. Steve. Let's get into the meat of the matter here. |
| Steve: Okay. So what is going on with web fingerprinting? A group of five researchers, three from Texas A&M University, one from Johns Hopkins, and the other from the commercial networking company F5, Inc. collaborated on research which resulted in their publication of their research in a paper titled "The First Early Evidence of the Use of Browser Fingerprinting for Online Tracking." This paper was presented during the 2025 ACM Web Conference which took place from April 28th to May 2nd of this year in the Sydney Australia Convention and Exhibition Centre. The conference was formerly known as the International World Wide Web Conference, which originated at CERN back in 1994, so it has long served as the premier venue for presenting and discussing research, development, standards, applications created for the web, the works. So having this paper accepted at the conference was prestigious. We've talked about web browser fingerprinting a number of times in the past. The idea is that a web browser's query for an asset to a remote web server contains far more than just the name of the asset it's asking for. The most famous thing any web client will send back to a remote web server is a cookie that was previously set into that web client by that remote server. As we know, although the original intent of a cookie was purely for first-party websites - meaning the site the user is visiting for the purpose of maintaining logged-in state and tying all of that visitor's individual page requests together - the cookie name matching was simply by domain name. There was never any express prohibition against other web servers that were also serving content to a page also receiving their own cookies for their own third-party domains. You know? This is the feature - which I have always called a bug - which permitted advertisers that were serving ads pervasively across the web, that is, everywhere, on all kinds of sites, to thereby track individual users across their web browsers as they move from site to site where that advertiser had ads because a single user would always return the same unique identifying cookie, no matter where they ventured. The only good thing about these cookies is that their tracking was explicit. So after some time, web browsers began offering their users the ability to manually disable the use of third-party cookies. This is an inherently privacy-enhancing feature, but only a single browser in history has ever shipped with this clear privacy enhancement enabled by default, and that browser is Safari, bless Apple's heart. So Apple should receive some serious props for having made that decision long ago. The persistent problem of third-party tracking for privacy has dogged the industry. The browser vendors did not want to follow in Apple's footsteps for fear of breaking websites, since there are some defensible needs for third-party cookies not just used for tracking, but also for synchronizing allied services with a first-party site. So the web browsers finally settled upon "stove piping" cookies. The best analogy is the one Firefox uses of having multiple cookie jars. Third-party cookies can only be used for tracking when web browsers store all of their cookies together in a single large cookie jar. In that fashion, no matter where a user roams on the web, web tracking advertisers would obtain their unique cookie from that single cookie jar. Firefox was the first to pioneer per-site cookie jars, and Chromium has followed actually relatively recently since. And in this model, third-party cookies are still enabled by default, but any cookie that's set when visiting a specific web domain - regardless of whether it's a first- or a third-party cookie - will only be stored inside the current domain's individual cookie jar. So that completely breaks tracking. In computer science parlance we would say that cookies are "scoped" to the browser's first-party domain. This means that all cookies now carry the site the user was visiting at the time the cookie was received, and that cookie will only be returned to its requesting domain if the first-party domain also matches. Over time, the slowly growing pushback against web tracking, which data brokers and advertisers believe is crucial to the success of their businesses, was a source of great concern for these companies. Cookies were threatened, you know, threatening to become unreliable due to this anti-tracking pushback. So these companies, the ones that wanted to do the tracking, like were committed to it, started looking for non-cookie means of tracking users. Cookies were explicit. What these companies needed was something that would be implicit. So before I go on, I need to just remind everyone of one thing that it's easy to overlook. The single most obvious and almost impossible to bypass at a whim tracking that's available is our IP address. I've often noted that my Cox cable IP is so static that I'm able to use IP-based filtering at the Level 3 data center in order to reach my residential IPs, and I only need to change that IP when I switch cable modems. So I tend to have the same residential IP, often for months or years at a time. I may be an extreme case, but no one should imagine that the IP address that's being used to fetch ads and tracking scripts from remote servers is not being used as a significant factor, maybe the most significant factor, in the individual's identification because for a long... |
| Leo: Well, it's interesting because in the EU they do call it personally identifiable information, your IP address. |
| Steve: Yeah. |
| Leo: The problem is that that's how the Internet works. You have to publish your IP address or you can't open a website. |
| Steve: Right. Yes. Your browser is making a direct point-to-point contact, unless you go through huge hoops, like using Tor or something. |
| Leo: Well, or a VPN. |
| Steve: Or a VPN. |
| Leo: Yeah, VPN will do it, yeah. |
| Steve: Yeah. |
| Leo: But, you know, that is part of the problem with IP address tracking though is a lot of people are on shared IP addresses. Everybody in a company usually comes in on the same IP. |
| Steve: That is true. |
| Leo: I know a little bit about this because it's one of the issues we have in measuring audience; you know? If a thousand people at Microsoft download Security Now!, it looks like it's the same person. |
| Steve: Yeah. |
| Leo: And so we can't, you know, we don't count them. |
| Steve: Although it is a thousand downloads from the same IP, so there is some soft information there. |
| Leo: Yeah, we throw those out. It has to be - and the reason for that... |
| Steve: You call them unique downloads. |
| Leo: This is in the weeds. But a lot of podcast clients open eight or nine streams to download it. So almost all the audience metrics debounce, in effect, the IP address. And sometimes - NPR managed to get it to be a 24-hour debounce. You know, we ignore it, the same IP address for 24 hours, which is way too long. I was very upset when they did that. That hurt us rather badly. But NPR didn't care. And the people who implemented it, the Interactive Advertising Bureau, loved it because they represent advertisers, not podcasts. |
| Steve: I solved that problem by looking at the byte range because when you open... |
| Leo: Oh, yeah, they don't open, they don't download the same byte, that's right. |
| Steve: Correct. |
| Leo: Yeah. |
| Steve: And so I only count the one that begins at byte zero. |
| Leo: That makes sense. |
| Steve: Yeah. And then I just ignore all the others. |
| Leo: I don't know if we, you know, because remember we use CDNs. I don't know if we have access to that kind of information, that regularity, yeah. |
| Steve: Yeah. Anyway, so I just wanted to remind everybody... |
| Leo: It's a big topic, but [crosstalk] identifiable. That's your IP address. That's you. |
| Steve: Yeah. And the other thing, too, is remember you may, like, if you changed IP addresses deliberately while not at the same time synchronizing a change with your browser, then your browser serves as a bridge between your old and your new IP, and they just start tracking the same person at the new IP. I mean, so, I mean, I just wanted to remind everybody, while we're talking about all of this, you know, tracking avoidance stuff, IP address is there, too. And so you have to, like, you have to completely change every aspect of your identity at the same time because these trackers are so determined to lock onto you that, if you change something, they'll just adapt to that using the other tracking information that you didn't change at the same instant that you changed one of them. I mean, it's, you know, diabolical. So you change browsers, but you're still on the same residential IP. They go, okay, now the same guy's on this browser. You know, it's like, okay. So anyway, I just wanted to, you know, if you were like being super-sneaky, I know people are, like, deleting their cookies and spoofing their browser's user agent string, switching between browsers, switching into incognito mode, or private browsing, you don't change your IP, they just go, uh-huh, well, we see what you're doing. Fine. Okay. So consumers have loudly and clearly voiced their preference for not being tracked as they move around the web. They don't want any tracking, if for no other reason than it just feels creepy, and it doesn't obviously benefit them, and no one asked their permission. Recall that when Apple iOS 14.5 added that App Tracking Transparency which popped up the question, "Allow this app to track you across apps and websites?" Four out of five people said no. Only one out of five said, fine, I don't care, if you want to. So people don't like it. Given this clearly negative tracking sentiment, and the strong business need the trackers believe they have, a great amount of industry has gone into tracking. I mean, it's shocking how much. You know, again, even across IP address changes, when third-party cookies don't work. And as we recently talked about, Meta solved this problem with their so-called "Meta Pixel." |
| Leo: "Solved" is an interesting way to put it. They hacked this problem. |
| Steve: They did, right. You know, by running a script on all the websites that had Meta thumbs up and like buttons and their own tracker. And then using that localhost access to their own app on devices because they were in a privileged position of having a high incidence of app presence on devices. So, you know, most advertisers and data aggregators don't have that kind of privilege that Meta did, so they're unable to abuse that. Believe me, they would if they could. |
| Leo: And the real point of all this is, yeah, IP address is important. But they don't have to rely on that. |
| Steve: No. And they're not. So what remains after all these other things have been tried is web browser fingerprinting. Like the Meta Pixel, which used the localhost connection to local applications... |
| Leo: Ugh. |
| Steve: I know. Web browser fingerprinting used for tracking can best be described as sneaky. Until now, the unanswered question has been: "Just how prevalent is fingerprint-based tracking?" It was the question that these researchers set out to answer. The Abstract of their paper reads: "While advertising has become commonplace in today's online interactions, there is a notable dearth of research investigating the extent to which browser fingerprinting is harnessed for user tracking and targeted advertising. Prior studies only measured whether fingerprinting-related scripts are being run on websites, but that in itself does not necessarily mean that fingerprinting is being used for the privacy-invasive purpose of online tracking because fingerprinting might be deployed for legitimate purposes such as bot/fraud detection and user authentication. It's imperative to address the mounting concerns regarding the utilization of browser fingerprinting in the realm of online advertising." And I'll just mention that, as an example of fingerprinting for bot/fraud detection, that's what Cloudflare does. When you go to one of those sites where you're stopped by that greeting page that spins something for a few minutes or, well, not minutes, seconds, and then, like, says okay, you're allowed to pass. That's you being fingerprinted by their script running in your browser making a decision about whether you're a legitimate human visitor or bot or fraud. So they said: "This paper introduces 'FPTrace,' which is an abbreviation for 'Fingerprint-based Tracking, Assessment, and Comprehensive Evaluation,' so a bit of a strained abbreviation, FPTrace, obviously Fingerprint Trace." They said: "A framework to assess fingerprinting-based user tracking by analyzing ad changes from browser fingerprinting adjustments. "Using FPTrace, we emulate user interactions, capture ad bid data, and monitor HTTP traffic. Our large-scale study reveals strong evidence of browser fingerprinting for ad tracking and targeting, shown by bid value disparities and reduced HTTP records after fingerprinting changes. We also show fingerprinting can bypass GDPR/CCPA" - that's California's Consumer Privacy Act - "opt-outs, enabling privacy-invasive tracking against expressed, in contravention of, expressed user wishes. In conclusion, our research unveils the widespread employment of browser fingerprinting in online advertising, prompting critical considerations regarding user privacy and data security within the digital advertising landscape." So what these guys did was brilliant. They deliberately manipulated the apparent fingerprints of web clients, or actually apparent web clients, carefully observing the behavioral changes in the ads and pages that were returned. When taken at scale, this allowed them to infer the degree to which specific advertising behavior was being driven by the fingerprinting of web browsers. It's brilliant. I mean, it's kind of what you would have to do, but these guys did it. So here's what they shared in their paper's introduction, which offers some additional depth. They said: "Browser fingerprinting is a technique employed to surreptitiously collect data regarding a user's web browser settings during their online activities. The collected data is then utilized to construct a unique digital identity, commonly referred to as a 'fingerprint,' for that specific user browser." And again, to Leo's point, changing your IP doesn't change this. "Each time a user visits a website, there is potential for the site to employ browser fingerprinting as a means to identify and track the user. Many earlier research studies and reports assumed that the adoption of a fingerprinting script itself is an indication of web tracking and a violation of web privacy. However, this assumption does not hold. Just like cookies, browser fingerprinting can be used for defensive security purposes, like bot/fraud detection or authentication. For example, Wu et al. showed that the fingerprints of malicious web clients differ from those of benign users and therefore many real-world websites are using fingerprints for bot and fraud detection. As an example, Lin et al. demonstrated the real-world usage of browser fingerprinting in authentication as has been demonstrated in feasibility studies. "Therefore, the research question that we are answering in this paper is whether browser fingerprints are indeed adopted for online tracking, thus violating web privacy. To the best of our knowledge, none of the prior works have established the link between browser fingerprinting and online tracking. On one hand, many browsers consider the mere existence of fingerprinting scripts to be evidence of online tracking, which is not true. On the other hand, people have studied the relationship between personalized advertisements and web tracking in general, like cookie-based tracking. "For instance, Wills et al. explored ad tracking on the Google and Facebook advertising platforms. Similarly, Zeng et al. employed header bidding to assess targeted ads. These studies did not specifically address the methods employed to link tracking with online advertising; therefore, it remains unclear whether browser fingerprinting was a contributor to online tracking and privacy violation. "This paper seeks to bridge this gap in current research and regulatory assessment practices by investigating whether the advertising ecosystem indeed utilizes browser fingerprinting for user tracking and targeting via a measurement study. Our key insight is that if browser fingerprinting plays a role in online tracking, the change of fingerprints will also affect the bidding of advertising and the underlying HTTP records. Specifically, our approach involves leaking user interest data through controlled A/B experiments, modifying browser fingerprints, and leveraging advertiser bidding behavior and HTTP events as a contextual indicator in the advertising ecosystem to deduce changes in advertisements. Given that advertiser bidding behavior and HTTP events are influenced by their prior knowledge of the user, we anticipate notable changes in this information when altering browser fingerprints." So looking at the details of the three broad contributions that they feel they were able to make to our understanding, our industry's understanding of what's going on, we learn some interesting things. So here are the three things they feel they contributed. They wrote: "We offer the first study to measure whether browser fingerprinting is being used for the privacy-invasive purposes of user tracking, targeting, and advertising. Our main contributions can be summarized as follows." They have three, as I said. "First, we introduce a framework, FPTrace, for detecting changes in advertisements following alterations in browser fingerprinting. FPTrace simulates real user interactions, captures advertiser bids, records HTTP data, and removes or exports cookies to observe such changes for the measurement purposes of browser fingerprints. "Second, our findings provide evidence that browser fingerprinting is indeed utilized in advertisement tracking and targeting. The bid value dataset exhibits notable differences in trends, mean values, median values, and maximum values after changing browser fingerprints. Moreover, the number of HTTP records, encompassing HTTP chains and syncing events, decreases significantly after altering browser fingerprints." Meaning pretending to be somebody new rather than somebody known. "We also evaluate the role of browser fingerprinting in cookie restoration. Our results confirm that certain cookies contain browser fingerprinting information. We documented 378 instances of cookie restoration related to fingerprinting across 90 unique combinations of cookie keys and host pairs across all settings." In other words, again, remember that there's all these different beacons that the browser is sending. There's IP address. Now we've confirmed there's fingerprinting, and there's cookies. So if you change, if you were for example to delete your cookies, as long as there's a consistent fingerprint or consistent IP, the cookie will immediately be restored by the trackers. They want to keep all of these beacons alive specifically so that losing any one of them allows them to still be locked on to the people that they're tracking. You know, they're literally doing everything they can, no matter whether people want them or don't. "And third," they said, "we further study the potential malicious use of fingerprinting in the presence of data protection regulations such as GDPR and CCPA when used with content management platforms. Even under the GDPR and CCPA regulation protections, there are significant variations in the number of HTTP chains and syncing events observed in certain instances when browser fingerprints are altered. Under GDPR, websites utilizing Onetrust, Quantcast, and NAI might be involved in data sharing activities that use browser fingerprinting to identify users. Under CCPA, Onetrust and NAI might be involved in data sharing activities that use browser fingerprinting to identify users." Okay. So one of the more interesting aspects of this was that we learn of so-called "Header Bidding," where the amount of money an advertiser is willing to pay to have their advertisement inserted into a webpage is determined by whether they recognize - and thus have been tracking - the apparent viewer of the website's page. Here's what their research explained when they introduced the idea: "Header bidding," they write, "is a method employed by publishers on websites. Here, publishers designate specific advertising spaces for potential advertisers to fill. The advertiser securing the highest bid gains the chance to display their ads in the corresponding slots. In client-side header bidding, users have the convenience of directly accessing and observing all the bids from their web browsers. Prebid.js is a notable implementation of header bidding. Through the API pbjs.getBidResponses(), users on the client side can inspect the list of advertisers who engaged in the bidding process to secure the opportunity to display ads during the current user's visit. "In one study of this, the author observes that profiles classified as 'Only category,'" - meaning known users - "command prices 40% higher than those assigned to 'New user' profiles. The key finding underscores that advertisers' bidding behavior is shaped by their prior familiarity with the user, resulting in elevated bid values compared to users for whom advertisers lack previous knowledge. In other research by Liu et al., they additionally demonstrated that advertisers with knowledge of users through data syncing tend to submit higher bid values in header bidding." So we talked about client-side advertising selection in the context of Google's Privacy Sandbox development, where they were hoping to push the technology further, taking the decision out of the hands of advertisers entirely and fully isolating the advertisers from the advertised-to. So the fact that client-side advertising selection in the user's browser allows researchers to observe this bidding process, and that the difference in offered ad price is around 40% greater, provides exactly the sort of feedback that's needed to judge the effects of known and tracked versus unknown, untracked users. And let me just pause for a moment to observe something that is very important. We're talking about an advertiser paying a website 40% more for displaying an advertisement to a known website visitor. Imagine for a moment receiving a 40% raise in one's employment income. That's a big deal. And this gives us a first sense for the value that tracking must represent to web advertisers. They're not dumb. They're not going to pay a 40% premium to inject their ad into a competitively bid website slot unless they are sure it's going to be worth that additional premium to them. One of my constant bemused refrains on this podcast whenever we've talked about tracking has been my skepticism that tracking and identifying website visitors can really matter so much. I've apparently been naive because money talks, and these guys matter-of-factly observed that known visitors, which allows for much more effective ad targeting, are in fact and truly worth a 40% advertising premium. And consider that this is money that's collected by the website that's made that advertising slot available. This means that it's also in that site's strong interest to have its visitors identified to its advertisers. We've talked about the somewhat icky idea that websites might be colluding with their advertisers for the express purpose of helping their visitors to be identified. If collusion means that a website will be generating 40% more revenue from advertising, it's not much of a leap to imagine this is happening wherever possible. |
| Leo: I wouldn't call it colluding. This is just the way it works. If you want web advertising, you provide the information. |
| Steve: Right. |
| Leo: But we're lucky because we're a podcast. We can't do all that weird stuff. |
| Steve: Right. |
| Leo: I mean, we do as much as we can if advertisers demand it. |
| Steve: Right. And remember, we've talked about that new policy we saw of websites asking to join the website for free. They all just "give us your email address, and you get to have additional benefits." Well, that email address is being encoded and returned to the advertisers in the URLs of the scripts that are being loaded. So the websites are saying, here's who has joined our website. And remember that the privacy policies even allow this. So the website is saying, hey, we're covered by our privacy policy. They're giving these email addresses to everybody who pulls content from that page. One of the other research papers they referenced talked about the effects of this real-time bidding. That research, which has the title "Selling Off Privacy at Auction," wrote: "We provide an analysis of the value of users' private data from the advertisers' perspective based on prices they paid for serving ads to users. We analyze how such factors as the visiting site, the time of day, user's physical location, and user's profile affect prices actually paid by advertisers. Interestingly, we discovered that prices are highest in the early morning. Prices in the U.S., average $0.69 CPM, are observably higher than those in the cases of France at $0.36 CPM and Japan at $0.24 CPM. "We confirm the fact that when a user's web history is previously known to advertisers, they're willing to pay a higher price than in the case of new users. We also show that users' intents, such as browsing a commercial product, are higher valuated than their general histories, i.e. browser sites not related to specific products. Finally, we highlight a huge gap between users' perception of the value of their personal information, which is quite high, and its actual value on the market, which is quite low." But it's not zero. Finishing up with the original research that led us here, the researchers make a clear statement to address the limitations of their study. They write: "Our experiment was conducted using IP addresses from two locations in the United States, both of which are located in the United States and are not subject to privacy regulations such as GDPR or CCPA. In regions protected by such regulations, trackers like cookies are prohibited from tracking users once they opt out. "However, our experiment has revealed that advertisers may employ browser fingerprinting to track users without providing any notification. It remains uncertain whether advertisers can continue using browser fingerprinting to track users, as there is currently no established framework for auditing advertisers in this context. It's important to note that our experiment cannot be utilized to assess advertisers' behavior within the constraints of privacy regulations. "Another limitation of our study is that all experiments were conducted on the Linux platform. We did not determine whether users of Windows devices, macOS devices, or mobile devices can still be tracked by advertisers using browser fingerprinting techniques." Now, you know, they're just covering their bases here; right? We know this is all happening regardless of platform. They're just saying we did not explicitly test that. They said: "While some of our fake fingerprint data were obtained from Windows devices, macOS devices, or mobile devices, which we used to emulate our experimental device browsers, it would be valuable to incorporate real Windows devices, Mac, or mobile in the 'True Fingerprints' settings to gain a more comprehensive understanding. Additionally, there is uncertainty regarding whether websites visited by FPTrace can accurately distinguish between visits from a crawler and those from real users." Meaning maybe they were spotted as being a bot. They said: "Despite our efforts, such as altering JavaScript API values and simulating human behaviors, we cannot be entirely certain that there are no undisclosed techniques for detecting bot visits. If FPTrace's visits are identified as originating from a bot, the accuracy of our results could be compromised." And again, they've got really good statistics, but they're just saying, you know, to be as good a raw research paper as possible, they have to say here are the limitations that we recognize. These are the things we did and what it might mean. So we learned that browser-side scripting being loaded by advertisers, which is used to deeply profile every aspect of a browser that it can, is conclusively being used to track users and reconnect and restore deleted cookies. We also learn that it is in direct contravention of GDPR and CCPA regulations, clearly expressed user preferences, and it's being done anyway. You know, in high school the bully would say, "Oh yeah? So make me!" Today's advertisers have adopted a similar attitude. This is principally done by third-party scripting, and I was wondering what the web experience might be if only those scripts were prevented from running, that is, only third-party scripts. Since uBlock Origin has the ability to selectively block only third-party scripts while allowing only first-party scripting delivered by the site to run, I gave it a try. Not long after, I clicked on a button to make a reservation at a local restaurant, and the button was dead. It took a few retries and page refreshes. Nothing worked. Then I remembered what I had done. So I reversed that block, and all was well again. In other words, you cannot disable third-party scripting in this day and age. Things don't work. Today's modern websites are strung together from a hodgepodge of third-party functionality. You know, nobody rolls their own and reinvents the wheel when there's some online service that can just be plugged in and glued on in return for a small piece of the action. It's just no longer possible to tinker much without causing breakage. Browser vendors are aware of this problem, and they've done things like deliberately reduce the resolution of their time of day, reported through JavaScript. Remember we've talked about that in the past, or fuzzing the script-reported battery level of the laptop or mobile device, you know, and any other things they can think of that might be used to create trackable data. But none of that has stopped this practice. And unlike cookies, which are an overt identifier and can be corralled, it's unclear what more can be done to mask fingerprints without breaking legitimate script dependencies. The blame for making our browsers so trackable through fingerprints ultimately falls on the shoulders of the World Wide Web script designers. They endlessly add one "gee whiz" feature after another. Does script really need to know a device's current battery level and ambient light level, as well as its compass orientation? Sure, it's possible to concoct a scenario where that might be useful. But in that case, ask for permission while visiting that page. Don't just leave it open all the time. But all of this superfluous environmental crap creates a gold mine for anyone wishing to mine that for information that they can use to track people from one site to another. That said, for short-term tracking, nothing beats the trusty old IP address, and there's not much anyone can do about that as they wander around the web, at least over the short term. Given that knowing who someone is, is worth 40% advertising revenue boost to websites, websites are going to do everything they can to identify their visitors to every one of their prospective advertisers in order to increase their own per-visitor revenue. There's a great deal of this cross-website and advertiser communication going on behind the scenes. The counter argument is that this is what's necessary for websites to be profitable these days, to keep going and to support the content that they're providing. So it's a tough call. Anyway, for anyone who's interested in digging deeper, I've got links at the end of the show notes to the full 16-page research paper and the related resources that I cited. So fingerprinting is here. It's here to stay. I don't think we're going to get rid of it. Google gave up on all of their efforts to try to change the way that the web was monetized, Leo. |
| Leo: I mean, unless you're willing to pay for everything that you use, that's, you know, that's really the way it's going to be. I mean, if you, by the way, if you join Club TWiT, there's absolutely no tracking. Podcasts have very limited ability to track. It's totally IP based. We do have redirects in our podcast feeds for non-TWiT members, non-Club TWiT member, because we use a system, a couple of different systems. But the idea is that they, as an independent third party, get the IP addresses. |
| Steve: You want to count them; right? |
| Leo: Well, we do it for counting. We do our own counting. We don't use a third-party for that. But what we do is, through pod sites, there's companies called Magellan, there's a number of companies, Spotify does this, is they take the IP addresses, because we do know that, obviously, everybody, we know that... |
| Steve: Everybody has one. |
| Leo: And then when you go to a website, for instance, you know, we say go to DeleteMe.com/securitynow, really the truth is - it's actually JoinDeleteMe.com/twit. But the truth is that's somewhat important, but really that /twit is less important than the fact that they - I don't know if DeleteMe does this, but most sites do - record the IP address if you're visiting. Then the third party, like an escrow agency, matches them and says 33% of the people who downloaded this show visited that landing page. That is the most privacy focused you can get. |
| Steve: Preserving. |
| Leo: Yeah, because nobody gets, no advertiser gets your IP address ever. The third party does. But they're, you know, kind of this trusted escrow partner. And we don't get information, by the way, from the advertiser, either, about that. They don't have to share that with us. Most of the time they don't. So I think we do a pretty good job. We have to live in the world where advertising demands this. I think there's a lot of evidence that the kind of advertising we do, which is, you know, hey, want somebody who listens to Security Now!, advertise on this show, is much more effective than tracking. We have a lot of evidence of that. So our system works pretty well. And again, if you decide you want to join the Club, we don't even do that. Nothing. You know, your feed is yours and yours alone, and we don't keep track of it. And we certainly don't sell your email address or anything like that. Steve, thank you for explaining how all this works. It just shows you how difficult it is to be anonymous on the Internet. It's almost impossible. |
| Steve: Yeah. |
| Leo: It just really is, unfortunately. |
|
 | 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: Jul 08, 2025 at 06:19 (133.35 days ago) | Viewed 9 times per day |