| ||||||
Description: Is there any such thing as truly free privacy? What has Elon done now? What's the latest new tactic in post-breach cyber-extortion? Has Europe finally come to their senses over old and creaky proprietary radio encryption? What new forthcoming iPhone communications feature took everyone by surprise? What discovery did I make for super-secure code signing? Just how sticky are those barnacles? What's a good way to measure USB drive speed? Is the EU's proposed eIDAS 2.0 QWACs system as bad as it seems? And if it passes into law as-is, CAN companies realistically say no? What's my favorite little PC platform for building security gateways? Why couldn't we just use the good part of a fake drive? What should ex-LastPass users watch out for in their credit card statements? And, finally, we recognize the 50th birthday of Ethernet and look back at the history of its creation.
High quality (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-949.mp3 |
SHOW TEASE: It's time for Security Now!. Steve Gibson is here with some theories on how to release the Windshield Barnacle; good ways to measure USB drive speed; his struggles with code signing. One last speed bump on the way to the latest version of SpinRite 6.1. And, finally, a look at Ethernet, 50 years old this year. Steve's got some great stories. It's all coming up next on Security Now!.
| Leo Laporte: This is Security Now! with Steve Gibson, Episode 949, recorded Tuesday, November 21st, 2023: Ethernet Turned 50. It's time for Security Now!, the show where we cover the latest security news, explain how things work in the real world, occasionally recommend some good sci-fi, and it's all thanks to this guy right here, Mr. Steve Gibson. Hello, Steve. |
| Steve Gibson: Yo, Leo. |
| Leo: How you doing? |
| Steve: Good to be with you once again. |
| Leo: Yeah. |
| Steve: For this pre-Thanksgiving podcast. |
| Leo: That's right. I won't be here next week. |
| Steve: And as I understand it, we're losing you for a couple weeks after this. |
| Leo: Just one week. One week. |
| Steve: Oh, okay. Oh, okay. |
| Leo: I'll be back two weeks from today. Next week I'm missing the whole week. Not a vacation. It's some sort of weird psycho retreat. |
| Steve: Well, and if it's what Lisa did, you're not allowed to take anything with you. |
| Leo: Nothing. I had to get a... |
| Steve: They strip you naked. |
| Leo: I had to get a Timex. No, no, you can wear clothes. But I had to get a Timex to replace the Apple Watch. When you check in they say, "Give me your cell phone." And so it'll be interesting to be completely disconnected. I think that's probably the main benefit, frankly. |
| Steve: I think it'll be nice; won't it? |
| Leo: Yeah, I'm looking forward to it. |
| Steve: I mean, like just to say, like, you can't do anything except, you know, think. |
| Leo: I'm just hoping that Sam Altman doesn't get fired again because then I'll really be out of the loop. A lot can happen in a few days. |
| Steve: That's a really good point. I mean, you spend so much time now staying current. You were just showing us your massive feed that you spend eight hours a day going through. Imagine a week going by. I mean, anything could happen. |
| Leo: Well, it was very hard for me over the weekend, because we were in Las Vegas for the Formula One race, to be reading these stories and saying I'm not going to get to talk about this on TWiT. It was a challenge. It was hard. I ended up doing a little mini-TWiT for Lisa, "Let me tell you what happened today." Poor Lisa, she had to put - she was very kind about it. She put up with that. So what's happening in your world this week? |
| Steve: So we've got a lot of fun stuff to talk about this week. We're going to answer the question, is there any such thing as truly free privacy? What's the latest new tactic in post-breach cyber extortion? Has Europe finally come to their senses over old and creaky proprietary radio encryption? What new forthcoming iPhone communications feature took everyone by surprise last week? What discovery did I make for super-secure code signing? Just how sticky are those barnacles? What's a good way to measure USB drive speed? Is the EU's proposed eIDAS 2.0 QWACs system really as bad as it seems? And if it passes into law as-is, can companies realistically say no? What's my favorite little PC platform for building security gateways? Why couldn't we just use the good part of a fake drive? What should ex-LastPass users watch out for in their credit card statements? And, finally, because this podcast is titled "Ethernet Turned 50," we recognize the 50th birthday of Ethernet and look back at the history of its creation. |
| Leo: Wow. I'm feeling old, Steve. Holy cow. I don't know, do you remember when Ethernet first appeared in your life? |
| Steve: Yes. I was actually onsite at the time. I will mention that. I was there with Bob Metcalfe... |
| Leo: What? What? |
| Steve: ...and the connection of the first Xerox graphics printer and... |
| Leo: Oh, so you had some firsthand experience of this. |
| Steve: '73 was the year I graduated high school, and the summer that I worked for SAIL, the Stanford University AI Lab... |
| Leo: Oh, my god. |
| Steve: ...and they received the first Xerox graphics printer from PARC. |
| Leo: Wow. |
| Steve: Which was, you know, nearby in Palo Alto. |
| Leo: Wow. Okay. Okay. |
| Steve: You would not believe, Leo, that it is now - well, you would - that it's now impossible for me to type sequel, SQL... |
| Leo: Right. |
| Steve: ...without putting an R in, SQRL. |
| Leo: Oh. |
| Steve: My hand just for so many years... |
| Leo: Yeah. |
| Steve: ...I was typing SQRL... |
| Leo: How funny. |
| Steve: ...that it's embedded in my autonomic nervous system. It just, I go, oh, darn it, and I have to go back and take the R out. |
| Leo: I just wish it were embedded into our Internet nervous system, frankly. |
| Steve: Yeah, yeah. |
| Leo: Well, that's how the cookies crumble. |
| Steve: So our Picture of the Week is a sort of a rendition, a rendering of a famous coffee-stained napkin on which Bob Metcalfe first sketched out his concept for the Ethernet's physical layer connection. This was in 1973 when PARC needed to connect all of the different things. They had created this Alto work station, which is also famously what Steve Jobs saw when he was taken on a tour through PARC. Of course Palo Alto's, Xerox's PARC, Palo Alto Research Center, where he first saw a GUI interface and immediately recognized what it was. So this was the beginning of hooking everything together. So we'll have much more to say about that at the end of the podcast. But it is a cool picture, and it is, like, it's what, you know... |
| Leo: It was a napkin. There really was a real napkin with that drawing. |
| Steve: There actually was a real physical napkin. |
| Leo: Is it around, or did it get destroyed? |
| Steve: That's a good question. I was wondering that myself. There are several pictures that pretend to be it, but they're not. They're fakes. So, I mean, and, you know, what are the chances that some random sketch on the back of a napkin would, like, actually have value in the future? Leo, what are the chances that some measly little bitcoins that you created overnight could actually... |
| Leo: Stop it, stop it. |
| Steve: Yeah, yeah, that's right. |
| Leo: By the way, I love it... |
| Steve: That's right. |
| Leo: ...that the name Ethernet comes from, and he's got it on the napkin, "the ether." |
| Steve: Yes, yes. Which is to say his conductive medium would be medium through which the messages travel. |
| Leo: And the medium's unimportant. It's the message protocol that matters. So he just writes "The Ether." Love it. Love it. |
| Steve: Yeah. So Last Thursday, Meredith Whittaker, whom we've spoken of before, she's Signal's CEO President, and of course whom we saw first stand up to the UK with their absolute refusal to compromise on Signal's encryption, along with a lead developer, Joshua Lund, authored a lengthy fundraising wake-up call in the form of a breakdown of their expenses, of Signal's expenses. Now, while they're a registered 501(c)(3) nonprofit organization, they maintain a staff of 50 busy people. And actually, when we put this in context as I will a little bit later here, it's shocking that it's only 50 for when you consider how much these 50 people are doing. And they also describe their significant infrastructure costs. And there are another few surprises that I'll share because I'm going to kind of pick and choose among this very long posting. But I'll share the beginning of it to give everyone a sense for what they're aiming for here. It starts out under the headline "Privacy is Priceless, but Signal is Expensive." And they write: "Signal is the world's most widely used truly private messaging app, and our cryptographic technologies provide extra layers of privacy beyond the Signal app itself. Since launching in 2013, so, okay, we're now 10 years out, the Signal Protocol our end-to-end encryption technology has become the de facto standard for private communication, protecting the contents of billions of conversations in WhatsApp, Google Messages, and many others. "Signal also continues to invest in research and development in the pursuit of extending communications privacy. This commitment underlies our recent work to add a layer of quantum resistance to the Signal Protocol, which we talked about a few weeks ago, and our previous work on metadata protection technologies that help keep personal details like your contact list, group membership, profile name, and other intimate information secure. This singular focus on preserving the ability to communicate privately is one reason that we work in the open, documenting our thinking and making our code open source and open to scrutiny so you don't have to take our word for it. "Signal is also a nonprofit, unlike almost every other consumer tech company. This provides an essential structural safeguard ensuring that we stay true to our privacy-focused mission. To put it bluntly, as a nonprofit we don't have investors or profit-minded board members knocking during hard times, urging us to 'sacrifice a little privacy' in the name of hitting growth and monetary targets." They don't have any growth and monetary targets. "This is important," they said, "in an industry where 'free'" - and they have that in air quotes - "'free' consumer tech is almost always underwritten by monetizing surveillance and invading privacy. Such practices are often accompanied by 'growth hacking' and engagement maximization techniques that leverage dark patterns to keep people glued to feeds and notifications. While Signal is also free to use, we reject this kind of manipulation, focusing instead on creating a straightforward interpersonal communications app. We also reject business models that incentivize such practices. "Instead of monetizing surveillance, we're supported by donations, including a generous initial loan from Brian Acton. Our goal is to move as close as possible to becoming fully supported by small donors, relying on a large number of modest contributions from people who care about Signal. We believe this is the safest form of funding in terms of sustainability: ensuring that we remain accountable to the people who use Signal, avoiding any single point of funding failure, and rejecting the widespread practice of monetizing surveillance." And finally: "But our nonprofit structure doesn't mean it costs less for Signal to produce a globally distributed communications app. Signal is a nonprofit, but we're playing in a lane dominated by multi-billion-dollar corporations that have defined the norms and established the tech ecosystem, and whose business models directly contravene our privacy mission. So in order to provide a genuinely useful alternative, Signal spends tens of millions of dollars every year." And they finished with this intro: "We estimate that by 2025, Signal will require approximately $50 [five zero] million a year to operate. And this is very lean compared to other popular messaging apps that do not respect your privacy." Okay. So then their blog post proceeds from there to substantiate that claim and to further detail the nature of their current cash outlay for all facets of what it takes to make Signal go. I've got a link in the show notes for anyone who's interested: signal.org/blog/signal-is-expensive. |
| Leo: You know, it's interesting because this ties in - she wrote this before the OpenAI kerfuffle of the past weekend. But it ties in very much to that because OpenAI was founded to be a nonprofit like Signal. But it got so expensive they had to create a for-profit arm. And really what you're seeing is the tension between the for-profit, very, very successful OpenAI and the not-for-profit AI should be not run by a big profit-making company arm. And look who won. You know, it's amazing that Signal can survive at that run rate. |
| Steve: And we're about to hear some gloom and doom from me. |
| Leo: Yeah. |
| Steve: So I said I'm not a big Signal user, though I do have it installed on my phone and desktop because back when I was bringing up GRC's XenForo web forums, one of our listeners, Rasmus Vind, who knew XenForo and PHP, came to my rescue and implemented the forum's interface to SQRL, which by the way remains in heavy use today and is the way most of our forum users logon, I've been told. So Rasmus suggested that we use Signal to converse in real time, and it worked perfectly. But I have to admit that I never even stopped to consider the fact that Signal was both free and devoid of any annoying advertisements or other nonsense. And in thinking about it, I realized that we've become very accustomed to receiving "free" things in our lives. |
| Leo: Yeah, that's the problem, yep. |
| Steve: Yes. And I have "free" in air quotes because something pays for the things we receive. You know, we grew up, well, for those of us with thinning or gray hair, listening to free AM and FM radio and watching free television, all sprinkled with ads. And today it's still possible to get lots of high-quality free stuff if you don't mind ads, like this podcast. GRC's various services like ShieldsUP!, and our growing library of ad-free freeware on a 100% ad-free website, is entirely financed by the sales of SpinRite. |
| Leo: See, that's interesting because, I mean, it's one thing for you to write a program and then distribute it. But you've got ongoing costs. With ShieldsUP! you've got to run a server all the time. |
| Steve: Yup. |
| Leo: Yeah. But you don't show ads. |
| Steve: No, it's 100% financed by SpinRite sales. |
| Leo: But I would say, by the way, that that is not really the case. It's 100% financed by Steve Gibson, who happens to have an income thanks to SpinRite. |
| Steve: That's a good point. |
| Leo: You're really paying for it. It's out of your pocket, yeah. |
| Steve: Yeah, that is the case. You know, so we have 8,661,248 people as of this morning who have downloaded and used our DNS Benchmark. ShieldsUP! is beyond 101 million uses. 68,000 people have downloaded ValiDrive since it was released. All these people received something of value for free, but only because a sufficient number of other people have been interested in having access to SpinRite and were willing to pay for it. So Google exists because of advertisements and extensive tracking. The TWiT network and this podcast are here thanks to advertisements and the direct support of Club TWiT members. And all of the stuff I've been able to do, create, and give away is thanks to people purchasing SpinRite. But what of Signal? What we're living in now is an "attention economy" where commercial interests are vying for, and are willing to pay dearly for, people's attention. But not Signal. It occurs to me, and I really hope I'm wrong, that this is going to be a heavy lift and that they're probably in a very tough spot. For all the best and right reasons, they've put themselves in the spot of needing to ask for voluntary donations from a global community that's grown accustomed to getting everything for free, or at least apparently for free. In other words, not needing to directly part with any of their hard-earned cash. So how will Signal support itself? Can it support itself? It'll be up to those who use it and who depend upon its integrity, or perhaps other wealthy donors who want to see it survive, to keep it going. Do most people actually care - and this is the question. Do most people actually care about the integrity of their messaging service? I have come to doubt it. It's fine if it's there for free. But will they pay for it? Will its users even understand the value that they're receiving in return? Or is it just a convenient messaging app that they're using without really understanding what's behind it and what it takes to offer such a service with absolutely no strings attached? And that's what differentiates it from everything else. Signal is 100% absolutely no strings attached. Elsewhere in their blog they write: "Data is profitable, and we're a nonprofit, focused on collecting as little data as possible. Most tech companies collect and create as much data as they can. They build large data warehouses, and then later invent new terms like 'data lake' when their unquenchable thirst for more of your private information can no longer fit within the confines of a single warehouse. Their default move is to store everything for as long as they can in an easily accessible and unencrypted format, suffering data breach after data breach after data breach, hoping to monetize this data by indirectly, or directly, selling it to advertisers or using it to train AI models. Again, data is profitable." They noted that their data storage costs are far less than other messaging companies specifically because, unlike everyone else, they only retain the barest minimum needed for the system to function. And it's been designed from front to back not to store anything that it doesn't need to. One of the surprising line items they highlighted was the cost of registration. Get a load of this. They said: "Signal incurs expenses when people download Signal and sign up for an account, or when they re-register on a new device. We use third-party services to send a registration code via SMS or voice call in order to verify that the person in possession of a given phone number actually intended to sign up for a Signal account. This is a critical step in helping to prevent spam accounts from signing up for the service and rendering it completely unusable, a non-trivial problem for any popular messaging app. "Signal's registration service routes registration codes over multiple telephony providers to optimize delivery across the globe, and the fees we pay to third-party vendors for every verification code we send can be very high. This is in part, we believe, because legacy telecom operators have realized that SMS messages are now used primarily for app registration and two-factor authentication in many places, as people switch to calling and texting services that rely on non-telecom Internet data. In response to increased verification traffic from apps like Signal, and decreased SMS revenue from their own customers, these service providers have significantly raised their SMS rates in many locations, assuming correctly that tech companies will have to pay anyway. The cost of these registration services for verifying phone numbers when people first install Signal, or when they re-register on a new device, currently averages around $6 million dollars per year." |
| Leo: Wow. |
| Steve: Leo, that's like an eighth of their budget, or a seventh of their total budget, or a sixth. It's astonishing. And just think of all the people who might download and then set up the app, then wind up not using it that much. My phone is chock full of such apps. Why would I pay anything for anything for something that I never use? Yet they're footing the cost of my sign-up verification whether I ever use it again or not. Another thing I appreciated is how lean they're running. They have 50 employees total. How does this compare to other similar services? They wrote: "Signal is not a collection of privacy-preserving services that route end-to-end encrypted messages and calls around the world." That is, it isn't just that. "It's also a set of cross-platform apps and modular development components (libraries) that make this type of private communication possible in the first place. Because the norm is surveillance, we're often required to create or modify our own libraries from scratch, swapping in privacy instead of using more common frameworks that assume surveillant defaults. Swimming against the tide of an ecosystem whose incentives and infrastructure promote surveillance and privacy invasions is, of course, more time-intensive and more expensive, and requires dedicated and experienced people. "First, we have three distinct client teams, one for each platform: Android, Desktop, and iOS. These teams are constantly working, adjusting to operating system updates, building new features, and making sure the app works on a wide variety of devices and hardware configurations. We also have dedicated engineering teams that handle the development and maintenance of the Signal Server and all its infrastructure, our calling libraries like RingRTC, and core libraries like LibSignal. These also need constant development and monitoring. "Product and design teams help shape the future of the app and determine how it will look and function, while our localization team coordinates translation efforts across more than 60 [six zero] languages. We even have a full-time in-house support group that interfaces with people who use Signal and provides detailed technical feedback and real-time troubleshooting information to every other team. This is an essential function, particularly at Signal, because we don't collect analytics or telemetry data about how people are using Signal. So otherwise we would never know. "This is a lot of work, and we do it with a small and mighty team. In total, around 50 full-time employees currently work on Signal, a number that is shockingly small by industry standards. For example, LINE Corporation, the developers of the LINE messaging app popular in Japan, has around 3,100 employees; while the division of Kakao Corp. that develops KakaoTalk, a messaging app popular in Korea, has around 4,000 employees. Employee counts at bigger corporations like Apple, Meta, and Google's parent company Alphabet are much, much higher." Of course they're also doing lots of other things. And the last bit that I wanted to share is this: They wrote: "Growth in Signal translates into increased infrastructure costs, and having more infrastructure requires more labor. As of November 2023" - today, this month - "Signal's server network is regularly responding to around 100,000 requests per second, and we routinely break our previous records. A funny thing happens when a globally accessible service starts handling billions of requests every day. Suddenly, one-in-a-million possibilities are no longer unique or rare, and unlikely situations become more and more common as Signal grows. "It's not unusual for our engineers to do things like write custom code to reproduce an esoteric and complicated IPv6 connectivity issue that's affecting people running an arcane operating system configuration in specific regions, but only when connected via a certain set of Internet service providers." Whew. "Troubleshooting such infrastructure issues can be very expensive because isolating a problem and developing a fix can take a lot of time and expertise." So, okay. When I opened the app just now, I found a request for a donation. Clicking the "Donate" button took me to a screen which read: "Privacy over profit. Private messaging, funded by you. No ads, no tracking, no compromise. Donate now to support Signal." And then there was an option to read more. Having read everything I just had, I decided I would give them some money. So I selected an amount and was taken to a screen that said "Donate to Signal. Get the Signal Boost badge." And the payment options were Apple Pay, Debit or Credit Card, or PayPal. It'll be interesting to see whether a user-supported secure messaging system is an oxymoron. Can such a system support itself? I have no idea whether a sufficient number of users will step up and pay, and on the ongoing basis that Signal requires, to use a miraculously secure and clean service that's truly free in every sense of the word. I'm not inclined to pay continuously because I don't use it on a regular basis. I am a continuing supporter of Wikipedia because I do often use it. My fear, based upon everything I've seen, is that people do not appreciate and probably cannot appreciate what Signal is, and that they use it because among all of the other free messaging services, they can see that it's the cleanest and totally free of debris. But they have no idea why. The problem is that being totally debris free is an expensive service for Signal to deliver. I'm glad they took the time to explain their financial reality. Those of us here get it. But most Signal users will never see their posting. And without that posting, that "Donate" button at the bottom of Signal's screen doesn't pack nearly the same punch. And Leo, I think that your immediate reaction is probably the right one. It's like, it's been nice knowing you. |
| Leo: I don't know. You know, we should point out you mentioned Brian Acton is the CEO. He was the founder of WhatsApp, sold it to Facebook for 19 billion. He's worth it's estimated 2.5 billion. I suspect it's Brian and a few other well-situated donors that have been keeping it going. It'll be interesting to see if, I mean, obviously no one wants to pay $50 million a year forever, even if you're a 2.5 billionaire. It'll be interesting to see if they can get people to donate. I do think, and we've talked about this on our other shows, we are coming to the end of the free Internet. We all know it couldn't hold forever. Right? |
| Steve: Well, we were all wondering why it, like, held at all. |
| Leo: How could it be free, yeah. |
| Steve: Like for how many years were we hearing that Twitter's losing money, but they're going to make it up in volume. |
| Leo: Right. |
| Steve: It's like, what? |
| Leo: Yeah. And I think, you know, the crunch has come. And I don't think, you know, look. We are in the same position. Ad sales have dropped way off. Podcasting, which was the fair-haired boy, no longer is with advertisers. They quite understandably want to go where they can get more information about who's watching. So they buy YouTube, and they buy Google, and they buy Facebook, because they like that information about you. And so because we have very limited ability to track you, podcasts in general are much less attractive. That's why we make a big deal about Club TWiT and invite you to join and support us and stuff. And we have to date 8,322 paid members, which is great. Not enough to keep us on the air. We're doing some sort of hybrid thing. But it's a big crunch. And so, you know, I just don't know if people have, you know, people talk about subscription fatigue. I understand nobody wants to pay $7 here, $5 here. But donations, I've got to tell you, we used to do donations. We started, I thought the whole thing will be donation-based. You remember that because you were there. |
| Steve: Yeah. |
| Leo: And we'd get about 8,000 a month. It wasn't enough to pay a salary, let alone a whole team. |
| Steve: Yeah, yeah. And one thing I did note that I didn't put in the show notes is that Tor remains more than half supported by the U.S. government. |
| Leo: Yeah, isn't that interesting. |
| Steve: Yeah. |
| Leo: Why would they support that? |
| Steve: It is curious, although the half of support is way less expensive, it's like $1.3 million or something. So the Tor Project is not the same as Signal by any means in terms of scale. |
| Leo: Well, I imagine most Tor servers are self-funded; right? They volunteer. So it's a really interesting - we are in interesting times. |
| Steve: I sort of wanted to - yeah. We are. I wanted to put that on everyone's map just, you know, to make sure they knew about Signal, where it stands, that it is, you know, unique in the industry. And I wish them luck. You know? I just don't have an occasion to need Signal. Rasmus and I haven't talked in a long time, and iMessage is fine. And I buy an iPhone, and that apparently underwrites iMessage. |
| Leo: Yeah. I mean, honestly the people who most need it, the dissidents and so forth that do need it, probably have no means to pay for it. |
| Steve: Right. |
| Leo: So really the donations are to support that, guess. |
| Steve: Yeah. And it's why I think the more reasonable solution is the benefactor. You know, they would like to have, as they said, a stable income source from many small donations. But I just, you know, I don't know. And as I said, Leo, I don't know why people chose it except that it's the best one. You know, it's clean and no ads. But does anyone really know about Signal, or care? If they tried to make it a subscription, people would leave. They'd just go to one of the other free things that is not actually as free as Signal truly is. |
| Leo: Mm-hmm. |
| Steve: So, okay. Here's one that just makes your head shake. It was tied for the most listener news mentions with feedback about last week's discussion with The Barnacle, which we'll be getting to a bit later. We've talked before about how ransomware has evolved. In the good old days, ransomware attackers would just encrypt a business's various servers, you know, their workstations and hopefully their backups, if they could get it, and leave it at that. But when that wasn't always delivering the results they wanted, meaning getting paid in lots of cryptocurrency in return for providing the decryption keys, some of the gangs would then launch a powerful DDoS attack against the company just to increase their pressure on it. And when even that didn't work, the gangs began exfiltrating the enterprise's data before encrypting it so that they could also hold it for ransom, threatening to release it to the public or sell it on the dark web unless the enterprise met their extortion demands. And in true escalation, when even that wasn't producing the results they sought, they further threatened to use the exfiltrated data to contact the victim's clients and customers directly, informing them that the company had lost control of their personal and presumably private data. So this brings us current, where today, believe it or not, we have yet another step upward in this seemingly endless escalation. The ransomware group known as ALPHV, who uses the BlackCat ransomware, claims to have breached the systems of MeridianLink, a company based in California that provides digital lending solutions for financial institutions and data verification solutions for consumers. So seemingly quite sensitive data. This cybercrime gang claims to have stolen a significant amount of both customer data and operational information belonging to MeridianLink, and they've been threatening to leak it unless a ransom is paid. But apparently negotiations were not going as well as they'd hoped so they decided to escalate. What could they do to make matters worse for MeridianLink? In an effort to increase their chances of getting paid - and this doesn't quite make sense to me either - the malicious hackers claim, and have presented documentary evidence, to have filed - I love this - a complaint with the U.S. Securities and Exchange Commission, our SEC, against MeridianLink, accusing the company of failing to disclose the breach - which they themselves perpetrated. |
| Leo: Wow. That is chutzpah. Wow. Holy cow. |
| Steve: Within four business days, as required by the new rules announced by the SEC last July. So the group published screenshots on its leak website last Wednesday, November 15th, showing that the complaint has been filed and received by the SEC. I have a screen shot in the show notes. From their multiple-choice selection, they chose "Material misstatement or omission in a company's public filings or financial statements, or a failure to file." Under the category that best describes the complaint they chose, they selected "Failure to file reports." And in the fill-in field for "In your own words, describe the conduct or situation you are complaining about," these criminals wrote: "We want to bring to your attention..." |
| Leo: Wow. |
| Steve: I know. It's wonderful. "We want to bring to your attention a concerning issue regarding MeridianLink's compliance with the recently adopted cybersecurity incident disclosure rules. It has come to our attention that MeridianLink, in light of a significant breach compromising customer data and operational information, has failed to file the requisite disclosure under Item 1.05 of Form 8-K within the stipulated four business days, as mandated by the new SEC rules." Okay, now, I want to pause here for a moment to take note that the grammar used in this posting is uncharacteristically excellent. |
| Leo: Native English speaker, I'd say. |
| Steve: Uh-huh, well, since this is so rarely seen from non-native English speakers, and the ALPHV gang operates out of Russia, my first thought was that ChatGPT, or one of its ilk... |
| Leo: Oh, yeah, sure, sure. |
| Steve: ...may have had a hand, or a register, in producing this prose. You know; right? |
| Leo: Of course, yeah. |
| Steve: So however, nice as that bit was, the group screwed up a few other substantive and material details that directly bear on the success of this. First, there's some confusion over the date of the breach. The hackers told the site "DataBreaches.net" that the attack against MeridianLink which only involved data theft, not file encryption was conducted two Tuesdays ago, on November 7th, and that it was discovered by MeridianLink the same day. However, MeridianLink has told the tech press that the intrusion occurred three days later, on Friday, November 10th. They said: "Upon discovery on the same day, we acted immediately to contain the threat and engaged a team of third-party experts to investigate the incident. Based on our investigation to date, we have identified no evidence of unauthorized access to our production platforms, and the incident has caused minimal business interruption." Okay, now, of course, no evidence is not proof that it didn't happen, just that they're able to legally say, assuming that it's true and they were using a third party, so like they can't obfuscate there, that there's no evidence. So, okay. It is data exfiltration, not encryption, so no business interruption would have been expected to have occurred. If MeridianLink is able to assert formally, as they apparently have in reporting, that they quickly detected the breach, engaged a third-party forensics team, and have so far identified no evidence of unauthorized access to the system containing the sensitive customer data, then they would have had no cause to inform the SEC under the new four-day rule. Even so, though such disclosure would be prudent for any publicly traded company, that new four-day rule doesn't actually go into effect until the middle of next month on December 15th. The way that new and still-pending rule is written, companies will be required to notify the SEC within four business days of determining that a cybersecurity incident is material to investors, which - because, you know, it's the SEC - based on MeridianLink's statement, that does not appear to be the case. So I think it's probably significant that the one thing that appears to be conspicuously absent, even today, is a shred of actual proof of this breach from the attackers. Yeah, they got in. Did they get anything? They say yes. MeridianLink says no. The attackers have not managed to prove otherwise, and that's trivial to do if they actually have any data. |
| Leo: Sure, sure. [Crosstalk] to do, yeah. |
| Steve: You know? Yes. Uncharacteristically, following any true data breach, nothing has been posted to the dark web to confirm and prove that the attackers actually did obtain any sensitive data. So it appears that MeridianLink is correct in their statement that nothing material was obtained by the hackers, and that the entire extortion incident with the SEC may have been an empty threat. |
| Leo: Or the point; right? |
| Steve: Yes. Well, it's weird, too, because on their site they showed the evidence that they had submitted this, and the automated reply. And they said, "Now they have 24 hours to respond." |
| Leo: It's blackmail, yeah. |
| Steve: What, you just shot your load, what are you talking about, 24 hours? What do you have to threaten them with now? |
| Leo: Wow. |
| Steve: Anyway, you know, despite all the fact that this may be empty, it did make headlines in the tech press because, although threats have been made in the past by many ransomware and extortion gangs, alleging or saying, threatening that they would follow up their theft of data with reports to the SEC because it's occurred to people in the past that companies would be vulnerable to the need to report this, this does appear to be the first time a ransomware group has actually followed through and filed an SEC complaint against one of its victims. |
| Leo: That's hysterical. That's real chutzpah. |
| Steve: It really is. I just love the "It has come to our attention." Yeah, right. |
| Leo: Because we did it. |
| Steve: Because we did it to you. |
| Leo: Very nice. |
| Steve: Leo, let's take a break. We're at a good point. And then we're going to talk about Europe and their faulty radio encryption, basically circling back to something that we talked about previously. |
| Leo: Okay. Yeah. Actually, I see that the NYPD wants to spend $30 million to encrypt their radio traffic. |
| Steve: Yup. |
| Leo: Sometimes encryption could be used against you, not in your favor. But that's a story for another day. |
| Steve: Yup. |
| Leo: Now back to Mr. G. |
| Steve: So there's some welcome news in the world of open versus closed encryption standards. Last summer we covered the story of serious flaws being found in yet another closed and proprietary radio encryption system. The fastest way to bring everyone back up to speed is for me to share just the beginning of some coverage in WIRED about this discovery at the time. They said: "For more than 25 years, a technology used for critical data and voice radio communications around the world has been shrouded in secrecy to prevent anyone from closely scrutinizing its security properties for vulnerabilities. But now it's finally getting a public airing thanks to a small group of researchers in the Netherlands who got their hands on its viscera and found serious flaws, including a deliberate backdoor. "The backdoor, known for years by vendors that sold the technology, but not necessarily by customers, exists in an encryption algorithm baked into radios sold for commercial use in critical infrastructure. It's used to transmit encrypted data and commands in pipelines, railways, the electric grid, mass transit, and freight trains. It would allow someone to snoop on communications to learn how a system works, then potentially send commands to the radios that could trigger blackouts, halt gas pipeline flows, or reroute trains. "Researchers found a second vulnerability in a different part of the same radio technology that is used in more specialized systems sold exclusively to police forces, prison personnel, military, intelligence agencies, and emergency services, such as the C2000 communication system used by Dutch police, fire brigades, ambulance services, and Ministry of Defense for mission-critical voice and data communications. The flaw would let someone decrypt encrypted voice and data communications and send fraudulent messages to spread misinformation or redirect personnel and forces during critical times. "Three Dutch security analysts discovered the vulnerabilities, five in total, in a European radio standard called TETRA, short for Terrestrial Trunked Radio, which is used in radios made by Motorola, Damm, Hytera, and others. The standard has been used in radios since the '90s, but the flaws remained unknown because encryption algorithms used in TETRA were kept secret until now. The technology is not widely used in the U.S., where other radio standards are more commonly deployed. "But Caleb Mathis, a consultant with Ampere Industrial Security, conducted open source research for WIRED and uncovered contracts, press releases, and other documentation showing TETRA-based radios are used in at least two dozen critical infrastructures in the U.S. Because TETRA is embedded in radios supplied through resellers and system integrators like PowerTrunk, it's difficult to identify who exactly might be using them and for what. But Mathis helped WIRED identify several electric utilities, a state border control agency, an oil refinery, chemical plants, a major mass transit system on the East Coast, three international airports that use them for communications among security and ground crew personnel, and a U.S. Army training base." Okay. So back when this all broke we dug into this more deeply. But that explains the breadth and importance of this system. It's far more widely used throughout Europe than in the U.S., but that doesn't make its security any less important. The fact that the system is so old, and that it's been in place since the 1990s, likely explains part of the problem. Once again we have inertia. We think it's encrypted. The colorful glossy brochure says it uses super-fancy "Air Interface Encryption," whatever that is. And we already have a huge investment in these radios in the field, so we really don't want to be told that it's all crap, thank you very much. So here's the good news. Although the gears are turning as slowly as ever, after being bombarded with well-deserved criticism for keeping its crappy encryption algorithms secret for the past 25 years, after they were exposed as such, and not until, the European standards body ETSI, behind the TETRA algorithms, has finally decided to open them to the public for scrutiny. Although one could argue that those three Dutch security analysts have already done that. At the time, Matthew Green, the Johns Hopkins University cryptographer and professor whom we often quote, called the technology in use old-fashioned and behind the times for continuing a practice of secrecy that had long been abandoned by the security world. When asked about the recent decision to open the encryption now to the world, he said: "This whole idea of secret encryption algorithms is very 1960s and 1970s and quaint. It's nice to see them joining us here in the 21st Century." And now having made the decision to go public, they are owning it. ETSI's statement said: "Keeping cryptographic algorithms secret was common practice in the early 1990s when the original TETRA algorithms were designed. Public domain algorithms are now widely used to protect government and critical infrastructure networks, for example AES, the Advanced Encryption Standard, standardized by the U.S. government. Effective scrutiny of public-domain algorithms allows for any flaws to be uncovered and mitigated before widespread deployment occurs." So, yeah, right. As Matthew said: "Welcome to the 21st Century." But better late than never. And what will be interesting is to see whether they did better. Remember we talked about it, there was like the TEA, they called it T-E-A, TEA1, TEA2, TEA3, TEA4. Some of them were deliberately crippled, and those were like the ones they sold to governments that they trusted less and presumably didn't want them to have strong encryption and maybe be able to break into it if they needed to. And then now they've kept going to 6, 7, and 8. So we're going to be able to see if the new stuff is any good. So we don't know. Okay. Meanwhile, late next year, those green bubbles which appear in iMessage whenever the message's recipient is "out of system," which typically means an Android user, will be getting many more features. In a move that few saw coming, last Thursday Apple announced that it will be adopting the RCS - which stands for the Rich Communication Services - messaging standard. This will finally bring, for the first time, a wide range of iMessage-style features to messaging between iPhone and Android users. This has been actually made possible as RCS has continued to develop and become a more mature platform than it was when it first, you know, came out of the gate. So it's to the point now where Apple has said, yeah, okay, we understand we should be doing more for cross-platform messaging. RCS is what we'll use. So RCS on iPhone will bring many iMessage-style features to this new cross-platform messaging, you know, read receipts, typing indicators, high-quality images and videos, and much more. Their implementation will also give users the ability to share their location with other people inside text threads. And unlike regular SMS, RCS can work over mobile data or WiFi, as well. At the same time, iMessage isn't going anywhere. That's Apple's. It will continue to be the messaging platform used for all "in-system" communication between iPhone users. So RCS will simply replace SMS and MMS and exist separately from iMessage when it's available. And SMS and MMS will also continue to be the fallback when they're needed. So anyway, as an iPhone user myself, it will be nice to retain some of those goodies when messaging with other people who have the green bubbles in messaging. On my end, I'm still working on the dynamic server-side code-signing technology I'll be using for all future SpinRite and other commercial software downloads. My favorite discovery last week was finding that Yubico, you know, Yubico now makes their own HSM, I mean, a commercial product in HSM, which is, as we know, needed for secretly storing keys and securely storing keys and then using them internally to perform crypto operations inside the HSM so that those keys are never exposed to any possible hacking. And since their famous key is called the YubiKey, it won't surprise anyone to learn that their HSM is the YubiHSM. There's a YubiHSM 2 and a YubiHSM 2 FIPS which provides additional certification assurances. Since EV code-signing certificates can only be signed by a FIPS-certified HSM, Yubico has that covered for me. Aside from the fact that it's by Yubico, which would be reason enough for me, it is vastly more capable than that Gemalto/Thales SafeNet 5110 dongle that I've been using for manual code signing so far. It's able to hold many more keys, it can work with much longer keys, and it supports many more recent crypto algorithms. The Gemalto/Thales device that I'd been using, the SafeNet, it has virtually zero developer support. I wrote to them last week requesting access to their developer SDK, and I received the reply, basically: "You didn't purchase it from us, so go away." By comparison, Yubico's developer support is astonishing, and it's all published out in the open for anyone to have and to hold. The product has been around for a while, so it's only that I hadn't been paying attention that I wasn't aware of the YubiHSM 1, which has now been replaced by the YubiHSM 2. And needless to say, for anyone who may have been thinking, with all the attention we've recently been giving to the need for an HSM, that switching to one might make sense, now you know that a favorite company of ours, Yubi, also offers a terrific-looking solution. So I will be spending more time with it after today's podcast. Okay. Let's close some loops. PhobicCarrot tweeted to me: "@SGgrc: Is this a joke?" He's referring to the Barnacle, which we had a lot of fun with last week. He said: "Someone could easily slide something between the suction cup and the windshield to remove it. Haven't you ever removed a suction cup before? I'm guessing a playing card or credit card would do the trick." Now, one would also think that the company behind this had arranged some means for making that difficult to do. Fredrik tweeted: "@SGgrc: How do you beat Windshield Barnacle? As it turns out, to take off the Barnacle, all you need to do is run your vehicle's windshield defroster for 15 minutes, and then use a credit card or similar thin piece of plastic to release the suction cup around the edge." Okay, that was interesting. My guess is - and there are articles on the 'Net that confirm this. My guess is that the defroster heats the windshield, which causes the air trapped underneath the Barnacle's two massive suction cups to expand, right, as it gets hotter. That in turn lifts the whole system away from the windshield, which then allows a shim of any sort to be slid underneath to break the suction cup's seal. So apparently students have been having a lot of fun in the universities where this has been deployed, to the point that some universities have decided to back away from using it because it's causing more trouble than it's worth. Art Nilson tweeted: "Hi, Steve. I have a need to determine if a USB drive is fast or slow at writing. ReadSpeed and ValiDrive are very close to giving me this, but not quite there. Any suggestions?" Okay, well, ValiDrive is not a useful test for real world speed because it continuously alternates between tiny reads and tiny writes as part of its job. Not only is that not the way such drives are typically used, but my theory, which will be confirmed or repudiated before long, is that many thumb drives may have an especially difficult time getting ready to write after reading. Since ValiDrive is not the way drives are typically used, that's not something that many have been optimized to do very well, that is, to switch from reading to writing rapidly. They just don't need to, typically. ReadSpeed fails to meet your needs for two reasons. First, it won't run on USB. It was designed during the early SpinRite work as a test of SpinRite's new native drivers. So only on AHCI or ATA-connected drives. Secondly, you want a writing speed benchmark, not just reading. And ReadSpeed, as its name suggests, only benchmarks read speeds. Now, SpinRite 6.1 has a very nice new drive benchmarking system which will benchmark any drive, including USB drives, in three places: front, middle, and end. But like ReadSpeed, SpinRite is only benchmarking drive read performance. However, If you are a SpinRite owner, you could grab the latest pre-release code for SpinRite 6.1. Level 1 is a read-only test, and Level 3 writes back what Level 1 reads. So Level 3 is both reading and writing, but in large typical blocks that a drive would normally be used with. Until we get to SpinRite 7, SpinRite is still forced to access drives through the machine's BIOS. And that limits us to 127 512-byte sectors, but that's more than 65,000 bytes at a time. So far better than ValiDrive. SpinRite 6.1 also allows you to set precise starting and stopping points, down to the single physical sector number. So when it stops it shows and logs the exact elapsed time required to do whatever you told it to. So you could first run SpinRite at Level 1 over a specific region and specifically sized region of the drive, and note the time required for that pure reading operation. Then do exactly the same thing, but at Level 3. Since Level 3 only adds writing of what was read, the difference in the timing of the two levels will entirely be due to the drive's true writing speed for that amount of writing. And since SpinRite 6.1 also now logs not only the percentage of the drive, but also the exact physical sectors, you get the exact number of bytes by multiplying the sector span by 512 bytes per sector, and then calculate the drive's write bandwidth. Okay. Now, having just written all that, I realized that with a tiny change, ValiDrive could become a very nice freeware USB drive read and write performance benchmark. I never really knew why I was posting all of that read and write performance statistics with min, max, median, standard deviation, and variance, but now I know. All that would need to be changed for ValiDrive to become a very useful and precise benchmark for USB drives, would be to have it transfer much larger blocks of data at once. Then its measured performance, which ValiDrive already does beautifully, would echo a drive's speed in the real world. I have been planning to revisit ValiDrive once SpinRite 6.1 is packaged and finalized. So now I have another reason to create a ValiDrive 2.0. And that'll make it quite useful for more than just checking drives for their validity. Actually, I sent that reply back to Art via Twitter before I had hit on the idea of using SpinRite in this read and read/write mode. His reply tweet was: "I have been running it regularly during development, but my systems are all just boring. SpinRite always just worked." So he wasn't providing a lot of feedback in the newsgroup. You know, and the fact that we have 805 testers the last time I looked, and not that many people that are actively reporting problems, suggests that he's like most of the others. T A Hofer tweeted something interesting. He said: "Dear Steve. Thank you for your relentless coverage of the sometimes too exciting cybersecurity world, and for providing an insightful and entertaining way to earn CPEs. Listening to your coverage of Article 45 and QWACs" - you know, QWACs, which is the idea that certificates are going to be produced by EU countries - "or qualified website authentication certificates, it piqued my interest. And after some research, I thought I might be able to add perspectives to understand the motivations that I've observed having worked in financial services," he said, "the previous globally connected network before the Internet, in strategic, operational, and audit roles." He says: "Well, I am not for or against QWACs. I'm not even in the EU anymore. Nevertheless, these are a few thoughts about this from a compliance perspective. "The EU would definitely propose that technology is too big for any single country, and that's why they legislate for the territory of the EU. At the moment, practically all major providers are U.S.-based, operating under U.S. law. For example, the AWS CDN CloudFront operates in the Virginia region of AWS, where data passes through the territory of the U.S. Although you, residing within the U.S., enjoy the protections of the Constitution and other laws enforcing, for instance, your right to free speech and restricting unreasonable search and seizure, these protections do not apply to me and my data passing over there, as I reside in the UK. "The kerfuffle about GDPR, privacy, and safe harbor agreements with the U.S. were somewhat about companies, but more painfully about protections against government intrusion. Although it's true that companies terminate TLS sessions on the edge and do filtering for internal networks, so do CDNs covering a vast part of Internet traffic. And if routed through U.S. territory, the providers have obligations under U.S. law. That's why the EU would want to assert legal primacy over their own citizens and territories. "The financial services industry has already gone through this process about a decade ago, and U.S. international banks established local subsidiaries operating under the EU directives. Value-added tax or VAT is a similar example. It used to be possible to buy digital content from U.S. companies without VAT. Now it's not. They're all registered for VAT. Indeed, if you are a European client of Google, you would be contracting with Google Ireland, showing that large U.S. tech providers have already adapted to increasing local laws and regulations on technology. "Based on the materials available about QWACs, they appear to serve the exact opposite of eavesdropping. They appear to be THE banner. The idea is that if a QWAC has signed the site" - that is, you know, one of these certificates - "has signed the site certificate, then this would show in the address bar as OV and EV once did. Documentation available on the European Parliament website show that QWACs are considered super-EVs and would be used to provide assurance that users, and particularly payments providers, are connecting to legitimate counterparties. This way, QWACs would actually defeat eavesdropping and transparent TLS-terminating proxies because Cloudflare or AWS might be able to issue a valid certificate for the Swedish government website on the fly, but cannot issue one signed with a QWAC. "By the way, that would also be the simplest way to expose eavesdropping, if any. Just show a banner that the site used a QWAC-signed certificate. This also answers the challenge of technical feasibility. There is no need to insert a banner into web traffic, as the CA certificate being a QWAC is the banner. For the countries in question, the governments are the elected representatives providing the checks and balances over the technology companies, not the other way around. From Germany's or France's perspective, the Mozilla Foundation might not look like an organization that has to police them. Rather, they might demand that Mozilla put the countries' CAs in the trusted store if Mozilla wants to do business there. That's really the crux of the issue. The QWACs are already long there, just not added to the trust stores. "Mozilla might choose not to add them, but it is less unlikely that Apple, Google, Microsoft, and others would leave a market as big as the EU, just as large U.S. banks chose to operate under local laws there, too. And yes, that's a more fragmented world, for better or worse. Apologies, long message, hopefully somewhat useful. Wishing all the best and looking forward for 999," he said, "perhaps 0xAAA and beyond. Kind regards, Thomas." Okay. So I think Thomas's counterpoint brings up a lot of useful issues. It's certainly useful to see both sides of this. There are a couple of corrections, though, that I need to make. For one thing, CDNs like Cloudflare actually do terminate the HTTPS TLS connections coming into their proxies with their customer's actual certificate. I looked into this at one point and learned that they had several ways to do this. A customer could provide their certificate or make it available on the fly for Cloudflare's use without losing control over it. The system is very slick. But it also means that even fully proxied and decrypted communications would still bear that QWACs seal. So that would mean it was a false positive. If the presence of a QWACs certificate was somehow surfaced on the browser's UI chrome, where in this instance "chrome" is the generic term for all of the browser's non-webpage content window dressing, it would be providing a false assurance that eavesdropping had not occurred and was not possible. I have not spent too much time digging around into this myself because that time would be wasted if QWACs never materializes, as I hope it won't. And so many others feel similarly. But if it appears as though it's going to, then I'll definitely be coming up to speed on the details. The question is, is QWACs a countersigning of a certificate that was also signed by an existing Certificate Authority for browser trust, or can it be used standalone? It would seem that browsers could be designed to require that any QWACs-signed web certificate also be signed by a traditional CA. But then, even so, Thomas describes the effect of this as a sort of super-EV cert, which is likely accurate and exactly what the EU wants. The trouble with that is that the web industry already had "EV" which was shown proudly on the browser's chrome. And it collectively decided over time that it was a bad idea to show anything that could be interpreted as "extra trust and encryption goodness." You know, browsers' users would think that meant something more than it did. It could be abused, for example, by any site that got an EV cert, then used that cert to do bad things to its visitors under the misunderstood banner of "extra trust and encryption goodness." So if this eIDAS 2.0 QWACs business looks like something that will actually come to pass, you can count on receiving a 100% fully detailed description of exactly what it winds up being right here because I'm going to want to find out about it and share it. I received another note, which is a fitting follow-up to this, from a listener who asked me not to share his name. He wrote: "Hi, Steve. Thank you for your podcast. It's been a great source of information, laughs, and concerns. Your explanation of how root certificates work and how Article 45 could be misused has been a factor of stress." I guess for him. "I listened to the episodes 983 and 984, and then went on to read the show notes, just to be sure that it was as bad as I had understood. I was curious about the number of CAs trusted by my Firefox browser, and there it was: I counted 165 root certificates." |
| Leo: Wow. |
| Steve: Yikes, yeah. "After some manual cleaning, I was able to reduce this number to 84 entries. Some of these are from European countries, many from the United States and China, and then we have Slovakia, South Africa, Tunisia, Ecuador, and many more. From what I understand, any of these 165 root certificate counterparts could be used to intercept my communications. I have to trust that none of these 84 CAs" - which apparently survived his pruning - "will lose their signing private keys or be compromised by one of the powerful states that have the capability to intercept communications worldwide. So there's no way to ensure real privacy, even if I remove all but the root certificates that I know are needed for my communication, and the CA of the cert used in the TLS will be able to intercept it?" He ended that sentence with a question mark. So I'll say that, yes, that's 100% correct. Then he finishes: "Is it just me, or is this system still largely based on faith? It seems to rely on the expectation that all participants will all behave ethically all the time, and be highly competent in protecting their precious keys." Okay, so, yes, just to be clear, our current system of global trust is fragile. This is largely why so many well-placed parties have spoken out against the idea of having the EU mucking around in it in any way. All that can do is destabilize an already somewhat precarious system of trust. The reason the system we have today works at all is that the incentives strongly favor rigorously correct behavior from every single one of those trusted CAs. We've talked about this in the past, but it's worth refreshing briefly. Being able to charge money for encrypting the hash of a certificate after verifying its statements is a profitable privilege, not a right. And it's a privilege that those running the world's few root stores can and will and have rescinded after sufficient evidence of misconduct has been found. No CA wants to lose their privilege of charging money for encrypting a hash. So as I said, the incentives which are built into this system strongly favor rigorous compliance. We've talked about mistakes and deliberate misconduct here in the past. But overall, the whole trust-based system has been functioning amazingly well. And everyone wants it to stay that way, which is why allowing EU countries to unilaterally mandate that their individual countries' own certificates must be present in OS and web browser root stores, and that there can be absolutely no oversight or recourse or consideration by any browser, you know, that's just politicians with a bad idea running amok. The entire idea absolutely runs contrary to the historical communal spirit which has carefully evolved through the years and which, perhaps against all odds, has been working. And we just can't allow this to happen. Bad idea. Someone who tweeted with the handle "M" said: "Hey there, Steve. Long-time listener. I just wanted to pass along an observation about your musings on EU Article 45. It is in no way similar to the UK messaging demand. If Apple chooses to remove iMessage in the UK, there is absolutely zero impact to their bottom line. People in the UK still buy iPhones and Macs. But if the entire EU, an enormous market for any tech vendor, decides browsers and operating systems will conform, Apple, Microsoft, and every other publicly traded stock company will absolutely comply. "Remember, these companies are owned by stockholders. If Apple executives decided to drop such a major market on principle, their board would fire them before you could say 'fiduciary duty.' If their board refused to do that, the board would be replaced by the shareholders, many of them financial activists, sooner than you could say 'shareholder lawsuit.' Opportunities to exchange potential income for principled stands disappeared when they no longer owned a majority of their own stock. Thanks for the show." Okay. So I don't know how to reply to that, but I hope it doesn't turn out to be true. At the same time, M's logic seems sound. We did once have our browsers' crypto deliberately compromised by having strong crypto, any symmetric crypto with a key longer than 40 bits, classified in the U.S. as a munition and therefore against the law to export. Even crypto ideas, conversations, and the publication of papers about strong crypto was banned. It was a sad state of affairs at the time. The cryptographer Dan Bernstein sued the U.S. State Department using First Amendment free speech argument. Anyway, as I've been saying often more recently, we're all living through some very interesting times. Bob Van Valzah, he said: "I love having a personalized copy of SpinRite 6.0. But if you add code signing to personalization for 6.1, how will it ever develop a trusted reputation with AV tools? No two binaries will ever be the same." And yes, Bob, that is absolutely a problem that's been haunting me. But there were two points. I've confirmed that code signing with an EV certificate, as opposed to a non-EV cert, does convey special meaning to Microsoft's SmartScreen filter. It cares if the signer qualified to receive an EV certificate. And given the hoops that DigiCert jumps its certificate users through in order to qualify, I'm not surprised. Also, there's apparently some level of heuristics at play with the most modern AV. All of the test releases of SpinRite's Windows boot prep component have been signed, and they're all different. But for whatever reason, they have not been setting off alarms for SpinRite's testers in Windows, and even when I send them to VirusTotal. I've looked carefully at what VirusTotal has to say about them, and there does appear to be significant behavior and proximity matching going on for the specific purpose of reducing false positives for "near relatives" that have long been known to be benign. So I think we're going to be okay. |
| Leo: Well, I think it's a misunderstanding of how AVs work. They don't do a - they're not comparing binary to binary, hash to hash. They're looking at signatures. They're looking at strings. So they're not saying, oh, this binary is different from that binary, and this one's okay. They're looking for - aren't they looking for fingerprints of viruses via strings? |
| Steve: There's definitely that going on. But there's also reputation. Reputation counts a lot. |
| Leo: Sure. There's other Signals, and that's why an EV cert's good. And, I mean, obviously heuristics help because you're looking at the behavior of the app. But I don't think just because every binary is slightly different, that's going to impact it one way or the other. Right? They're not looking at the whole binary. |
| Steve: And it doesn't seem to be the case. |
| Leo: Yeah. |
| Steve: So his point... |
| Leo: That would be too costly and time-consuming. |
| Steve: Well, and his point was that, for example, the DNS Benchmark that's been downloaded more than eight million times, its signature has acquired a reputation, that is, its hash, the hash of that is what VirusTotal looks at. So if someone drops a copy of DNS Benchmark on VirusTotal... |
| Leo: Oh, I see, right. |
| Steve: It doesn't scan it. It just it already knows. |
| Leo: They don't bother. I get it, yeah. |
| Steve: That that is perfect. And so his concern is that every copy of SpinRite 6.1 that is downloaded will have a unique hash because it is personalized for each user. And he's right about that, but the EV cert matters, and there does seem to be some heuristics that are softening, exactly as you say, Leo. They've kind of gotten comfortable with that class of software. |
| Leo: Right. |
| Steve: And so it doesn't send up red flags. |
| Leo: Right. |
| Steve: Nathan, whose last name I'm not even going to try to pronounce, R-Z-E-P-E-C-K-I, it sounds like an eye test. Anyway, he said: "You mentioned you use a pfSense router. I'm interested in switching my router from a Ubiquiti Edge router to pfSense, mainly because I want to use multiple VLANs and WireGuard/Tailscale networks and so forth. Have you shared any details of what you use hardware-wise for pfSense, or could this be a topic for an episode? I know it's not directly security related for the show." Yeah, it kind of is. "But I would be interested in knowing some of what you're willing to share for your personal home/work/office setup. Thanks for reading this far, #securitynow." Okay. So I have been completely happy with the Netgate SG-1100 that I have here. It's a perfect starter router with three fully independent NIC interfaces, one for the WAN, and two for LANs that can be configured and filtered completely separately. As we know, that little router's "wall wart" power supply began causing it to reboot a few weeks ago. But after switching to another beefier 12V supply, it's returned to absolute stability. But when I was setting things up in the new home I was establishing with my wife, who at the time was my girlfriend, I chose differently. I went with Protectli, P-R-O-T-E-C-T-L-I, Protectli. And it's Protectli.com. Their website's home banner says: "#1 Appliance for Open-Source Software." I was recently actually totally by coincidence discussing them with Alex Neihaus, recall from Astaro, one of this podcast's original commercial supporters. He had independently settled upon Protectli, as well, and he is also 100% happy with his choice, as am I. So that's the direction I would go without question. I purchased a 4-port device, but they have 2, 4, and 6 ports in a very wide array of configurations and speeds. I have a link to their product comparisons page in the show notes, or you can just click on it on their website. And they even offer 4G cellular LTE failover in the case of a WAN outage to keep the network alive, you know, presumably at somewhat slower speed. The routers, you know, these things, basically they're just small PCs. They're user-configurable for storage, RAM, and processor. You can get it bare bones or with whatever software you want preinstalled by them, and it runs everything since it's essentially a generic fanless PC with either a Core Boot or AMI BIOS. You can purchase directly from them to get exactly the configuration you want, and Amazon also sells them off the shelf if you're in a hurry. Unless and until something better comes along, that's what I'll be doing and recommending in the future: P-R-O-T-E-C-T-L-I. Anon John wrote: "Hi, Steve. Something worth sharing: We've rolled out uBlock Origin, specifically to combat malvertising. Thus far it's only deployed in IT. We aim to deploy enterprise-wide, 25,000 users." He said: "We recently saw Redline stealer malware, where uBlock was not deployed, delivered via malvertising. It slid past EDR; but luckily, C2 comms were stopped by a cloud proxy. Blocking advertising categories at the proxy would be a choice, but that results in user browsing issues, and so far uBlock has generated barely a peep of user feedback. Perhaps this tale might encourage others to implement security controls for malvertising." And anyway, that's, you know, it's a great point. I just read, while I was putting things together, that ALPHV ransomware group is using malvertising to spread their malware. So, you know, and it's clicking on a link in an ad to receive some enterprise-level tool that was actually, you know, had a backdoor bundled into it, and that's how people were hurting themselves. So don't do that. And John's note caused me to also realize that we've only been talking about minimizing the annoyance of ads and tracking aspects. But again, I just wanted to reassert that malvertising is a big deal. And of course when he talked about proxies and blocking this stuff, my mind jumped to those ADAMnetworks guys I talked about a few weeks ago whose DNS-based trust and the use of trust-no-one whitelisting is also designed to perform the same sort of blocking. It would block the browser from ever loading the malvertising content in the first place. And like you wouldn't get the ad, you wouldn't get where the ad was linking to, and you wouldn't get any link back to command-and-control if someone were to, like, bring it into your enterprise mistakenly and allow it to get loose. So great thoughts and solutions. |
| Leo: It's also nice to know that uBlock works. |
| Steve: Yes. |
| Leo: Because we all recommend uBlock Origin and use it. Now, I don't know if you've seen this. This is I think recent news. Google has announced starting in June adblockers like uBlock Origin will be disabled in Chrome 127. They're rolling out Manifest v3. So it's unknown whether Edge is going to adopt Manifest v3. I think Opera said they wouldn't. Vivaldi said they wouldn't. And of course Firefox won't. |
| Steve: And are they both Chromium based? |
| Leo: Yeah. |
| Steve: So, okay. That's interesting. So that doesn't mean that the Chromium core determines what Manifest level a browser's running. |
| Leo: One hopes, yeah. |
| Steve: Well, otherwise, my point is if it does, then the other browsers can't... |
| Leo: [Crosstalk] Firefox. Yes. |
| Steve: Yeah. |
| Leo: You know, you can't use a Chromium browser. So there you go. That malware blocking you're doing with uBlock Origin, that may not work in Chrome starting in June. |
| Steve: Yikes. |
| Leo: Yikes. |
| Steve: And I wonder about things like Privacy Badger. It's probably [crosstalk]. |
| Leo: Probably not, yeah. A lot of extensions are blocked. And I understand, Google's point is that, well, extensions are inherently dangerous, and we don't control the security model of your extension, and all sorts of bad things can happen. It's true. You can have malver-extensions, just like malvertising. |
| Steve: Yup. |
| Leo: But I don't know if this is the right way to do it. I don't know. |
| Steve: Yikes. |
| Leo: Yeah. |
| Steve: Okay. So two last pieces. Mike asks: "So, can I change the declared size of my mostly fake 2TB stick that is actually 32GB, and can I then use that 32GB of storage? Thank you." Okay. From Mike's message it appears that he used ValiDrive on a 2TB drive and discovered that it only contained 32GB of actual memory. There's been some discussion of the prudence of reformatting a fake drive to its actual size. For example, GRC's InitDisk utility could be updated to incorporate a true drive-sizing feature. It would exactly locate the physical end of the drive, then intelligently give it a file system that matches the drive's true size, not its declared size. But the question was raised about the wisdom of ever trusting the memory of a drive which you receive from people who are clearly crooks and who are clearly in the "crook business" of selling deliberately bogus drives. For all we know, the chips they're using were swept up off the floor at the end of the shift because they failed other critical reliability tests. They got them cheap because no one else wanted them. They don't seem like a good place to place anything that anyone ever wants to retain. Since a true and authentic 32GB drive is very inexpensive I just checked, a SanDisk brand 32GB Ultra Flair USB 3.0 Flash Drive is $7.69 from Amazon. So why would you not use that? If one cares at all about the data they're storing on a drive, I think that would make much more sense than trying to take a crooked drive and straighten it out. You know, good luck. But I have to say I considered that before the discussion that we had over in GRC's news groups said, are you nuts? And I thought, yeah, okay, that would not probably be a good idea. Finally, Shoeless Scoop wrote: "I'm glad I used a Privacy card for LastPass because I canceled my account back when you aired the LastPass breach, and they have not stopped trying to charge my family membership." |
| Leo: Oh, wow. |
| Steve: Yeah. |
| Leo: But Privacy's great. So it's a win. One sponsor wins, another loses. Former sponsor LastPass, yeah, that's a loser. But at least Privacy worked, and that was a sponsor, too, yeah. |
| Steve: Yeah. He said: "Clearly the days of them being a good company are gone." And I didn't put it in the show notes, but he included, because it was private by DM, a picture of his statement from Privacy card showing the repeated attempts... |
| Leo: Declined, yeah. |
| Steve: ...from LastPass to bill a card on an account that he closed. So I just wanted to say to our listeners, I know that not everyone scrutinizes their credit card statements closely, especially for smaller charges, you know, the ones that have more digits and stick out, you know, you want to make sure that you know what those are. But it would be really creepy and really extra sad if LastPass was continuing to do this. |
| Leo: Yeah, no kidding. And they wouldn't be the only ones who do this, either. I mean, this is very common. |
| Steve: So ChaCha was designed by the individual I referred to earlier. |
| Leo: Brian Acton? |
| Steve: Dan Bernstein. |
| Leo: Oh, Dan Bernstein, yeah, yeah. |
| Steve: Dan Bernstein. And it is the follow-on from Salsa20, which is why ChaCha. |
| Leo: Is the next one going to be Merengue20 or Waltz20? Foxtrot. |
| Steve: I think maybe Dan is done. But... |
| Leo: I love that. ChaCha20. All right. |
| Steve: So the question: What do you get when you subtract 1973 from 2023? You get 50. And since the design for the Ethernet was first famously sketched out on the back of a coffee-stained napkin in 1973, earlier this year the Ethernet turned 50. Many podcast moons ago we thoroughly and deeply covered both the electrical and logical operation of the Ethernet. And its official birthday was widely celebrated in May. But just last Thursday, on the 16th, the IEEE Spectrum magazine posted a birthday retrospective that I thought everyone here would enjoy. With a bit of editing and my editorializing added, here's what they had to say under their title "Ethernet Is Still Going Strong After 50 Years. The technology," they wrote, "has become the standard LAN worldwide." And when you think about that, I mean, it's really something. |
| Leo: Really, it's everywhere. It's what I use; what you use. Everywhere. |
| Steve: Yes, yes. I mean, yes. That's just astonishing. |
| Leo: Because it's remarkable that something designed 50 years ago is still, you know, you can now get 10Gb, I mean, I bet you can go more. I mean, it's amazing. |
| Steve: Yup. Yup. So they wrote: "The Xerox Palo Alto Research Center in California has spawned many pioneering computer technologies including the Alto - the first personal computer to use a graphical user interface - and the first laser printer." And I'll stop there to mention, and I've said this before, I've talked about it in the past, but that printer, the first laser printer, was known as the XGP, you know, stood for Xerox Graphics Printer. And by pure coincidence I was there at the time. I clearly recall the silver serial number plaque on the back of the printer which had a whole bunch of zeroes and a single one. It was XGP-1. |
| Leo: Wow. Wow. |
| Steve: And I had the privilege of designing and building the first interface for that printer to the DEC PDP-10 at the nearby Stanford University Artificial Intelligence Lab which had employed me in the summer of 1973 while I was between high school and college. And there was an IMP, an Interface Message Processor, standing there and that I used to sort of look and think, I wonder what that is? Well, of course we know that was the birth of the Internet. |
| Leo: Wow. |
| Steve: So they wrote: "The PARC facility is also known for the invention of Ethernet, a networking technology that allows high-speed data transmission over coaxial cables. Ethernet has become the standard wired local area network around the world, and it is widely used in businesses and homes. It was honored this year as an IEEE Milestone, a half century after it was born. Ethernet's development began in 1973, when Charles P. Thacker, who was working on the design of the Alto computer, envisioned a network that would allow Altos to communicate with each other, as well as with laser printers and with PARC's gateway to the ARPANET. PARC researcher Robert M. Metcalfe, an IEEE Fellow, took on the challenge of creating the technology. Metcalfe soon was joined by computer scientist David Boggs." And actually what's not widely known is that the reason he was joined by David is that Bob cut himself badly cutting coax, and so Boggs stood in and like did the coax cutting because Metcalfe wasn't able to. And they were called, I think, the Boggsey Twins because they were spending so much time together. |
| Leo: Here is a picture of those days. And that is - was it this big? It looks like it's... |
| Steve: That's it. That is the printer. |
| Leo: It's a refrigerator. It's huge. |
| Steve: Yes. That is, that's the XGP. Holy crap. I haven't seen one forever. |
| Leo: Holy crap is right. |
| Steve: Yeah. It was - it stood that tall. And Leo, it had a single continuous roll of paper. |
| Leo: Wow. And a cutter then. |
| Steve: It was about a foot in diameter. And so you'd like put this sheet of paper, you know, like in it, and then it would just spool it and then cut it. And it had a bug, and the paper just came rolling out and never got cut. That was not good. |
| Leo: There it is. |
| Steve: Ah. |
| Leo: There is the paper, not getting cut. |
| Steve: Very cool. |
| Leo: Wow. Look at that. Holy cow. Put your hand in there, you're taking your life in your hands. |
| Steve: Oh, not good. |
| Leo: Wow. |
| Steve: Yeah, very cool. |
| Leo: Yeah. |
| Steve: So anyway, "Metcalfe and Boggs," they wrote, "had two criteria. The network had to be fast enough to support their laser printer." |
| Leo: Oh, wait a minute. Wait a minute. Here is a picture of SAIL with the XGP in the background. |
| Steve: Yes. Yes, yes, yes. |
| Leo: That's where you were. That's the lab. |
| Steve: Yes. I was there. Behind them was something known as the hand-eye table, which is what transfixed me because it was robotic cameras and robotic arms. And we're talking in 1973. |
| Leo: Wow. |
| Steve: And when you drove up the driveway to SAIL, there was a sign that said "Caution: Robot Vehicle in Operation." |
| Leo: Here's the XGP, lurking in the corner there. |
| Steve: Yup, that's exactly where it was located. |
| Leo: And there's young Steve Gibson, high school student. |
| Steve: I can't quite remember that guy's name in the background but he was - yeah. |
| Leo: That's so cool. |
| Steve: So that was a PDP-10 on that side and a PDP-6 is behind them. |
| Leo: So this is what you wrote the interface on. Wow. |
| Steve: Yup. Yup. |
| Leo: Okay, I'm impressed. |
| Steve: And a DECwriter. Very cool. Anyway. |
| Leo: Yeah, yeah. I'll send you the links. |
| Steve: I was there then, yeah. |
| Leo: Yup. |
| Steve: Okay. So they wrote: "Metcalfe and Boggs had two criteria: The network had to be fast enough to support their laser printer, and it had to connect hundreds of computers within the same building. The Ethernet design was inspired by the Additive Links On-line Hawaii Area network." Okay, now, this is one of those where you come up with a name afterwards. Additive Links On-line Hawaii Area network. |
| Leo: Oh, ALOHA. |
| Steve: ALOHAnet. That's right. It was a radio-based system at the University of Hawaii. Now, again, we're talking in the early '70s. Computers transmitted packets, prefaced by the addresses of the recipients, over a shared channel as soon as they had information to send. If two messages collided, the computers that had sent them would wait a random interval and try again. And as we know, this is exactly the way today's Ethernet operates. The brilliance of Bob's original conception was its simplicity. Essentially, an Ethernet network is a big party line to which everyone is attached. Anyone who wishes to talk on the line first listens to be sure the line is clear, that no one is currently talking. If so, the party who wishes to talk just does so. But since two waiting parties might start talking at exactly the same time, anyone who is talking is also listening to the same communal party line to detect any collision of their message with someone else's. The abbreviation that's been given to this little bit of brilliance is CSMA/CD which stands for carrier sense multiple access with collision detection. As the IEEE article noted, when two or more talkers detect that their message had collided with someone else's, they would each pick a back-off interval at random and wait again before trying. Now, this is somewhat similar when you think about it to the way the Internet itself operates, where - and this is the key - where the guarantees for delivery were almost counter-intuitively softened by deliberate design, like the Internet's deliberate lack of any guarantee that a packet sent would ever reach its destination. But the somewhat surprising result of these approaches was that the creation of quite robust networking systems occurred because the assumption of failure was deliberately designed into the system as part of the solution. |
| Leo: Isn't that fascinating, yeah. We can make it more robust, as long as you don't guarantee success. |
| Steve: Well, by designing failure into it. That is, you know, it was so cool. |
| Leo: Yeah, brilliant. |
| Steve: Okay. Now at the same time one of the obvious problems with this freewheeling system is congestion. The collision and random retry solution is very clever. And it works terrifically so long as the overhead from collisions and retries does not become too great, since none of that represents a successful use of the bandwidth. As a consequence, the Ethernet does suffer from one fatal flaw known as "congestion collapse." Ethernet does not degrade gracefully under too great a load, it collapses as everyone is trying and failing to get their message through without collision. There is, however, one simple solution to this, simply provide more bandwidth, which is what we've been doing ever since. Continuing with what the IEEE wrote, they said: "Metcalfe outlined his proposal, then called the Alto Aloha Network, in a now-famous memo to his colleagues. Using coaxial cables rather than radio waves would allow faster transmission of data and limit interference. The cables also meant that users could join or exit the network without having to shut off the entire system. In a 2004 oral history conducted by the IEEE History Center, Bob Metcalfe said: 'There was something called a cable television tap, which allows one to tap into a coax without cutting it. Therefore, Boggs and I chose coax as our means of communication. In the memo, I described the principles of operation: very distributed, no central control, and a single piece of 'ether.' "Metcalfe and Boggs designed the first system," they wrote, "of what is now known as the Ethernet in '73. It sent data at 2.94 Mb/s and was 'fast enough to feed the laser printer and easy to send through the coax,' Metcalfe told the IEEE History Center. A 9.5-millimeter thick and stiff coaxial cable was laid down the middle of a hall in the PARC building. The 500-meter cable had 100 transceiver nodes attached to it with N connectors, known as 'vampire taps' because each of the taps had small boxes with a hard shell and two probes that when you closed the box over the cable, they 'bit' through the cable's outer insulation to contact its copper core. Thus new nodes could be added while the existing connections were live literally on the fly. You could be tapping into virgin cable. "Each vampire tap had a D-type connector socket in it, consisting of a plug with nine pins that matched a socket with nine jacks. The sockets allowed Alto computers, printers, and file servers to attach to the network." Boy, those were exciting times. "To enable the devices to communicate, Metcalfe and Boggs created the first high-speed network interface card (NIC), a circuit board that is connected to a computer's motherboard. It included what is now known as an Ethernet port. "The researchers changed the name from the original Alto Aloha Network to Ethernet to make it clearer that the system could support any computer. PARC researcher Alan Kay recalled a comment Thacker had made early on, that 'coaxial cable is nothing but captive ether.'" |
| Leo: And the joke of course is scientists for a long time thought that - they couldn't figure out how light transmitted through a vacuum, so they invented a magical... |
| Steve: Ether. |
| Leo: ...ether that it was going through until Michelson and Morley proved... |
| Steve: A substance. |
| Leo: Yeah. So there's no - light does not need ether to travel through to transmit. |
| Steve: Yeah. |
| Leo: Yeah. So it's kind of fun they're using this word "ether." |
| Steve: Right. |
| Leo: This antiquated scientific word. |
| Steve: Yeah. So Metcalfe, Boggs, Thacker, and Butler Lampson were granted a U.S. patent in '78 for their invention. And I'm sure it was assigned to Xerox. Or actually I'm not sure because Intel and DEC both got involved. These guys continued to develop the technology. And seven years later, in 1980, PARC released Ethernet that ran at 10 Mb/s. That was the first commercial Ethernet that we used. The update was done in collaboration with researchers at Intel and Digital Equipment Corporation to create a version of Ethernet for broad industrial use. "Ethernet first became commercially available that year, in 1980, and quickly grew into the industry's Local Area Network (LAN) standard. To provide computer companies with a framework for the technology, in June of '83 Ethernet was adopted as a standard by the IEEE 802 Local Area Network Standards Committee. Currently," they finish, "the IEEE 802 family consists of 67 published standards, with 49 projects under development. The committee works with standards agencies worldwide to publish certain IEEE 802 standards as international guidelines." So of course today's Ethernet protocol is carried over twisted-pair, which is the cabling that we all use when we're using wired Ethernet; optical; and of course radio, which is the ubiquitous WiFi that has mostly replaced wires anywhere ad hoc networking is needed. The interconnection technology that began 50 years ago with a single long run down the center of the hallway is the technology that is now literally everywhere. |
| Leo: Truly amazing. And if you'd ever used Token Ring or any of the pre-Ethernet solutions, you realize what an amazing invention Ethernet was. I remember crawling around not even that long ago at a radio station that was - all the machines were networked, and but it was a serial network - and disconnecting my machine, bringing the entire network down. It had to all be connected in a ring. Ethernet is a miracle, for anybody who worked with pre-Ethernet technologies. Really incredible. Fifty years. |
| Steve: Yeah, it is. And, you know, the Internet is a similar miracle that we've talked about often. Again, both of them were designed to assume failure. |
| Leo: Brilliant. Yeah. |
| Steve: And that by building that in, they made an incredibly robust system. |
| Leo: And incidentally, that's how WiFi works. It's still a collision-based system. |
| Steve: Yup. |
| Leo: And it just works. It's just brilliant. Do you think that Metcalfe came up with that out of nowhere? Or was there some precedent for this? |
| Steve: It was the ALOHAnet that was using the same... |
| Leo: ALOHA was the first. Okay. |
| Steve: It was using that collision technology for radio. |
| Leo: It's really cool. It's so cool. |
| Steve: And then he grabbed it and further refined it. |
| Leo: I think really important, too, for younger people, younger than us, which is almost everybody, that they know about this because the history really gives you some reason to appreciate what we've got. It didn't just all spring out of the, you know, full flown out of the minds of the founders. |
| Steve: Yeah. |
| Leo: It's really been an amazing trip. Ethernet turned 50. And 50, by the way, ain't that old. It ain't that old; right, Steve? |
| Steve: That's right. I had products when I was 20 years old, when it was being born. |
| Leo: Exactly. Steve Gibson. GRC.com. I love doing this show, and I'm so glad that you bring us each week these nuggets, this information, stuff we can use today, stuff to think about from days gone by. You'll find Steve at his website, which does not stand for governance and compliance and any of that stuff. GRC.com, it stands for Gibson Research Corporation. Bye. |
| Steve: Thanks, buddy. Bye. |
|
 | Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy. |  |
| Last Edit: Nov 28, 2023 at 13:52 (566.46 days ago) | Viewed 6 times per day |