Security Now 973 transcript

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

0:00:00 - Leo Laporte
It's time for security Now. Steve Gibson is here. He'll talk about GPS fuzzing, how it works, what one can do to avoid it. You've all heard about that VPN flaw that Ars Technica says makes all VPNs useless. Not so fast. Steve explains why it is not anything to panic about. And then, speaking of not so fast, google has stopped progress on abandoning third party cookies. Steve now knows why. He will explain all that and a whole lot more coming up next on Security Now. Stay here. Podcasts you love from people you trust. This is Twitter. This is Security Now with Steve Gibson, episode 973, recorded Tuesday May 7th 2024. Not so fast. It's time for Security Now, the show where we cover the latest security and computer news and privacy news and, of course, a little sci-fi and TV thrown in, with this guy right here, steve Gibson, the arbiter of all that is good and kind.

0:01:10 - Steve Gibson
Hello, steve oh well, I'll go for that. Yeah, yeah, hello Leo. So here we are. At the middle of the show, you said, hey, google just changed their plans on third party cookies. And I said, what, anyway? So we're going to talk about that. So we're going to talk about that. Today's episode is titled Not so Fast, which you know as in that expression, not so fast there, which is what the UK is saying to Google. But we're going to first look at what danger is presented by the world's current and growing dependence upon GPS, and why is that? Any concern has the sky fallen on all VPN systems, as the tech press has been reporting since yesterday, when a blog post really went a little out of control.

0:02:20 - Leo Laporte
I was really hoping and I wanted you to explain option 102 or whatever Option 121.

0:02:26 - Steve Gibson
Yes, I really want to know about that. We will know all about that by the time we're done today. Thank, you.

Also a couple questions more from our listeners, still bogged down in what is arguably a quagmire of network authentication options, so I'm going to spend a little more.

That's continuing to come into crisper focus for me, so I figured I'm going to spend a little more time on what's going on there. Also, we may have an answer to what Apple was doing with the iCloud keychain deleting and what was going on something that absolutely makes sense, so we're going to cover that. What was going on something that absolutely makes sense, so we're going to cover that. And also, finally, as I said, I've I I invested no little bit of time in, you'll hear, you'll hear the term bureaucracy used more times probably than you know any large word in this podcast, because, boy you know, I guess any kingdom that's been around as long as the United Kingdom has continued to survive has also developed quite a system of bureaucrats, and they're all you know. They all want to weigh in on Google's plan. So, anyway, I think, another great podcast for our listeners and a picture of the week that's kind of a hoot too.

0:03:48 - Leo Laporte
Oh good, always enjoy the pictures of the week. Well, security now is ready to get underway. I hope you are as well, boys and girls, cats and kittens, club members and others. Now you club members, you don't have to hear this because it's time for a commercial. Our show today brought to you by.

You know the name Melissa, the data quality experts Since 1985, did you know Melissa's global address verification and validation service? I mean when they say global, they mean it works in 240, 240 plus countries and territories. I didn't even know there were that many. Now why is that important? Well, no matter where your business is located, now you can improve deliverability worldwide, reduce costly errors. You can boost your address data accuracy everywhere, increase delivery speed, boost ROI. It is ultimately all about the return on investment. That's why Melissa offer free trials, sample codes, flexible pricing. They know your bottom line is important to you. They also know your data is important to you and Melissa secures your data with the highest quality standards. They are FedRAMP authorized. Now that's a huge deal. Of course, it doesn't matter if you're not a government agency, but everybody benefits from that security level. It's the best you can get. All Melissa users benefit from that Also. Of course, melissa's solutions and services are GDPR and CCPA compliant. They meet SOC 2 and HIPAA high trust standards. So your information is absolutely secure with Melissa. But they can do so much with it to really improve your customer data, and better customer data means a better bottom line.

Download the free Melissa lookups apps if you want to try it. They're on iOS and Android. They're absolutely free. Melissa lookups with an S. You don't even have to sign up. You can validate addresses and personal identities in the US or Canada. You could check global phone numbers, global IP address information and more. It's really a handy little tool. Get started today 1,000 records cleaned for free. Just to give you a sample of what Melissa can do on-prem in the cloud as a SaaS application. They have an API so you can build it into your own software. Go to melissacom slash twit to know more Melissa M-E-L-I-S-S-A melissacom slash twit and we thank him so much for the support of the good work, the important work that Steve's doing right here at Security Now.

0:06:16 - Steve Gibson
Well, the important work will be appearing shortly.

0:06:21 - Leo Laporte
Hey, this is important work. Do not knock this work.

0:06:25 - Steve Gibson
Now we have a picture our picture of the week from somewhere looks like in the US Southwest. There's no signs of any telephone poles or structures. So you know, we're kind of out in the desert somewhere, and so one of the things that people want is they want their cell phones to work out in the middle of nowhere. And actually this is a problem I have with many movies these days, which seem to forget that it's necessary to have a cell tower not too far away from where your cellular device is in order for it to get any connection. You know, we see people wandering out in the middle of literally nowhere and they're on the phone, unless the riders don't want them to be, in which case they're holding the phone up, you know, scanning around trying to find a signal.

Well, the way we solve the problem of people wanting cell phone coverage wherever they are yet nobody wanting to despoil the landscape as a means of providing it is we come up with stealth cell phone towers, and I'm not sure how truly stealthful this is, because it looks a little square to be a cactus is because it looks a little square to be a cactus, but I gave this picture the caption. Oh, don't mind us. We're just putting the lid back on the cactus, because this is clearly a cell phone tower cactus, which is meant to mean it. Actually, you know it's got the little extra what do you call it? Arm off the side of the cactus, looking a little more to make the whole thing look a little more cactus-like.

And actually you could see some other cacti in the neighborhood that look decidedly less mechanical than this one.

0:08:22 - Leo Laporte
I have to say, all over Mexico you see these saguaro cactuses, and I guess the southwest as well. So you know, you see it with a hundred others. You probably wouldn't look twice. It's actually a clever way.

0:08:32 - Steve Gibson
It's certainly not, you know, an eyesore, looking like this thing would look like with the lid off, which we can see here, because the lid is off and the crane has lifted the lid off the cactus.

Anyway, I just got a kick out of this and I've seen fake palm trees and I know that here on the so-called sort of now the famous 405 in Southern California, there are power lines that run alongside the freeway and very often there's a big cluster of cell equipment on these power lines because it's a perfect place for them to be. There's already a right-of-way, there's some ability to run a service vehicle along the back and so forth. And many, many, many moons ago, back in the Spinrite actually it was after Spinrite 2, because I remember I was working on Spinrite 3, I built a building in Aliso Viejo to a corporate headquarters 20,000 square feet, two stories and 1.43 acres of land, and so forth. Wow, Anyway, the cell companies came to me and said, hey, this building is like up on a point on a bluff, looking out over this valley. You can make some extra money by letting us put some cell things along, you know, like ringing along the edge of your roof. Well, you know what my answer was.

0:10:12 - Leo Laporte
You said no, it was the same answer.

0:10:13 - Steve Gibson
You said no. I said no why? This is a beautiful building. I'm not going to have, you know, warts of self crap all over the floor.

0:10:21 - Leo Laporte
I bet they're there now, Steve. They are crap all over the.

0:10:24 - Steve Gibson
I bet they're there now, steve, they are, they are. I mentioned that because I drove by not long ago, you know, looking wistfully up at the building, and there it was. Just I don't know, I don't think you could. You could get more cell tower crap around the perimeter of this roof than there is there now, but not while I was in control, but immediately after I left, yeah, anyway, uh, such as the world, you know, and that's why I also have no ads on my site. Uh, mark thompson made a case, he said at one point. He said, steve, there's something wrong now with a website that doesn't have ads.

0:11:01 - Leo Laporte
Yeah, yeah, what's wrong with?

0:11:02 - Steve Gibson
you. No, thank you. Anyway, I wanted to start off this week by sharing an important piece of interesting news that's not Internet security related but is nevertheless potentially quite a big and serious issue in the real world. Last Thursday's headline in Wired was the dangerous rise in GPS attacks With the subhead. Thousands of planes and ships are facing GPS jamming and spoofing. Experts are warning these attacks could potentially impact critical infrastructure, communication networks and more. Okay, so I thought that was interesting. It got my attention. They said the disruption to GPS services started getting worse on Christmas Day, meaning at the end of 2023.

Planes and ships moving around southern Sweden and Poland lost connectivity as their radio signals were interfered with. Since then, the region around the Baltic Sea, including neighboring Germany, finland, estonia, latvia and Lithuania, has faced persistent attacks against GPS systems. Tens of thousands of planes flying in the region have reported problems with their navigation systems in recent months amid widespread giant jamming attacks, which make GPS inoperable. As the attacks have grown no surprise to anyone, russia has increasingly been blamed, with open source researchers tracking the source to Russian regions such as Kaliningrad. In one instance, signals were disrupted for 47 hours continuously. On Monday, marking one of the most serious incidents yet, airline Finnair, canceled its flights to Tartu, estonia, for a month after GPS interference forced two of its planes to abort their landings at the airport and turn around. Talk about dependence on GPS. Apparently, you just can't land anymore without it. The jamming in the Baltic region, they wrote, which was first spotted in early 2022, is just the tip of the iceberg. In recent years, there's been a rapid uptick in attacks against GPS signals and wider satellite navigation systems known as GNSS, that's, you know, generic satellite navigation, including those of Europe, china and Russia. The attacks can jam signals, essentially forcing them offline, or spoof the signals, making aircraft and ships appear at false locations on maps, which you can imagine might be even more damaging than just jamming outright. Beyond the Baltics, war zone, areas around Ukraine and the Middle East have also seen sharp rises in GPS disruptions, including signal blocking meant to disrupt airborne attacks, which actually, as we'll see a little bit later, I think is the actual goal of this. Because of the degree to which drones are now using GPS Wired wrote.

Now, governments, telecom and airline safety experts are increasingly sounding the alarm about the disruptions and the potential for major disasters. Foreign ministers in Estonia. The disruptions and the potential for major disasters. Foreign ministers in Estonia, latvia and Lithuania have all blamed Russia for GPS issues in the Baltics this week and said the threat should be taken seriously. Jamie Adamson, the chief of public affairs for the Swedish Navy, told Wired quote it cannot be ruled out that this jamming is a form of hybrid warfare with the aim of creating uncertainty and unrest. Of course there are concerns, mostly for civilian shipping and aviation, that an accident will occur, creating an environmental disaster. There's also a risk that ships and aircraft will suspend their traffic to this area and thereby affect global trade. Joe Wagner, a spokesperson from Germany's Federal Office of Information Security, told Wired a growing threat situation must be expected in connection with GPS jamming. Wagner said there are technical ways to reduce its impact. Officials in Finland say they've also seen an increase in airline disruptions in and around the country, and a spokesperson for the International Telecommunication Union, a United Nations agency, told Wired that the number of jamming and spoofing incidents have increased significantly over the past four years, and interfering with radio signals is prohibited under the ITU's rules. Gee, you think Russia is slowed down by a NATO agency, the International Telecommunications Union, saying well, you shouldn't be doing that right.

Attacks against GPS and the wider GNSS category come in two forms. First, gps jamming overwhelms the radio signals that make up GPS and make the systems unusable. Second, spoofing attacks, which actually are far more sophisticated, can replace the original signal with a new location. Spoofed ships can, for example, appear on maps as if they're at inland airports, and actually that did happen recently. Both types of interference have increased in frequency. Disruptions, at least at this stage, mostly impact planes flying at high altitudes and ships that can be in open water, not people's individual phones or other systems that rely on GPS.

Within the Baltic region, 46,000 aircraft showed potential signs of jamming between August 2023 and March this year. According to reports and data from tracking service GPS Jam. Benoit Figue, an academic at the Zurich University of Applied Sciences who also runs a live GPS spoofing map there is such a thing says there had been an additional 44,000 spoofing incidents logged since the start of this year. Earlier this month, more than 15,000 planes. Earlier this month, more than 15,000 planes had their locations spoofed to Beirut Airport. According to data that Figue shared with Wired, more than 10,000 were spoofed to the Cairo Airport while being over the main runway at Simferopol International Airport in Crimea, ukraine. The airport is around 19 miles inland from the Black Sea, where it's believed the ships were actually located. So yeah, it's no longer possible to believe what GPS is showing you. You need to look out the window and see where you actually are.

Zach Clements, a graduate research assistant at the University of Texas here in Austin, said the biggest change in the past six months is definitely the amount of spoofing. As I said, spoofing is far more sophisticated and difficult than just jamming and potentially far more dangerous, he said for the first time we're seeing widespread disruptions in civil aviation, especially in the Eastern Mediterranean, the Baltics and the Middle East. In prior years there were reports of spoofing impacting marine vessels, but not aviation. Clements says there appear to be three spoofers that can be traced back to Russia. One open-source intelligence analyst going by the pseudonym Marcus Johnson has located jamming in the Baltics and that which impacted the Finnish airline this week. So that was the one that was causing them trouble to Kaliningrad and other Russian locations. One research group has suggested disruption near Poland impacted Russia's own GNSS system less than others. Not surprisingly, russia doesn't want to hurt themselves, they just want to disturb everybody else, and Russia has a long history of interfering with GPSS signals, both within its borders and internationally. Russia's embassy, not surprisingly in the UK did not respond to a request for comment.

The disruptions can cause uncertainty and potential safety issues for airline pilots and their passengers. Yeah, no kidding. A spokesperson for Eurocontrol, a European aviation organization with more than 40 countries as members A European aviation organization with more than 40 countries as members says its analysis shows disruptions are happening in the eastern Mediterranean areas around Ukraine and the Black Sea, as well as the Baltic states. During one week in March, 4,387 aircraft reported issues. 187 aircraft reported issues, the Eurocontrol spokesman says. For the same time, last week there were 2,646 flights reporting problems. The Eurocontrol spokesman says planes can fly safely without GNSS, but interference quote puts a higher workload on pilots and air traffic control.

A safety notice issued by the UK Civil Aviation Authority this month says loss of GNSS, which is just, you know, general satellite-based navigation, can result in serious navigation issues, incorrect emergency terrain warnings that the plane is too low to the ground and failure to various other systems. And finally, in a NASA report detailing GPS instance that was also published this month, one pilot said I have flown with crew members who were not fully aware of this problem. Other pilots said they'd received false terrain warnings that caused them to pull up. That's not good. Yes, and the pilot should have a thorough review of jamming effects on the different aircraft systems as part of their training. And here's the problem, of course, because this is a relatively new phenomenon relative to when the pilots were trained relatively new phenomenon relative to when the pilots were trained. It may just be the fact that the pilots are trusting their avionics and not being sufficiently skeptical. So it does look like these GPS disruptions are coinciding with Russia's full-scale war in Ukraine, and also it looks like Israel's attacks in Gaza have also been tied into this. As we know, disrupting GPS as part of electronic warfare has become common on Russia and Ukraine's battlefield as a way to try to limit the operation of drones, and while Iran launched a barrage of missiles and drones against Israel last month on the 13th Israeli GPS disruption designed to limit the impact of the attack also impacted mapping and taxi services, as well as food delivery. So here was an instance of Israel doing some GPS jamming, which was somewhat indiscriminate, and the mapping and taxi services, as well as food delivery within their own country, took a hit as a consequence.

Kevin Henka writes Wired, the founder of cybersecurity company Hensec, whose work includes detecting GPS disruptions. Company Hensec, whose work includes detecting GPS disruptions, says jamming and spoofing technology has become cheaper and smaller over the years to the extent that individuals can install them in their cars to hide their own movements. That is, you know you're blocking your own GPS receiver, so your car doesn't know where it is. However, henke says, more sophisticated attacks use equipment that can cost huge sums. Yes, anytime you're doing spoofing.

As I said, spoofing is a whole another level than just blanket jamming, he said. In conflict zones, in military terms and in professional terms, this spoofing is very sophisticated and it always goes hand-in-hand with jamming. Okay, so, since both the jamming and the location spoofing disruptions are enabled through the use of very powerful local radio transmitters which overwhelm the reception of the authentic signals being beamed down from the GPS satellite systems in orbit, so long as you're not in the region of the Baltics, you know where Russia appears to have taken, you know serious action to create major disruptions. The good news is these attacks are inherently local in nature. You know, here in the US we're not being affected by it at all, as is most of Europe. They are inherently very local.

But the problem for those who are in the region is that GPS and the wider GNSS, which again Global Navigation Satellite System, have always been incredibly reliable sources, and not just of location but also of time.

They are master sources of, essentially, time of day and, as we know, when something is both very useful and has earned the reputation for also being very reliable I mean, you know, these things are up in the sky beaming down at us they end up creating a strong dependence, we end up becoming very dependent upon them. Non-military commercial systems have become so reliant upon GPS that the deliberate disruption of that service for military purposes, such as Russia, as has likely been perpetrating, can cause dramatic collateral damage. The GPS system, which is put up by the US, was conceived quite a while ago, a little over 50 years ago, back in 1973. It took five years to package this in the first satellite that began launching at that time and today we have 24 satellites up in the GPS constellation. They've been up and operating since 1993. And talk about depending upon something that's more fragile than we might want. Our phones and automobiles today only know where they are, largely thanks to GPS signals coming from space. We've talked about the-.

0:26:22 - Leo Laporte
I only know where I am thanks to GPS signals. Forget the car. Yeah, I can't drive without GPS.

0:26:30 - Steve Gibson
And I'm sure you know sports wristwatch, you know health tracking wristwatches are doing the same thing.

You know, and you know we have recently been talking about the militarization of space and the idea that having satellites attacking one another up there is no worry of James Bond science fiction. You know, it's actually happening. In some cases, robot satellites are there in order to repair others, in order to repair others. But the same robot that can function, you know, to fix a broken antenna, can also go over and break one off of some other satellite. So you know, unfortunately they also have multiple purposes and unfortunately, as global political tensions increase, we can hope, and we need to hope, that no major powers having space-based military capabilities nor the ability to kill satellites from the ground believe that denying the entire world these benefits would create an advantage for them, because it's difficult now to conceive of a world where, you know, GPS was just shut down. It was like destroyed deliberately by a power hostile to you know. It wouldn't even necessarily have to be hostile to the US. It could be, you know, because everyone's using GPS. Killing it for everyone also succeeds in killing it for a specific targeted country. Before GPS, the only way for something to know where it was was through a system of inertial navigation. Inertial navigation, like its name suggests, is a closed system which relies upon the system's precise measurement of its own linear and angular accelerations. It integrates those over time to determine its velocities and then integrates those over time to determine its position. Even though inertial navigation systems are still in use, due to the nearly instantaneous position and especially angular feedback that they provide, the errors that tend to creep in over time can only be eliminated with the use of slower but far more accurate input from the global GPS system.

I suspect Russia's primary concern is with the use of autonomous military drones which may rely upon GPS to determine their in-flight location.

But since the risks presented by GPS jamming although they haven't been prevalent and it hasn't been a big concern for airline pilots until recently, especially operating over there, in the east, in the Baltic areas Since jamming has been a possibility for some time, I suspect that the latest technologies are much more immune to GPS outages than those in Russia might wish. Given all of the advantages and the advances made in vision and in real-time recognition, I would be surprised if the latest autonomous technologies were not able to fly nearly as well by sight as they can these days by GPS. They might well use GPS as a first choice, but use vision to detect location spoofing, while also being able to switch to pure vision if GPS should fail completely. And another likely strategy, which, again, you don't worry about or deal with until it becomes a problem is that, since GPS signals will always be originating from above, is that, since GPS signals will always be originating from above, would be to shield any GPS receiver and its antennas, oh, from below?

0:30:31 - Leo Laporte
Yes, because the jammers are on the ground.

0:30:35 - Steve Gibson
Exactly that's clever, yeah, so planes can do that because they're well above ground. Unfortunately, it's probably not practical for ships at sea.

0:30:46 - Leo Laporte
Yeah, I mean, when you listen to ground air traffic control talking to an airplane which I used to always do on United Channel 9, used to love to do that they often have visual markers. You know they say turn right at, you know the big rock, candy mountain and things like that. And I don't know if they still do that. I haven't listened in a while but I bet they do. I mean, there's always, you always want redundancy in in any system like that, right?

0:31:14 - Steve Gibson
yeah, and of course, the problem is that you know, we all, you know. Okay, I remember, leo, when, the when I guess this must have been in Driver Ed we were supposed to go out and walk around our car to check all four tires. Yeah, we don't do that anymore. No, do you do that? It was the last time anybody did that.

0:31:40 - Leo Laporte
Pilots do that, commercial jet pilots do that and I thank goodness that they do. I think that's really great. But no, I haven't done that to my car in a while.

0:31:48 - Steve Gibson
I figure if it's flat I'll know right it'll go frum, frum, frum but I do remember being told that's what we're supposed to do. So here we have a problem where Jeep has been so reliable and relied on that. I'm just hoping. I mean the the in this nasa report last week where one of the guys said you know, I've been with flight crews that just assumed that the gps was telling the truth, even though they were suddenly being told to pull up because you're about to hit the rock candy mountain and that would not be good.

0:32:28 - Leo Laporte
Pull up.

0:32:28 - Steve Gibson
Pull up but there's nothing there. So, Leo, let's take another break, and then we're going to talk about whether the sky is falling on all VPN systems. Yeah, as the tech press seems, to believe.

0:32:39 - Leo Laporte
I was counting on you to cover this because I read the stories. Thank God you're covering it before I actually did the stories. Keep me out of trouble, please. We are very proud to say that our show, this portion of the show, brought to you by Collide. We're going to meet with Collide tomorrow at RSA. Great people with a great product. In fact, I was so happy when I heard and maybe you heard too that Collide was just purchased by 1Password. That's really good news. Two companies leading the industry in creating security solutions that put users first. They belong together.

For over a year we've been telling you about Collide Device Trust, helping companies that use Okta make sure that only known and secured devices can access the data right. Okta authenticates the human, collide authenticates the hardware. That's a big deal and they're going to still do that as part of 1Password. In fact, they're going to even be better at this. If you've got Okta and you've been meaning to check out Collide, this is the time, absolutely. Collide is easy to get started with. They come with a pre-built library, a pre-built device posture check, so you can get up and running right away all the basic stuff you would want. But if you have some specific devices or software or situations you'd like to check for. It's very easy to write your own custom checks for just about anything you can think of. Another point I really like you can use Collide on devices without MDM. That means your Linux fleet or your contractor devices. You can't tell them put our MDM on your device. And, of course, every BYOD phone and laptop that sneaks into the company. All of them can be protected by Collide.

Now that Collide is part of 1Password, it's only going to get better. This is the time to check it out. Collidecom slash security now. Learn more. Watch the demo today. K-o-l-i-d-e dot com slash security now. And if you're at RSA, go visit them. They're at us RSA too. I think it starts tomorrow in San Francisco, collide. Thank you, collide for supporting Steve and his very important mission. Now what's all this about? Vpn, steve.

0:34:51 - Steve Gibson
Okay.

So yesterday Ars Technica got a little carried away in their reporting of what amounts to a clever hack that a Seattle Washington-based pen testing firm known as the Leviathan Security Group posted in their blog, and of course the rest of the tech press picked up on it quickly too. The blog posting carried the headline how attackers can decloak routing-based VPNs for a total VPN leak, and what I found curious was that they assigned they meaning the Leviathan Security Group assigned a CVE number to their discovery, even though nothing about this is a bug or a flaw oh, it's just a clever local exploit of a little used feature of dhcp servers. Unfortunately, ours technica's headline for their story was novel, headlined, novel attack against virtually all vpn apps neuters their entire purpose. Ah, run away, okay, which of course makes this sound more like the end of VPNs as we've known them. It isn't. Here's what's going on, okay, so I'm going to do a bunch of propeller head cool stuff in order to get a real grip on this.

Our PCs all interact with both internal and external networks through network interfaces. Most systems typically have a single physical network interface or NIC, but it's possible for a machine to have more than one physical network interface, with each interface connected to different physical networks. In that case it's important for outgoing network traffic to know which physical interface any given packet should be routed out through. To answer that question, our machines contain a routing table. The routing table performs a most specific match function based upon the destination IP address. And in years past we talked about internet routing tables and all of this, so we've covered this in detail. But the key here is most specific match and that all of our PCs, every one of them, pads, phones, you name it anything that's networked using Internet protocol, ip protocol, has a routing table. Route space print will display a list of the system's interfaces, followed by the IPv4 and IPv6 routing tables respectively. And they're interesting and you can get a sense for the fact that there's a lot going on under the covers that you know, we don't appreciate, we normally don't even see. That you know, we don't appreciate, we normally don't even see. Okay, so this set of network communication, that is, ip-based network communication, comes in so handy that, in addition to true physical interfaces, many of our machines will have one or more virtual network interfaces. In fact, you know the so-called local host, local host 127.0.0.1, that's a virtual network interface that all stacks have and, for example, the use of virtual machines has become very popular and they create their own virtual network interfaces to talk to their host machine as well as to the outside world. Okay, so here's the main point.

Many VPNs, like OpenVPN, for example, operate by creating their own virtual interface in the hosting machine. It looks like and operates like any other network interface, but being a VPN, a virtual private network which is used to transact privately with encryption. Any packets sent out of that virtual interface are first encrypted, then rerouted out of an actual physical interface to be sent to the VPN's matching endpoint. Since the typical VPN user, while using a VPN, wants all of their machine's traffic to be tunneled through the VPN, when the VPN tunnel is brought up, the VPN software dynamically edits the system's global routing table in such a way that, instead of the system's traffic by default being routed out through its normal, actual physical interface, all of its traffic is instead routed to the VPN's software-created virtual network interface. This is the way that, deep down inside the guts of our machines, all of the traffic that's normally unencrypted suddenly becomes encrypted when we activate our VPN. Essentially, it's like a man in the middle it sticks a shim into our network so that all of the traffic that would normally just go straight out the physical interface instead is routed to the VPN. And that's done, as I said, by making just a slight change to the routing table, so that all of the traffic, instead of going out the physical interface, goes to the VPN, so that all of the traffic, instead of going out the physical interface, goes to the VPN. We need one other piece of information, just to be certain that everyone's on the same page.

Dhcp stands for Dynamic Host Configuration Protocol. By default, when any networked machine boots up and gets itself going, it needs to be using an IP address for itself on its local network that's unique for that network, and it needs to know the IP address to which it should address packets bound for the outside world, in other words, the network's gateway IP. It may also want to know the IP addresses of some DNS servers that will honor its requests for domain name lookup. It's the network's inward-facing DHCP server that answers all these needs. When any network machine starts up, by default it will emit a broadcast packet onto the network announcing its presence and asking for any listening DHCP server to please provide it with all the information it requires to become a well-behaving citizen on the local network and to connect to the rest of the global Internet.

Dhcp cleanly organizes the various types of information it can supply to the clients who are requesting it by number. Each one of these is known as an option, where the option number is a single byte, thus having a value from 0 to 255. 0 is a null option and it can be used for padding. 255 is the marker for the end of the list of options. So the options are provided as a list of information, terminated by option 255, which, of course you know is a byte of all ones. So, for example, option one provides the network's subnet mask to the requesting client.

Option two specifies the offset of the client's subnet in seconds, that is, in real time, from UTC Coordinated Universal Time. Option three specifies a list of the IP addresses of routers on the client's subnet. You know what we know as the gateway IP. Option four specifies a list of time servers which are available to the client. Number six provides a list of DNS servers for the client's use, and you know there's there's a bunch of them, all kinds of different things that have been added through the years, and there are even some surprises, for example, options 69 and 70 provide the IP addresses of SMTP and POP3 email servers, which I thought was kind of cool. You know, we're all used to specifying those ourselves, but back in 1997, when this was first created, that information was available via DHCP.

Something else that DHCP was able to provide is the source of today's trouble. The RFC's definition for option 33 defines it as the static route option and says, quote this option specifies a list of static routes that the client should install in its routing cache, in its routing cache. Okay, now everybody who's been paying attention and, you know, enjoys networking stuff just went aha and knows what the problem is. This thing continues If multiple routes to the same destination are specified. They are listed in descending order of priority. The routes consist of a list of IP address pairs. The first address is the destination address and the second address is the router for the destination. Again, if some of you just said, oh crap, that would be the correct reaction. What this means is that the response from a DHCP server can be used to mess with a machine's routing table and, as we noted earlier, a machine's traffic is routed to the VPN's virtual interface through a dynamic modification of the machine's routing table.

Now, as it happens, option 33 is not really the problem, because it was defined back in 1997 when IP networks were all class A, b or C. That meant that networks were defined to always have exactly one, two or three bytes of host machine addresses. As we know, this was extremely wasteful of IP addresses for networks falling into intermediate sizes. So something known as CIDR, c-i-d-r, which stood for classless inter-domain routing, was adopted of contiguous bits set, thus allowing scaling of networks by factors of two, all the way from one machine well, technically up to 4.3 billion. But no one network has that, except the Internet itself. Okay. So the adoption of CIDR obsoleted option 33, forcing its replacement five years later, in 2002, under the guidance of RFC 3442, which introduced option 121, which allows for exactly the same thing, but under the specification of classless static routes. Now I mentioned that I was surprised that these Leviathan Security Group guys had arranged to get a CVE assigned for this, since technically this is a feature, not a bug.

And all the way back in 1997, the fundamental vulnerability of DHCP was quite well understood. Again, 1997, section 7 of the original RFC 2131, dated March of 1997, is titled. It was Section 7 seven security considerations. It says, dhcp is built directly on UDP and IP, which are as yet inherently insecure. Furthermore, dhcp is generally intended to make maintenance of remote and or diskless hosts easier. Make maintenance of remote and or diskless hosts easier. While perhaps not impossible, configuring such hosts with passwords or keys may be difficult and inconvenient. Therefore, dhcp in its current form which, by the way, is the form it has today, in 2024, because you know if it's not broke in its current form is quite insecure, says the RFC from 1997.

They said unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients, such as incorrect or duplicate IP addresses, incorrect routing information, including spoofing routers, etc. Incorrect domain name server addresses to spoof name servers, and so on. Clearly, they wrote, once this seed information is in place, an attacker can further compromise effective systems. Okay, so here's how the Leviathan folks described the attack they've devised by abusing Option 121. They said Our technique is to run a DHCP server on the same network as a targeted VPN user and to also set our DHCP configuration to use itself as a gateway when the traffic hits our gateway.

We use traffic forwarding rules on the DHCP server to pass traffic through to a legitimate gateway. While we snoop on it, we use DHCP option 121 to set a route on the VPN user's routing table. The route we set is arbitrary and we can also set multiple routes if needed. By pushing routes that are more specific than a slash zero CIDR range that most VPNs use, we can make routing rules that have a higher priority than the routes for the virtual interface the VPN creates and, as we know, because that means it's a more specific route. So the routing system ends up routing to the intercepting DHCP server rather than to the user's VPN. They said we can set multiple slash one routes to recreate the 0.0.0 slash zero all traffic rule set by most VPNs.

Pushing a route, they wrote, also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that is not clearly stated in the RFC. That is not clearly stated in the RFC. Therefore, for the routes we push, it is never encrypted by the VPN's virtual interface, but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface, talking to our VPN or our DHCP server. So in other words, they're able to literally select by destination IP. If they don't want everything, they can say, ah, just give us this chunk of your traffic. You think it's going through your VPN, but it's not.

They said we now have traffic being transmitted outside the VPN's encrypted tunnel. This technique can also be used against an already established VPN connection. Once the VPN user's host needs to renew a lease from our DHCP server, we can artificially create that scenario by setting a short lease time in the DHCP lease so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication, that is, you know, the control channel, meaning the channel to the remote end that is, outside of the tunnel. They said in our testing the VPN always continued to report as connected and the kill switch was never engaged to drop our VPN connection, meaning there was never a panic that the VPN was concerned that it was being intercepted and so shut things down. So then, to their credit, they raised the question that we've had all along by asking is tunnel vision a vulnerability? And I appreciated their answer.

They wrote this is debatable. We're calling it a technique because tunnel vision doesn't rely on violating any security properties of the underlying technologies. Routing tables and VPNs are intended to work. However, it contradicts VPN providers' assurances that are commonly referenced in marketing materials. In our opinion, tunnel vision becomes a vulnerability when a VPN provider makes assurances that their product secures a customer from an attacker on an untrusted network. There's a big difference between protecting your data in transit and protecting against all LAN attacks. Vpns were not designed to mitigate LAN attacks on the physical network, and to promise otherwise is dangerous. In our technique, we have not broken the VPN's cryptographically secured protocol and the VPN is still fully functional. An attacker is instead forcing a target user to not use their VPN tunnel. Regardless of whether we classify this as a technique, vpn users are affected when they rely on assurances that a VPN can secure them from attackers on their local network. Hmm, interesting.

0:54:46 - Leo Laporte
Finally, yes, Because that is one of the primary uses, isn't it for a coffee shop and other open Wi-Fi networks? Exactly?

0:54:52 - Steve Gibson
Okay, but this has been around forever. So yes, exactly, and they finished. As for what systems are affected, the short version is everything except Android. Isn't that funny? Android doesn't support option 121, so it's completely excluded from these attacks. Isn't that wild, they wrote. In our testing, we observed that any operating system that implements a DHCP client according to its RFC specification and has support for DHCP option 121 routes is affected. This includes Winix, this includes Windows, linux, ios and macOS, notably, they wrote. It does not affect Android, as they do not have support for DHCP option 121, which really is interesting.

I do too, because I did some digging and there have actually been instances where Android's lack of option 121 support has caused problems for Android users. Because it turns out this is not obscure, leo. This is the first time we've ever talked about it on the podcast, because it's just never come up. You know we've covered DHCP in depth in the past. It's just never come up. You know we've covered DHCP in depth in the past. Okay, so just to be clear about the scope of the danger presented by the potential abuse of DHCP's option 121. This is strictly a local land side attack. But, leo, as you correctly point out, you know we do operate in essentially land networks where we're assuming a VPN is going to trust us where untrusted peers are on the same land we are. So that's a thing thing. The attacker needs some means of defeating the network's actual DHCP server, since DHCP clients will and do accept the first reply to their query. Simply being faster to reply is typically all that's needed. And you know, as we know, most routers use the slowest chip that the manufacturer was able to get away with. Boy, I tell you, those web interfaces on routers it's like okay, I click the button hello, hello, did you. You know, should I click it again or just wait? No, so the point is it's not going to be quick to fire off a DHCP reply because it doesn't need to right. That's going to be way down the priority queue of traffic that it needs to deal with. So an attacker probably doesn't have much difficulty being able to respond with DHCP queries faster, being able to respond with DHCP queries faster. So it's definitely conceivable also in an enterprise environment that if you had somebody untrusted on an enterprise network that would be a problem. And it also turns out that option 121 is not the least bit obscure in the enterprise. It turns out it's under heavy use. I found two little samples through a quick search. A posting over on Stack Exchange says I'm running OpenVPN on a CentOS 7 server. The DHCP server on the LAN uses option 121 to tell other devices to use this CentOS server if they want to get to the VPN subnets the OpenVPN server is connected to. This works great. The problem is that this CentOS server is getting these same routes from the DHCP server, which breaks things. And then he goes on to talk about how he can manually remove the static routes that the CentOS server is receiving from DHCP Option 121 is being used to inform machines on the LAN where to route the traffic they want to go through the CentOS 7 servers, vpn subnets. So it's very useful for that. And also, just as recently as last Tuesday, someone posted to the remove whatever poor humans they have that are being forced to respond to forum postings there and put chat GPT-12 or something in there instead. It is excruciatingly bad. Anyway, someone posted and, needless to say, they got no useful answer.

When connected to my office network, its DHCP server meaning his office's network DHCP server will use option 121 to assign three different networks to be reached using a router, which is not the default gateway. This works absolutely. The networks appear in my routing table in active routes. Everything works, networks are reachable, anyway. So he wrote that and I just grabbed that as a little snippet of another example of. Like you know, option 121 is really out there and it turns out has, you know, really been useful. As I said.

He goes on to explain at some length. He's complaining that when he boots his pc without any network connectivity then it has a problem. Uh, yeah, that would be a problem. So anyway, uh, I wanted to point this out again that this DHCP option is in heavy use within more complex corporate networks. What that means is that simply like blacklisting, option 121 is not viable In my opinion.

It would be extremely unlikely for anyone at home to ever have anything to worry about, though it's still instructive to paint a picture. The way I can see this might occur to somebody at home would be if some malicious device were connected to a residential network and wished to capture all of the user's traffic, whether tunneled through a VPN or not. By being the first device to respond to any DHCP query, such a malicious device could establish itself as the network's gateway to receive, inspect and forward all traffic from the network's many machines and then, by additionally using option 121, such a device could use that to also insert entries into the user's routing table to prevent their VPN, if any, from tunneling the user's traffic. Even though the VPN would show that everything was working and the users traffic was protected, none of it would be. The VPN tunnel would be up and established, but it would not be carrying any of the users traffic.

Since there are many environments where option 121 is not needed and is never used, like probably most of ours at home, I think it would be nice for our operating systems to provide the option to hard disable it, but I dug around and I couldn't find any indication that that's being done. That that's being done, I would imagine the Windows firewall could be configured to look for any incoming DHCP port. What is it? It's been so long, is it 163?

1:03:28 - Leo Laporte
No idea Is.

1:03:28 - Steve Gibson
DHCP? I don't remember now the port number.

1:03:33 - Leo Laporte
The best mitigation would be turn off option 121, but that's not an option for us now. Unless, can VPN software be updated to have that as a feature?

1:03:46 - Steve Gibson
The problem is, this gets in underneath the VPN software. I mean, I suppose it could be updated to monitor the routing table and proactively determine whether or not it's been rerouted. So that's certainly something that it receives. Everything what it would need to do would be to and I guess it actually could would be to send itself a test ping. Ah, there you go From an, from an IP in the user's IP space and verify that its virtual interface receives that ping, right? Um, if it doesn't receive the ping, that tells it something has interfered with the routing between the the uh, the user's local host IP and its own interface. So yeah, that would be a cool feature for a VPN to have.

1:05:04 - Leo Laporte
Meanwhile there's not really a mitigation, is there?

1:05:07 - Steve Gibson
No, no. And I think your use case is exactly the right one, leo, because where do people deliberately bring up a VPN? It's when they're in a hotel, in a cafe, you know, in any untrusted environment, and you know they don't want to be sharing their traffic with everybody else.

1:05:30 - Leo Laporte
Yeah, yeah, I wonder if commonly used hacking tools like Wi-Fi, Pineapples and stuff are able to do this. They probably are. I mean, it's been around for 30 years.

1:05:41 - Steve Gibson
Yeah, but well, oh, so you mean whether they're able to perform the hack. Yeah, I bet that intercepting DHCP is such a juicy target. I mean, I'll bet you that hacking tools actively have DHCP server spoofing and are able to get a response out immediately. Interesting.

1:06:10 - Leo Laporte
Wow, this is good stuff. Thank you Because this has been everywhere, this story, and I was really curious what you thought of it. So it's a problem?

1:06:19 - Steve Gibson
It's not. Again, what are you going to do with a CVE, like hello, like okay? I mean, maybe that gets it more attention. It gets the word out right yeah, Unfortunately, some apparently GPT something is able to read the CVE and immediately design a hack that the script kiddies can then use. So great.

1:06:42 - Leo Laporte
Would you like to take a break? Is that what you're looking at me like that for? I know that. Look, we will have more with Mr Gibson in just a little bit. You know, every week there's a story or two that in my mind and I bet your mind too you go. I wonder what Steve has to say about that. That's, that's why we love you, steve, and that's why we listen to the show. We're so glad to carry the show Um today.

Our sponsor for this segment, lookout. This is a kind of timely. Every company today is a data company, right? We all have data and we're all out in the cloud. We're all out and about.

Every company's at risk with cyber threats, breaches, leaks this is all the new normal and cyber criminals. They're getting better and more sophisticated by the minute, especially with the help of AI. At a time when boundaries no longer exist to work, what it means for your data to be secure has really fundamentally changed, which is why you need Lookout. From the first phishing text to the final data grab. Lookout stops modern breaches as swiftly as they unfold, whether on a device in the cloud, across networks, even working remotely at the local coffee shop, which now we know is a little hazardous. Lookout gives you clear visibility into all your data, at rest and in motion. You'll monitor, assess and protect without sacrificing productivity and employee happiness for security. With a single, unified cloud platform, lookout simplifies and strengthens. For me, imagining security for the world that will be today.

Visit lookoutcom today to learn how to safeguard data, secure hybrid work and reduce IT complexity. That's lookoutcom. Thank you, lookout, for supporting Steve and the work he does here, and thanks also to all of our Club Twit members whose donations make this show possible. You know, if you find this valuable and you're not yet a Club Twit member, it's just seven bucks a month. We have corporate memberships too. Get your whole company involved. Probably everybody in your IT department should be listening to this show every darn week. Go to twittv slash club twit to find out more. And to those of you who are already members, thank you. We appreciate your support. On we go with Mr.

1:09:02 - Steve Gibson
G. Okay, so a bit of feedback. Dave Brenton tweeted Mr Gibson quickly. May I say, as a machine language coder, I admire your work in that area.

I'm a Spinrite owner, user and longtime fan since near the beginning of Security. Now my question is about security keys. I hope this is not too long a question, and it wasn't. He says I'm about to make the transition to YubiKey and so I intend to purchase two to have a safe fallback in case of loss. I'm also planning to convert the wife over to the passkey world.

My question is can the passkeys be paired across two user accounts, thereby ensuring recovery in case of loss with only three keys? My mental model says it made sense, but I do not know for sure. One can the same key be applied to two different people? Two to assure full backup protection, can all three keys be coded into both users? It may be a silly notion, but it could work. But could it work? Or should I just buy four keys to begin with? Thank you for all your good work and propeller head installments. On to 999 and beyond. Yes, dave, yes, and I said at the beginning of the show on episode 973, we are closing in on 999. Yet we're no longer fearful of that fatal number.

1:10:29 - Leo Laporte
We'd be sad. Hey, before you get to the answer, I just want to actually do the answer and then I want to ask you about machine language and assembly. I had some questions.

1:10:39 - Steve Gibson
Oh cool, go ahead. Okay. So I chose to share Dave's question because it so perfectly demonstrates the near total mess the user authentication world has fallen into today. It really has. It is just a catastrophe. Has fallen into today. It really has, it is just a catastrophe.

I'm hopeful this may just be a transition phase, but, truth be told, all of our collective experience also leaves me feeling somewhat skeptical. I worry that all we have done by adding the FIDO group I'm sorry, by having the FIDO group lower the bar for entry from requiring physical key dongles to allowing pretty much anything else smartphones and PCs running simple software passkey clients is to expand upon the number of available options with an additional and difficult as it is to believe in this day and age not very well thought out system. And we've added this new and not well thought out system without removing any of the previous options. Have traditional username and passwords been replaced? No, are they ever going to be? Not in this lifetime. Have the I forgot my password links gone away? No, are they ever going to? No. What about those time-based, one-time passcodes? Are they going away? No, passcodes, are they going away? No, any plan for that? No. What about OAuth, which brings us the log on with your Google or Facebook or some other account. Have those been obsoleted and removed? Nope, can they be? Well, not easily, since many sites only know their users thanks to their redirection through another web services authentication. And so to this pile of existing half-baked remote network authentication solutions, we're now adding PassKeys, a mysterious new solution that its designers all say is amazing and far more secure, which works sort of like magic, right up until it doesn't work at all. And when that happens, what do we do? Well, we fall back to send me an email.

What we've wound up with is the well-known and often observed phenomenon of solution spread. Of solution spread, we invent a better idea than what we had before. Perhaps it's because the times have changed and the older solutions are no longer adequate, or perhaps we have more technology and available processing power than we had before. So new solutions are available than were previously. But the problem is we rarely are able to kill off the things that came before. Why? Because by the time we can do something more, too many people have come to depend upon the previous solution and the one before that and the one before it.

And this solution spread doesn't just apply to the authentication domain. Just look at Windows, without getting bogged down into the details. Every few years, microsoft comes up with a new and much improved way of writing applications for their Windows OS, and they promote the hell out of it, explaining how and why it's so much better than everything that came before. And do they then kill off the previous ways of programming Windows? No, of course not. They can't. They were once promoting the hell out of those previous solutions and they got lots of people on board using them then. So, even though they no longer love them and are urging everyone to use the new system, that never happens.

I've heard Paul over on Windows Weekly saying that the original Windows API Win32, should have died off long ago. Oh yeah, that's what all of my Windows are written in, you know, and not just mine, a gazillion others as well, and that's gazillion with a G mine, a gazillion others as well, and that's gazillion with a G. I am certain Paul knows that Microsoft will never abandon Win32. They can't, any more than websites will ever be able to stop offering username and passwords with an I forgot how email link. So just to be clear, the industry has added a bright and shiny additional way for people to log into their accounts, but none of the existing ways are or will be removed. Remember Remember that today, in 2024, only one out of every three Internet users is using any form of password manager. I really don't know what the rest are doing. Perhaps these are people whose iOS and Android support for passkeys is mostly aimed at. You know, these people don't know, don't understand and don't care about their online identity. So when Apple or Google comes along and asks how would you like to log in instantly with passkeys and never worry about another password, well that sounds great. But that's not.

Dave, our listener, whose questions launched me into first taking a bit of a rant into a wider view of where we stand today. So let's look at Dave's situation. Dave says he's planning to convert his wife over to PassKeys. I'm sure he means that he would like to have his wife begin to use PassKeys, since it's not possible to convert over to pass keys in any meaningful way when so few websites offer the option at all, the caution there, since we do not yet have pass key transportability, is to be careful about which app is holding a site's passkeys. As I mentioned last week, ios, windows, android and now an increasing number of traditional password managers will all be vying to be the app that generates the passkey to be provided to a website. Since only that app will then be able to authenticate the user to that site with a passkey, the only sound strategy will be to only and always use a single platform for passkeys.

This issue and Dave's other questions require a quick bit of foundation about the operation of passkeys. When an application prompts its user about whether the user wishes to have which never leaves the application and which the application guards carefully and in this case I'm using key and application interchangeably From that closely held private key it then generates a public key and only the public key is sent to and retained by the website. In the future, that website will use the public key it holds to verify the signature of a challenge that it sends to the user's passkey authenticator. So my point here is that today there is no provision for these private keys, which were generated internally and have ever since been guarded by the application, to ever leave that application's control. Conscious organization like Apple can make the defensible claim that, since all of the pass keys security derives from the secretness of these private keys, which is crucial. No other application, including its user can or should be entrusted with their stewardship with the stewardship of the PassKeys private key, since this represents a powerful platform lock-in. It's not at all clear to me that Apple will ever allow for PassKeys export.

That being the case, I think that a very strong case can be made for only ever storing passkeys in a third-party passkeys client, such as a browser extension. In theory, it ought to be possible for a website to allow its user holder of a passkey. If a website supported passkey replacement, it should be possible to migrate away from one passkey application to another. And I was thinking about this. If a website doesn't explicitly allow you to migrate between passkeys, hopefully it allows you to delete a pass key, in which case your account would not be associated with one, and then you could reassociate it with a pass key from the provider that you're wanting to switch over to. So the real point here is that it is the application that generates the passkey. It is never something that we're able to supply from the outside.

So just to put a bit of frosting on this discussion, before we talk about the platforms with hardware authentication doggles, I wanted to share a few points from Google's Chrome FAQ. This is Google's Chrome browser FAQ about passkeys. They start off, of course, with all the glowing bits Under Manage Passkeys in Chrome. They say you can use a passkey to sign in easily and securely with just a fingerprint, face scan or screen lock. Pass keys are a simple and secure way to sign in to both your google account and all these sites and apps you care about. Without a password, you may be asked to sign into a website with a passkey or create one to improve your account's security. Then they have a little tip Passkeys are built on industry standards so you can use them across many platforms.

1:21:45 - Leo Laporte
Gotta love those industry standards, oh Leo that's the happy news.

1:21:50 - Steve Gibson
That all sounds terrific. And of course we ask what here? What could possibly go wrong? Well, here's what Google had to say about that.

Under store passkeys in Windows, they said if you have Windows 10 or up, you can use passkeys To store passkeys. You must set up Windows Hello. Windows Hello does not currently support synchronization or backup, so passkeys are only saved to your computer. If your computer is lost or the operating system is reinstalled, you cannot recover your passkeys Whoops or store passkeys in macOS. You can save passkeys in your Chrome profile, where they're protected by a macOS keychain. Under important, they said Chrome cannot save or use pass keys stored in iCloud keychain. If your computer is lost or your Chrome profile is deleted, you cannot recover your pass keys. And third, you can use a security key to store your pass keys. Important pass keys stored on security keys are not backed up. If you lose or reset the security key, you cannot recover your pass keys.

What a wonderful system. This clearly represents a huge leap forward. Sigh Wow word, sigh Wow. It's clear that, unfortunately, what we have at the moment is an extremely fragile system. The problem is the extreme secrecy surrounding the private keys which create the pass keys. It's true that they do not. I'm sorry. I'm sorry. It's true that they do need to be guarded. Unfortunately, at the moment they're being jealously guarded. How Microsoft could possibly imagine that it's practical to have all of a user's passkeys locked up in a single machine, unable to synchronize with any of a user's other devices, is beyond me. But we're ready to entertain the second part of Dave's question where he asked can the pass keys be paired across two user accounts, thereby ensuring recovery in case of loss with only three keys? He says my mental model said it made sense, but I do not know for sure. Can the same key be applied to two different people? To assure full backup protection, can all three keys be coded into both users? The answer is that not one of those operations dave is asking for is available, not Not one. And what's more I just double-checked.

As we learned last week, yubico's Yubikeys have the most ample storage for passkeys of any hardware passkey dongle in the industry, and even it is limited to a total of only 25. And they are utterly and absolutely non-exportable. A YubiKey is, at its heart, an HSM, a hardware security module. The internal YubiKey dongle hardware contains a very high entropy random number generator that's used to synthesize a unique private key. That private key never leaves the device. There is no way to export it. The exportation does not exist. There's no way to put a passkey in and no way to take a pass key out.

This would not be a problem if sites were to allow multiple pass keys to be registered for a single account, and there's no reason that would not be possible. But how many sites today support the use and management of multiple passwords for a single account? I've never seen one. So it's unclear why support for multiple passkeys would ever be created, even though nothing prevents it.

With YubaKeys having a 25 passkey limit, other than for experimentation, they seem most practical for higher-end, enterprise-grade security applications and perhaps for eventually signing into only a few of the most secure sites where the inconvenience of having an absolute hardware lock is warranted by its ultimate level of hardware-level security.

And, as we noted last week, a YubiKey might be used to unlock a password manager, which is where, we would all have to conclude, all of a user's pass keys should probably be stored.

The only sane conclusion we can draw is that, while this is all very interesting, is that while this is all very interesting, none of this is yet ready for primetime.

Poke at it, experiment with it, but wait until Bitwarden's passkey-supporting mobile clients emerge from their current beta testing state, at which point it will be practical to start depending upon passkeys. It will be practical to start depending upon pass keys because they will be in a single, sane, multi-platform client, and Bitwarden, which is, we should say, a sponsor of the Twit network, will likely be offering backup and support and exportation of those once the security protocol for doing that, which is reportedly underway within the FIDO group, is concluded. So Bitwarden will then generate and hold our passkeys, even when other passkey clients on iOS or an Android might be trying to. And then, of course, as we said last week, the challenge is making sure that your chosen passkey authenticator is universally used, even in an environment where multiple authenticators are all vying for attention. So I have to say it's. You know, the things that reasonable things that people would want to do are not available. They, they cannot be done.

1:28:25 - Leo Laporte
God, wow, yeah, yeah uh, yeah, I saw a uh, there was a news, uh story about uh, somebody wrote about why it's a hundred times harder to implement paskies on your website than you might imagine. I mean, it's just, I think this is going to be. I feel like people are going to throw up their hands and say, okay, fine, never mind, and that's depressing, right, right. And, as we said, last week.

1:28:49 - Steve Gibson
If it doesn't achieve critical mass, then it'll just be exactly as one of our listeners said. No, no, it was the guy who did the Rust web auth in client. He said I feel that this will, you know, it'll be like ad blockers. A small percentage of people take the trouble to do it, but it's sort of a niche and it never really becomes a problem for the ad companies and in this case it just never takes hold. So, speaking, of.

1:29:21 - Leo Laporte
It is a mess. It is a mess and it's not getting any better. This did not solve it. We've been trying. I mean, I remember when Microsoft tried the single sign-on thing 20 years ago.

1:29:31 - Steve Gibson
We've been trying to solve this, and they had something called Passports.

1:29:34 - Leo Laporte
That's what I was talking about Passport Exactly, and they had something called passports. That's what I was talking about passport Exactly. It was a single sign-on, it didn't get adopted and that's that. Yep. Oh well, oh well.

1:29:45 - Steve Gibson
So one last piece of feedback from Willie Scott Before you do that can I ask you a question? Yeah, about assembly language.

1:29:50 - Leo Laporte
Yeah, I was thinking the other day about how one debugs in a higher-level language. You'll write a print statement, for instance, and it'll tell you all your stuff. You must have some macros you've written over the years to help you debug assembly, or do you?

1:30:06 - Steve Gibson
No, I knew it, damn it.

1:30:11 - Leo Laporte
You just write it right the first time.

1:30:14 - Steve Gibson
Well so, not for debugging, but, for example, first time. Well so for not for debugging, but, for example, um, I, um. One of the reasons it would be difficult for me to share my assembler is that I have built up a macro archive things I do right for example, I, I use a macro called zero and it and it takes a, a register name.

Well, it simply expands to x or register, comma register right to zero, because we know, when you x or something, you wait exactly when you x or something, with itself you get zeros. And it's very fast because it doesn't depend upon a memory fetch or any the the previous data or the previous contents of the register. So and the point is, if I wrote X or something, comma, something, I would have to look at it and say OK, x, or, and then look at what, what am I doing? And then realize, oh, I'm wanting to zero that Well, it's much better if I just say zero, right, and then the thing right. So anyway, and and you cannot do that for variables, that, that is, the Intel architecture will not allow you to XOR memory with another memory. You can only XOR register with a register or register with memory, but not memory with memory. So when I have a variable, I use the macro reset which moves a zero into it.

1:31:45 - Leo Laporte
But you don't have any macros for kind of displaying the contents of the stack purely for debugging. You don't have anything like that. You just look at the code and figure out what's going on.

1:31:56 - Steve Gibson
Oh, no, no. So I definitely have a debugger.

Oh god, I oh yeah, yeah, yeah so comes with a debugger right or no, so mazum doesn't, but there were back in the day a bunch of third-party debuggers. Right, I use something called periscope, which was written by a guy named brett salter years ago. I remember that. Uh, he passed away a few years ago. There there was also something called soft ice, which was an ice stands for in-circuit emulator, and in the really old days you would pull the processor off the motherboard and plug in this paddle that then had a cable running to a bunch of things that emulated the processor, that allowed you essentially to get inside the processor. So that was called an ICE, an in-circuit emulator, and so soft ICE was essentially using protected mode to do all the same sorts of things.

So there have absolutely always been debuggers, and one of the banes of developing for Spinrite was that I'm, you know, dos and 16 bits and it was very difficult to create an environment where I was able to have networking in order for my code to get down into the target machine and debugging at the same time. So one of the things I'm really looking forward to as I move to my own environment is, for example, this RTOS32 that will be the home for Spinrite 7. It works with Visual Studio transparently, so I get to just live in a really nice GUI IDE and do all of my debugging.

And what's really cool, leo, I bought so many motherboards and so many random hard drives through eBay when our testers were reporting that on my Jim Crack 27Z it does such and such. It's like, oh my God. So I'd have to go to eBay. Go to ebay a search for gym crack 27e and buy one there's one, yeah, uh, and I would buy one, and so my, my amazing wife put up with having motherboards everywhere for the dining room table, I'm sure so what?

so what's very cool about RTOS32 is it allows internet trans-internet debugging. Oh nice, so if something is happening on that guy's Jim Crack 27Z, I'll be able to actually have him contact me and debug it on his machine. Oh that's really cool.

1:34:34 - Leo Laporte
Wow, yeah, very neat. All right, okay, so you have some pretty good tools. It sounds like oh, that's really cool. Wow, yeah, very neat. All right, okay, so you have some pretty good tools. It sounds like.

1:34:39 - Steve Gibson
Oh yeah, and in fact, one of the things that I've learned is invest in your tooling infrastructure before you do anything. It is so nice to have a convenient debugging environment Absolutely.

1:34:56 - Leo Laporte
On, we go.

1:34:57 - Steve Gibson
I'm sorry, I didn't mean to interrupt, I was just curious. I was debugging the other night and I was thinking I wonder how Steve does this. So now I know yeah, you absolutely have to have a good debugger that allows you to see the stack and the contents of the registers and what's in memory and what your local variables are. All of that is made really very nice with Visual Studio.

1:35:19 - Leo Laporte
Nice.

1:35:20 - Steve Gibson
Okay, willie Scott. He says okay, he has some feedback and advice about the operation of the iCloud keychain, and I bet you he knows what's going on or at least gave us enough of a clue. He said hi, steve, in regards to your discussion of pass keys on last week's show, the part about the author's partner losing her iCloud keychain passwords intrigued me. After the last pass hack, I decided to switch to using iCloud keychain for my passwords because I'm in the Apple ecosystem and wanted to start using passkeys instead of passwords wherever possible. I'm writing to mention that I, too, have had passwords and two-factor authentication codes wiped from my iCloud keychain, although my keychain yeah, exactly, although my keychain has never been fully wiped like the poor partner's keychain did, as near as I can tell. I believe I know the culprit of why it may be wiping credentials from iCloud keychain and wanted to pass this along to anyone who might still be using iCloud keychain to store their passwords or who knows somebody who may.

When I started changing all my passwords and adding accounts into iCloud Keychain, I noticed that an old Amazon password that I don't use anymore was already stored in there, probably from when the Amazon app asked do you want me to remember your password. It was an old password that I don't use anymore, so I deleted it. However, a couple of days later, I noticed that, even though I deleted that password or so I thought it had somehow reappeared in my iCloud keychain. Not only that, but I also noticed that one or two accounts that I had recently added to the keychain were missing, and this process repeated itself a few more times. So that's when I started investigating. While digging through the settings, I went through my Apple ID account settings, and that's when I realized that my old iPhone 6S Plus, which was running an old version of iOS, ios 14 to be exact was still signed into my iCloud account and had iCloud keychain turned on. I removed that old iPhone from my iCloud account and ever since I did that, no passwords have been wiped.

If you're in an Apple ecosystem, it's always a good idea to keep your devices up to date, but it might also be a good idea to do some spring cleaning and remove old Apple devices from your iCloud that you don't use anymore. Having said all that, I sadly was agreeing with a lot of the points you wereen once pass keys become officially supported in Bitwarden using and he says HTTPS colon. Slash slash Bitwarden dot com. Slash twit. Thank you, of course. That's our special sponsor link, yeah, which I think we're about to talk about.

1:38:48 - Leo Laporte
Yes, we are actually Thank you.

1:38:50 - Steve Gibson
Thank you for a great show. I look forward to it each week. I'm also a proud Spinrite owner and can't wait to start using 6.1 on my SSDs and a troubled hard drive. So this mysterious iCloud credential removal has all the feel of something Apple would be deliberately doing out of their typical abundance of caution. I'll bet there's a security model behind it. For example, while an older iPhone is also signed into an account's iCloud keychain, apple might be deliberately limiting what they're willing to save into that shared keychain what they're willing to save into that shared keychain while an older and presumably lower security device also shares access. In other words, it's a feature, not a bug.

1:39:51 - Leo Laporte
I guess it could be that I don't like that kind of unexplained behavior.

1:39:55 - Steve Gibson
However, it sounds like Apple, though, to say oh, we're not going to let you hurt yourself. You know we're going to delete your, you know the keys you've just saved, because otherwise one of your insecure devices might get them.

1:40:11 - Leo Laporte
Oh yeah, yeah, yeah, I'll make sure you always should remove old devices. That's maybe why I've never run into this. I always remove the old devices.

1:40:21 - Steve Gibson
So very interesting. I do happen to have an iPhone 6 right here, wow look at that. It doesn't work anymore.

1:40:29 - Leo Laporte
Look at that home button and think fondly on it, because Apple has, as of today, discontinued all the devices that had home buttons. The last one you could buy was the iPad base model, and that's now been superseded. So the home button is officially a thing of the past, as is the headphone jack, I think.

1:40:50 - Steve Gibson
Is it all facial recognition?

1:40:52 - Leo Laporte
Yeah, it's all Face ID now. Makes sense, let's talk about it, warden, and then I want to talk about your subject matter for the day, indeed what's going on with Google in the UK? What is happening here? Why are they putting off the third-party?

1:41:11 - Steve Gibson
cookie deprecate. Not so fast there, buddy. What's the deal?

1:41:14 - Leo Laporte
man, this portion of the show brought to you by Bitwarden, the password manager. I use, the password manager Steve uses and pretty much everybody I know uses. We were talking on MacBreak Weekly. There's something that happens in the geek community where we, without coordinating with one another, converge on the best solution Nilay Patel, the laser printer that everybody uses, but nobody mentions the. The, the screen cleaner we all use, but nobody mentioned. And I would say Bitwarden has become like that the password manager of of choice for anybody who's really paying attention.

Now, there's a good reason for this it's open source, it's got it's feature rich. I mean, it is great for home, great for office. They have a Teams and an Enterprise account. They support Yubikeys. And now, good news they just announced they officially support Passkeys. They've supported it for a while, but now they support it on the browser extensions and mobile devices. So it's a really good solution.

If you're saying I don't want to have my passkeys tied to a physical device, Use Bitwarden for your passkeys. I've been doing this for a while and now, everywhere you go on Android, iOS, Mac, Windows, Linux you've got your passkeys. Passkeys on mobile are available on iOS Open beta going on right now on Android. We'll talk more about it as time goes by, but that's what happens when you have an open source product. It's how Argon2 got in there, as a replacement for PBKDF2, which is, you know, not memory hard and has some issues. I use Argon2 now and that's because one of our listeners, Quexon, wrote an Argon2 implementation, submitted it to Bitwarden on their GitHub account. Bitwarden analyzed it, assessed it and said, yeah, we're going to adopt this, this is good, and now we all have it. I love that. I love that.

And this is the one more reason why I know you use a password manager, but you know you've got friends and family and you know they are in that 75% of people who just you know they use the same password over and over again, get them to use Bitwarden and when they say, well, I don't want to pay for a password manager, tell them it's free, forever, Open source, free for personal use, unlimited passwords, yubikey, passkeys, everything. World Password Day. We didn't really mark it, but it was May 2nd. It was five days ago. For in honor of World Password Day, bitwarden surveyed 2,400 individuals from the US, uk, Australia, france, germany and Japan just to learn a little bit about current password practices. We were talking about that a little bit earlier.

31% of US respondents almost a third reuse passwords across sites. They're lying. It's probably more like 50 to 60 to 70 percent, but okay, 31 percent admit to it. That's maybe the better way to put it Now to get this. 42 percent incorporate personal information. They're using their middle name and their birth date, their dog's name, their mother's maiden name, that kind of thing which really raises concerns about the password strength and security. It would be one thing if you reused a completely random password, but they're not doing that. 58% of respondents continue to use memory what's your password manager? I got it all up here. Good luck with that. And 34% continue to use pen and paper for password management. Now, that wouldn't be so bad at home. But we're talking about work. They've got something in their desk drawer probably more likely a post-it note under the blotter with all the passwords there.

Nearly a quarter of respondents view their workplace security habits as risky. They even know it 45% storing passwords insecurely. 44% using weak credentials. I love it. Bitwarden kind of understates this. They say these findings suggest areas for improvement in organizational cybersecurity practices. You need Bitwarden, let's face it. They empower enterprises, developers, individuals to store and share sensitive data not just passwords all sensitive data safely. It's transparent because it's open source. It's the right way to do it. You can even self-host. If you say, oh, I don't want to give anybody my passwords, fine, run your own server. But I honestly think I don't run my own server. Bitwarden is going to do a better job securing it than I ever am and with all that encryption and Argon2 password hardening and all of that, I'm not worried. I think my passwords are as safe as it could possibly be a lot safer than they'd be up here in the brain. Bitwarden makes it easy for you and all its users to extend robust security practices to all of your online experiences, and if you are an employer, you should be listening, because people are doing bad things down the hall at your job.

Get going. Get started with Bitwarden's free trial of a team or enterprise plan or, of course, as an individual, get started for free across all devices at bitwardencom See he used the right address. It's started for free across all devices at bitwardencom slash twit. See he used the right address. Bitwardencom slash twit. This is almost a public service announcement. I mean it's an ad, but really start using it, folks, and get your friends and family to do the same. Bitwarden.

1:46:43 - Steve Gibson
Okay, steve, it's the um, uh second order effect for our listeners. I can't imagine we have a single listener. I mean, I I know not everyone's using bit warden, right, but I'm sure every single person is using something. Yeah, I, just I. I can't conceive of it today, so tell your friends family, your boss, your employees.

Today's podcast is titled Not so Fast because that's the absolutely best way to characterize what's going on in the United Kingdom with Google. As we know, during our podcast two weeks ago, leo dropped the news that Google's third-party cookie deprecation would not be happening as had been long planned for this summer. And of course I was getting all excited about that because you know I've been on this third party cookie thing for a long time. I think it was in 2008. I created that whole cookie forensics facility. I created that whole cookie forensics facility. Grc understands which types of assets carry cookies and which ones are first party and third party and everything.

And back then browsers were not handling cookies correctly when you turned them off. Sometimes they didn't get turned off, or turning them off would keep new ones from being stored but would not cause old ones to start getting blocked, and there was just all kinds of screwy things that were going on. So you know this has been a hobby horse of mine for decades. So, um, it is the case that the abandonment and deliberate blocking of all third-party cookies and other web tracking hacks represents such a dramatic sea change for the web that I get it. Many understandably skeptical observers doubt it can or ever will actually come to pass, and you know we've been abused for so long. It's difficult to imagine that could ever end. So, self-confessed technology fanboy that I am, I wanted to determine what was going on. Were some stuffed shirt bureaucrats somewhere going to screw this all up? When I went to take a look at that for last week's podcast, I quickly became lost in a paper shuffle. I decided that whatever was going on was worthy of understanding, since I considered this single forthcoming change that you know the largest browser maker in the world by far wants to make to be one of the most important things that's going on today. That and the question about, you know, are we going to keep our conversations encrypted in messaging apps, which the EU seems determined to say no to? As I previously said, this represents a complete what Google is doing represents a complete reconceptualization of the way the Internet will finance itself going forward, and we could have it soon.

So the news that leo had picked up on came in the form of an announcement that that left actually more questions than it answered. On the 23rd of last month, which was, you know, tuesday before last, on their privacyboxcom site, google posted under the headline Update on the Plan for Phase Out of Third-Party Cookies on Chrome. That's very clear. Their brief introduction said the UK's Competition and Markets Authority, known as the CMA and we'll be using that acronym a lot here, or abbreviation and Google, publish quarterly reports to update the ecosystem on the latest status of Privacy Sandbox for the web. As part of Google's first quarter 2024 report, we will include the following update, that is, in the report about the timeline for phasing out third-party cookies in Chrome in the April 26th report. Okay, so the update? Very short. It simply reads we're providing an update on the plan for third-party cookie deprecation on Chrome. They said we recognize that there are ongoing challenges related to reconciling divergent feedback from the industry, regulators and developers and will continue to engage closely with the entire ecosystem. It's also critical that the CMA has sufficient time to review all the evidence, including results from industry tests which the CMA has asked market participants to provide, by the end of June. Okay now, that means essentially, june was when third-party cookies were supposed to be ending, but things are taking longer than expected. Given both of these significant considerations, we will not complete third-party cookie deprecation until I'm sorry deprecation during the second half of Q4. We remain committed to engaging closely with the CMA and ICO and we hope to conclude that process this year. Assuming we can reach an agreement, we envision proceeding with third-party cookie deprecation starting early next year, so early 2025.

Include by noting once published, you'll be able to view both Google and the CMA's full reports. Those reports were published three days later, on April 26th, so this was on the 23rd. They said this surprised the industry. Three days later, on the 26th, we got the whole story. So the entire issue is best described by the following statement On 7 January 2021, okay, so a little over three years ago, on January 7, 2021, the CMA commenced an investigation under Section 25 of the Act.

Some you know investigation under Section 25 of the Act. Some you know UK, not you know the equivalent of legislation to prevent. You know monopoly misbehavior. You know antitrust we have here in the US In relation to Google's privacy sandbox proposals. The CMA subsequently informed Google that the CMA was concerned that Google's proposals, if implemented without regulatory scrutiny and oversight, would be likely to amount to an abuse of a dominant position.

So basically, a little over three years ago ago, google says we're going to change the way the internet is financed. Uh, and among those things. We're going to kill off third-party cookies. There's no question that people in the uk, whose income and livelihoods depend upon tracking, like, like you know, their data resellers. They said whoa, whoa, whoa, we don't want third-party cookies to go away, we like third-party cookies. So, uk bureaucrats, please tell Google. No, please tell Google, we need those cookies. Okay, so I don't know that for a fact. It's unclear and is frankly not really important to know the genesis of the inquiry, but it's probably something like that, since we're talking about the elimination of all third party cookies and the curtailment of what had become the widespread practice of tracking Internet users around the Web as a means of determining their interests. It may well have been the advertising technology companies based in the UK which were crying foul behind the scenes.

1:54:43 - Leo Laporte
That seems more likely, really yes.

1:54:45 - Steve Gibson
Yes, what ensued was about what you'd expect from any healthy and well-established bureaucracy as old and wizened as the United Kingdom Experts were yeah. Experts, you know, I mean even the name United Kingdom sort of suggests.

1:55:04 - Leo Laporte
oh crap, we should check this out.

1:55:09 - Steve Gibson
What exactly is this? Experts were found neutral, third-party monitors were enlisted and Google created a document describing the and boy, are you going to hear this word the commitments it was prepared to make with a capital C. I mean, it sounds religious almost. These are our commitments. A document titled investigation into Google's privacy sandbox Sandbox Browser Changes opens with the assertion that, quote the CMA has accepted commitments offered by Google that address the CMA's competition concerns resulting from investigating Google's proposals to remove third-party cookies and other functionalities from its Chrome browser period, which begs the question what exactly are these commitments that the CMA has accepted? I found the points of concern in the description of the roles of the appointed technical expert that will be supporting the monitoring agent. The document states on the 26th of September 2022, the CMA approved the appointment of S-RM Intelligence and Risk Consulting Limited by the monitoring trustee, which is the ING Bank NV, as an independent technical expert to support the monitoring trustee in monitoring compliance with the following provisions of the binding commitments accepted by the CMA on February 11, 2022. Okay, and then the good news is this next line is short Google's use of data paragraphs 25 through 27,. Non-discrimination paragraphs 30 and 31,. And with respect to those provisions anti-circumvention paragraph 33,. The role of the technical expert is to provide specialized knowledge to support the monitoring trustee, particularly in relation to monitoring data flows and understanding the possible impacts of the privacy sandbox changes on ad tech markets. Okay, so we have the ING Bank serving as the neutral monitor, and this monitor has appointed another firm with the required technical expertise, and everything it focused upon is in a small handful of paragraphs somewhere. I found out where they are in Appendix 1A of the latest version of the Google's Final Commitments document. The first set of paragraphs, 25 through 27, basically amount to Google promising not to use any personal data from a user's past Chrome browsing history, a customer's Google Analytics account or to in any way track users. So that's all pretty much what Google has explained to be its intentions and goals. So it appears that the CMA just wanted that very clearly and succinctly spelled out the non-discrimination that's.

Paragraphs 30 and 31, state that Google promises to create a totally level playing field, having examined, explored and shared on this podcast the operation of Google's cookie replacement technologies as they've evolved through the years. This was, you know. It was always clear to me and those who understood this that this was inherently level. The playing field was that is. You know, google was getting a very prescribed amount of information and everybody had equal access to it. It's implicit throughout Google's design, though I have to agree that Google's design has grown to be much better thanks to all the feedback and criticism that various pieces have received through the years. So, yes, it's a good thing we did not get stuck with Google's first idea. What we've got is something far better than what we would have had if there wasn't sufficient scrutiny done and there was. So I can understand how bureaucrats who will never understand how Google's topics, api functions need a simple OK, but but. But what does it mean spelled out in English, since this is crucial to the acceptance of Google's technology? It's only a couple, it's only two paragraphs. I'm going to share them.

Paragraph 30 says Google will design, develop and implement the privacy sandbox proposals in a manner that is consistent with the purpose of the commitments and take account of the development and implementation criteria. Google will ensure that it does not distort competition by discriminating against rivals in favor of Google's advertising products and services. In particular, google will not and we have three things design and develop the Privacy Sandbox proposals in ways that will distort competition by self-preferencing Google's advertising products and services by self-preferencing Google's advertising products and services. Also, will not implement the privacy sandbox in ways that will distort competition by self-preferencing Google's advertising products and services. And, finally, also will not use competitively sensitive information provided by an ad tech provider or publisher to Chrome for a purpose other than that for which it was provided. Then it says, for the avoidance of doubt, privacy sandbox proposals that deprecate Chrome functionality will remove such functionality for Google's own advertising products and services, as well as for those of other market participants.

That was paragraph 30.

And yes, I mean that's exactly what Google has said they're going to do.

But essentially what has happened is a legally binding contract has been created that Google that's what these commitments are, which Google is saying they're going to honor. And paragraph 30 just says Google will not change its policies for customers of Google Ad Manager, campaign Manager 360, display and Video 360, or Search Ads 360 to introduce new provisions restricting a customer's use of non-Google technologies before the removal of third-party cookies, unless in exceptional circumstances, such circumstances to be discussed with a CMA or as required by law For the duration of the commitments. Google will inform the CMA ahead of any such change to these policies. And this leaves us with the final, anti-circumvention paragraph 33, which is just a blessedly single line which reads line which reads Alphabet Inc, google UK Limited and Google LLC will not in any way, whether by acts or omissions, directly or indirectly, circumvent any of the commitments. Now, that sort of language will be familiar to any businessman or anyone who's been involved in any contractual agreements where attorneys are engaged. You know it's a boilerplate.

Right and it's important to understand that both the United Kingdom government and Google's various corporations recognize those provisions to be now contractually and legally binding. To be now contractually and legally binding. So it has been upon those representations, which are enumerated as commitments with a capital C, that the UK then proceeded to carefully examine Google's proposal. So now we return to the timeline for phasing out third-party cookies. That work appears in a document titled CMA Quarter One 2024 Update Report on Implementation of the Privacy Sandbox Commitment, dated last month, april 24th. I mean April of 2024. Actually, it was April 26th. The document's summary lays out the entire story and it's interesting enough and short enough to share. They said this report sets out the CMA's updated views on the issues we identified in our January 2024 report. So January was the previous report Now, so it's basically quarterly, right? So this is the result of the first quarter, so this is from January 2024. Where are we now? We're in April, so we've had the first quarter go by. Our analysis is based on the framework for assessment set out in the legally binding commitments that Google made in February 2022 to address competition concerns relating to its proposals to remove third-party cookies from Chrome. So in other words, yeah, this is a big deal for the entire internet. It's a big deal.

The January 2024 report set out our provisional views on the impact of the privacy sandbox on competition, publishers and advertisers and user experience. We outline Google's response to the concerns we identified in that report the January report and the steps it is taking to resolve pending issues. We've also considered the feedback received from market participants on these points. We've included a summary of this feedback in the sections below. This report also incorporates the preliminary assessment of the at the ICO is the Information Commissioner's Office on the privacy and data protections impacts of the Privacy Sandbox. Having consulted with the ICO, we set out our current views on these concerns for each of the APIs. Although there are a number of concerns to work through, based on the available evidence, we consider that from the 1st of January 2024 through the 31st of March 2024, the relevant reporting period Google has complied with the commitments. This means that, in our view, google has followed the required process set out in the commitments and is engaging with us and the ICO to resolve our remaining concerns ahead of third-party cookie deprecation.

However, further progress is needed by Google to resolve our competition concerns ahead of deprecation. We will continue to work with Google to resolve our concerns between now and the point at which Google triggers the standstill period. We will provide an update on progress in our next update report. Testing of the Privacy Sandbox tools is also currently underway. The test results will form part of a wider evidence base that we will use to assess the effectiveness of the privacy sandbox. The test period runs until the end of June this year and, as I said before, because this is running through June, that's what kept the cookies from being, you know, for them for the beginning of the deprecation to start at the end of June, they said. Given the time needed to resolve outstanding issues and take account of testing results, we've agreed with Google that there should be a limited delay to third-party cookie deprecation, subject to resolving our remaining competition concerns. Google is now aiming to proceed with third-party cookie deprecation starting in early 2025. Under the commitments, it is for Google to decide when the standstill period is triggered. We encourage market participants taking part in testing to submit their results directly to us by the end of June deadline. We also welcome any additional feedback from stakeholders on the concerns identified in this report. Our contact deals are included at the end of the report.

Okay, so one last thing. This made reference to a standstill period several times, so I tracked that down In the earlier commitments documents. It appears to be just more bureaucracy for its own sake. It says not on paragraph 19,. Google will not implement the removal of third party cookies before the expiration of a standstill period of no less than 60 days. After Google notifies the CMA of its intention to implement their removal, google may increase the length of such a standstill period at any time, giving between a time between giving such notice and the period's expiration. At the CMA's request, google will increase the length of this standstill period by a further 60 days to a total of 120 days.

Okay, so what follows all of that is? That was the document summary. There are 97 pages of interesting but ultimately mind-numbing back-and-forth detail, as every conceivable facet of this big change Chrome will be implementing is examined under a bureaucratic microscope. The real concern is over Google's size and whether the changes it is making will disadvantage smaller ad tech players. But what becomes clear after reading at least some and that's what I did I could not go through 97 pages of this. My eyes started to cross and I couldn't see.

It is very clear that the UK is moving clearly in Google's direction. Both parties are truly negotiating in good faith. That that's one thing that also is very clear. This is not the UK stonewalling and you know being unreasonable. It really is as Leo portrayed you know, a bureaucratic walrus that just absolutely has, you know, doesn't not have any idea what is going on. People are nipping at it, saying this is bad, you can't let Google do this. So Google is saying this is not bad, this has to happen. We want to stop tracking on the Internet. People who make their living from tracking are saying yeah, but we like tracking, yes, and so the UK is sort of stuck in the middle. Google is being reasonable, I mean I. There must be like be a division of Google where they're intoxicated in hot tubs somewhere just in order to maintain their sanity. There's no way that the developers are dealing with any of this nonsense, because I mean, ultimately, that's what it is, but but the UK needs to be placated through having this explained. You know what exactly this is and does. So that's what's happening Again. Progress were being disadvantaged.

The expert looked at it under the watchful eye of the monitor and now, in the April report, the conclusion is no, that is not the case, no-transcript.

And it's also true that many companies whose revenue has been entirely derived from the oh-so-slimy practice of tracking users and aggregating their data without our knowledge or permission, for the purpose of selling that data to anybody with a wallet, will be. Their income will be impacted, and not in a good way. So, having read through the documents, I can understand that the process is taking place and it's taking time, and in retrospect, you know, though, I would have never expected this would happen, it is at least understandable, and it appears the world will indeed soon be receiving this dramatic change in the way Internet-based advertising is carried out. It is, you know, clearly far superior to the status quo. We can't keep going on the way we have been, and it takes something no less large than Google to just simply make it an ultimatum. We are going to do this. So I understand they've got to satisfy the walruses of the world. You know, it looks like that process is close to being done. Yeah.

2:13:37 - Leo Laporte
I hope so. Of course advertisers don't like it. Of the world you know, there looks like that process is close to being done. Yeah, I hope so. Of course advertisers don't like it. That's why we like it, and, I think, google. Obviously they're trying to balance the interests of both parties, because they are. They sell ads, they buy ads, that's their business, it's their revenue.

2:13:55 - Steve Gibson
But they also understand that consumers are not happy and I think they need to know and leo, I'm, I'm, I'm impressed by that the the minimization of the information that google themselves are willing to obtain. I mean it's as we've seen topics is not invasive. They are that. You know. No one can be identified from their topics, they are chosen at random. I mean, the system has incredible checks and balances built in, which we've talked about on the podcast when we explained it, and I think we'll probably do for a re-explanation when it actually goes into effect, because you know it's the way the world's going to work. And and I love the comment about the reason my, my machine's fans were spitting up, was that my chrome browser when I was running chrome when it was busy holding auctions with all of the world's ad agencies well, that's coming, maybe.

2:14:55 - Leo Laporte
Anyway, we'll see the only way.

2:14:57 - Steve Gibson
The only way to do this is to make it user-side. You move it to the user and then the user's browser chooses what they're going to see. It's brilliant. Yeah, makes sense.

I'm going to tease next week's topic. I believe I think next week's topic will be ZTDNS, which stands for Zero Trust DNS. Last Thursday, microsoft published a preview of a forthcoming security solution they call Zero Trust DNS. It's been clear for a long time that DNS represents, as we know, both an Achilles heel of network security and a point where it's also very possible, if you're clever, to discovery, a few months back of Adam Network's DNS solution, which they call Don't Talk to. Strangers may already be enjoying the benefits of dramatically improved security thanks to leveraging the power of DNS.

But I needed more time to dig into what Microsoft is doing. So for next week's podcast, I plan to take a deep dig into what Microsoft is doing. So for next week's podcast, I plan to take a deep look into what Microsoft has announced. Now, one thing I should say that immediately stood out was that Microsoft might be attempting to use this as a way of driving enterprises to Windows 11. Since enterprises don't want Windows 11, as we've heard Paul Theriot mentioned many times. You know no one really does. And in Microsoft's diagrams, which I briefly scanned, they're explicitly labeling the clients as Windows 11 machines. Now that just might be Microsoft, you know, because Windows 11 is what they're all using, since no one actually wants Windows 11, since Windows 10 still commands more than twice the number of desktops as Windows 11 and a much greater percentage within the enterprise, because new computers come with Windows 11, but enterprise machines that have been running for 10 years don't, and since a huge installed base of machines won't even run Windows 11,.

If what Microsoft is planning to do is truly a Windows 11-only solution, then the client agnostic system that the Atom Networks guys already have working and well proven seems like a far more practical one to me. But in any event, by the end of next week's podcast we'll know exactly what's going on. And you know it's a good thing that Microsoft is stepping up and looking to improve DNS security, because we all know it needs it. But it seems to me there's already a solution in place, but not from Microsoft. And so when the biggie does it? You know, I remember, leo, it was fantastic. Brad Silverberg and Brad Chase came down from Redmond and took me out to lunch and said Steve, we're going to be announcing DOS 6 pretty soon, you know.

2:18:20 - Leo Laporte
And.

2:18:20 - Steve Gibson
I said uh-huh, and they said we're a little self-conscious about this, but we're adding something called ScanDisk. Oh, it's nice of them to warn you, don't worry, it won't work. Well, it's not going to, it doesn't do what Spinrite does. And I said uh-huh, great, that's just effing wonderful.

2:18:50 - Leo Laporte
Was that later than Check Disk, because they had Check Disk. Yes.

2:18:55 - Steve Gibson
Later than check disk, because they had check disk. Yes, for the rest of our existence. We are answering the question well, I already have scan disk. What do I need spin right for Right? Anyway, the point is it matters when the giant offers the yeah, oh, it does. Yeah, I've been there firsthand. Yep, I like Silverberg a lot.

2:19:18 - Leo Laporte
I didn't never was fond of brad chase, you weren't uh, sherlocked though, as they, as the mac people, call it. So that's the good news no, norton did that tried, did you think?

2:19:30 - Steve Gibson
he sold more more copies of this doctor than you sold of uh spin right probably, huh well, what he did, um, uh, was when I refused to sell spin right to peter, he sent a developer home with a copy of it, oh, and said that's not nice. Oh yeah, and we, we know that because one of my guys looked inside and saw code that that was our code. I mean, there were, like there was a place where I needed to see whether the bios handled a certain api call. So I put some specific random data in the registers when I made the call to see whether they got changed.

Oh, that's kind of a smoking gun, their clone of spin right to the same values, the same data, because they didn't know what I didn't know what was doing exactly.

2:20:20 - Leo Laporte
They said well, we better do it this way, because we don't know if it does something.

2:20:24 - Steve Gibson
Yeah the good news is, since they didn't actually create uh, what was it called? Uh, calibrate, the was their clone. Since they didn't create it there, when, when their customers called for support, they said, well, we're not sure, call gibson research. I'm not kidding, we got, we got calls from for our support. People say, well, norton said to ask you about calibrate, and we said, well, when you buy a copy of spin, right, we'd be happy to answer all your questions.

2:20:52 - Leo Laporte
We'll tell you steve is and at GRC and still selling Spinrite. Now version 6.1, many moons later, and it's even better than ever. In fact, now it speeds up SSDs.

It's doing really well actually. Yeah, really Congratulations. If you go to GRCcom, pick up a copy. If you don't already have one of the world's best mass storage, maintenance, recovery and performance enhancing utility, we have to add that performance. That's a new feature, kind of serendipitous feature. It's pretty great. Yeah, you can also find a copy of the show there.

Steve has the canonical 64 kilobit stereo audio. Actually it's mono audio. He also has a 16 kilobit version for the bandwidth impaired and he has excellent transcripts written by an actual human being, no AI involved. Elaine Ferris does a great job with all of that grccom. He's at sggrc on Twitter. If you want to DM him, send him a picture of the week or whatever. His DMs are open. We have the 64-bit canonical version of it, the audio version, at our website, twittv slash SN. But you can also find video there. There is a video channel on YouTube dedicated to security now and of course, you can subscribe with your favorite podcast player and that way you'll get it automatically. You could even watch if you're really in a hurry. If you're like you can't wait, you can watch over Tuesday afternoon while we do it, because we stream the recordings of all of our big shows on YouTube. Youtubecom slash twit. This one's right after MacBreak Weekly, so times will vary 1.30 to 2 pm Pacific, 5 pm Eastern, 2100 UTC at youtubecom slash twit.

Club members, thank you for your support. If you're not a club member, may I beg of you please join? Seven bucks a month gets you ad-free versions of all the shows. Gets you a lot of extra stuff. We're going to do a watch party on Thursday, which should be a lot of fun, with the whole staff in the LaPorte living room watching a silent movie, which is good, should be a lot of fun the whole staff in the LaPorte living room watching a silent movie, which is good because we can make the sounds for you. That will be this Thursday. Club members, look in the events tab for more information. We're still voting on Stacy's Book Club Pick of the Week. A couple more days to that. You know the best thing about Club Twit is the people. It's a community of really great people. You would like to know If you're looking for a great community online. That's safe, that's friendly, that's smart. Twittv slash club twit. Okay, steve, I'm going to let you go. I'm going to take your ankle bracelet off and wish you farewell. Until next week, my friend.

2:23:39 - Steve Gibson
Thank you, buddy. See you for podcast 974.

2:23:44 - Leo Laporte
Yay, yeah, we would be right now going. Oh no, there's only 25 left. Oh no, okay. Thank you, steve, have a great one.

2:23:56 - Steve Gibson
Wisdom of our listeners. That's it. It's because of them that I'm like Okay, I'll stay.

2:24:01 - Leo Laporte
Now I'm trapped. Thank you everybody, because I have to Thank you everybody. I was going to retire when you did.

2:24:07 - Steve Gibson
Damn it.

2:24:08 - Leo Laporte
Damn it, jim. Thanks, steve, take care. Bye