Just How Secure Is Signal? || Tech Field Day News Rundown: March 26, 2025

LM skills, pay the bills. Google prefers Wiz AI app vulnerabilities. SoftBank amps up finops for fun and profit GTC goes Dynamo and holy bat signals in this episode of the Tech Field Day rundown.

Hello everyone, and welcome to the Tech Field Day rundown. Today is Wednesday, March the 26th. My name is Tom Hollingsworth and we are back with another great news roundup.

Uh, and I would like to inform everyone that it is National Little Red Wagon Day. Unfortunately, you can't ride because, uh, the backseat's broken in the axles dragon. And now that I got that camp song stuck in your head, I'd like to turn it over to my co-host for this episode.

Mr. Alistair Cook. Al, welcome back to the Rundown.

It's great to be here on the rundown. It is, of course also National Negar Day. So while you are dragging yourself along in that, uh, little red Wagon, um, you'll have a tasty snack to go with it.

Tom. Yeah, you're definitely gonna need a snack because we have a lot of news stories that are covering some things that are happening in the industry, some acquisitions, some security problems, and, uh, well, uh, we will get into that other thing here in just a little bit. Now, I want to, of course, talk about something that is the hot new rage for everybody out there in the space.

And that is of course, LLMs because the explosive growth in enterprises wanting to board the generative AI train has highlighted the shortage of expertise in building and operating LLM based applications. A recent study on LinkedIn showed that AI skills are in high demand and short supply. Maybe we need an AI agent to build AI applications for us.

Uh, will we always need humans to do these new skills or can we just build what we need, Alistair? Well, here's the fun part, is we have this dream that AI is going to build everything for us and we'll just sit back and have a life of leisure. Um, we are seeing some movements and progress in that, but that movement and progress is being driven by humans.

And that's really where this study highlighted that AI skills and building particularly generative AI tools, using large language models, is very much in demand among enterprise. And because as always, this is a relatively new field. The available skill levels of people is relatively low because it's early.

There aren't formal training courses. There are no university degrees in generative AI yet. And so the skills that have been built up slowly over personal experience, so brave and uh, quick learning, people have gotten in early and, uh, have built plenty of skills.

But the fast followers are just starting to come into the market with good skills around ai. It was also interesting to see that there are some really basic skill sets that are still in high demand in it in this LinkedIn study, particularly things like, uh, people management and communication. These do suggest that people are gonna be around for a long time.

But in fact, every time we look at a generative AI based application, we keep seeing a need for human judgment to still be applied because the current AI applications aren't general ai, that they're very much about pattern recognition and pattern and language recognition is what we see with generative ai. It's not really reasoning. And so reasoning and evaluation is still a human thing.

It's gonna be a very long time before these AI applications can actually replace a human's ability to judge. As they say, you're not gonna be replaced by an ai, but you may well be replaced by somebody who knows how to use an ai. And that skill in using and building AI is still a very in demand skill and, uh, I think will be for some time.

So if you look for a new career, let me think about learning around generative AI applications, particularly how to operate them in production, because that's the piece that I think is really missing, is understanding what the consequences are of having 20 or 30 different parts of your application that are using different large language models and potentially leading to some other issues. We'll cover it a little bit later in this episode. Google has successfully, uh, agreed to acquire the security firm whiz for $32 billion.

Uh, they tried earlier, they tried last year as we covered in July last year. We covered on the rundown that there was a failed attempt to buy Whiz by Google for a mere $23 billion up. Think the ante by $9 billion seems to have been good stuff.

This acquisition is a strategic move to strengthen Google Cloud security offerings, positioning it to better compete with Amazon Web Services and Microsoft Azure. By leveraging W'S technology, Google aims to enhance the security of its cloud infrastructure and applications, thereby attracting more enterprise customers. Tom, is Google lacking in enterprise customers?

Are they behind on enterprise and wanting to get there just with security? Yeah, they're solid number three, of course. The problem is, is that in order to get to number two, you're, you're gonna have to climb a pretty high mountain.

And, and I, I think back to, you know, one of those sage pieces of advice that, uh, my mom used to tell me, if you love something, let it go. If it comes back to you, it'll, it'll cost you an extra $9 billion. Yeah, mom was in finance.

Uh, here's the thing. Like we, we actually reported on this less than a year ago, July 24th, 2024, on that episode of the Rundown. We talked about the rumors that were swirling that Google was gonna buy Wiz, and everyone was sure that was gonna happen at the time.

And then Wiz walked away from that and they said, well, we think we can get more. And to their credit, they were right. I just don't think that everybody thought that this was what was gonna happen.

And I think I understand why. I think it's because the only other two people on the market that really could have afforded to shell out dozens of billions of dollars, were both developing their own infrastructure. And this is something that immediately puts Google into a very interesting market.

Um, when you're not Amazon or Microsoft, when you don't have ra name recognition like Coke or Pepsi, how do you differentiate yourself? Well, you have to be different somehow. Uh, maybe you're the more secure cloud.

Maybe you're the preferred cloud for Oracle workloads. Maybe you are the one that runs Red Hat the best. Who knows?

You can see that naming Oracle, naming IBM naming other ones. They're, they're very workload specific, right? And I've even said, you know, for a while that I think that, you know, uh, Google Compute Engine is really more of like, almost like a hobbyist thing where it's like, let's build it in GCE to make sure that it works with all these Google services, and then let's port it over to a real cloud to work.

Um, but I think that by offering, you know, really secure services that have a multi-cloud component to them, you can kind of basically say, well, we can run it in GC and then move it around as needed. Here's the thing though. We already know that Google is under very tight scrutiny from the US federal government.

Like they've even talked about the fact, as we mentioned on the rundown, that they may have to divest Chrome in order to beat some kind of antitrust regulation. And you might remember this from the nineties when people were trying to do it to Microsoft too. Uh, if you read or listen to any of the other media that we put out here on the future and groups specifically, uh, six five live with, uh, Daniel Newman and, uh, Patrick Morehead, they basic, Daniel basically said there's a 90% chance that this acquisition doesn't close.

'cause remember announcing that you're gonna buy somebody is step one. Step two is making sure that nobody has a problem with it. And now you have not only US regulatory agencies, but uk, Europe, and China all lining up.

And unless this is a slam dunk for any of those folks, this could get derailed at any point along the way. In fact, there are days where I seriously think that these folks talk to each other and just figure out who's gonna be the bad guy today. Um, remember that Wiz is an Israeli startup firm, which I, I believe I saw that this would be the biggest exit for an Israeli startup ever.

Um, so props to them for, for renegotiating basically a $9 billion upgrade. But they've gotta clear the regulatory hurdles. I I don't see how they're not, unless it's just the Department of Justice deciding we don't like that Google is amassing all of these pieces and we gotta knock 'em down a peg.

So stay tuned to the rundown, 'cause I'm sure we will be talking about this quite a bit. A new study from Tenable suggests that AI applications have a higher than average rate of security vulnerabilities. The baseline rate of 59% of cloud applications containing security vulnerabilities that were labeled as critical is pretty worrying.

However, tenable found that 72% of AI applications have have critical security vulnerabilities. Is this a rush to get AI into every possible part of the business to get all of that sweet, sweet venture capital funding that everybody seems to subsist off of? Or are we just finally getting to the point where nobody cares about security at all?

I think, uh, yeah, there's, there's this perception that in the cloud, security is somebody else's problem. And it's, it really is a, a concern that, uh, it is even more, more of a prevalence in, in AI applications. The tenable parts, uh, they, they survey particularly seems to point to AI applications being deployed on top of Linux that's built with bunches of, uh, libraries that may or may not contain vulnerabilities.

And having some, uh, awareness of what, what vulnerabilities and what libraries are using might be more of an issue on these AI applications. To me, that that smells of rush. This, these are really well known things.

Uh, it's really well known that using the wrong set of libraries underneath your application on Linux is going to lead to security vulnerabilities. And you need to be aware of this as you're building out your application. So there's, there's nothing particularly groundbreaking in what Tenable was highlighting here.

Other than that, there seems to be a much higher incidence for these AI applications. And that to me, smells of, we, we want to get this stuff out real fast and security is a, a blocker and a slower, so we're just gonna ignore it. Uh, that's terrifying, frankly, and a huge business risk.

Uh, the parts that that are tenable because they're a security scanning business also don't d drill into too much is the, the risk of these generative AI applications being hijacked and poisoned and used as ways of extracting information that shouldn't come out into public. Uh, particularly as we're starting to see more and more applications that are using tools like, uh, retrieval augmented generation to use proprietary corporate information to drive these applications, the risk of leaking that information out increases. And so, yeah, I think there's a, a significant issue with the speed at which people are rushing to get new AI applications out into production.

And it speaks to a lack of maturity and lack of skills. Uh, I mentioned that on an earlier a moment in this, uh, particular rundown that skills around building generative AI applications are, uh, in short supply and maturity around operating these things in production is definitely, uh, something that needs work from this study. And I, I think this is a place, again, great place to be, uh, heading out into your career and learning these, these skill sets.

If you're an operational person, um, generative AI is gonna be around for a while. And I think the knowledge and and ability amongst the, the staff that are running these things is, is going to be critical to making this successful and not leading to some large scale security, uh, exploit that then stops our movement and degenerative AI in its tracks. You've gotta get some return out of all of that venture capital money.

You've gotta get some return off that spending on building these applications. And if you've got big security vulnerabilities, yeah, your application may get shut down before that return turns up. Amper is getting amped up thanks to the purchase agreement from SoftBank.

The deals in all cash transaction valued at six and a half billion dollars and AMP has been covered on the rundown in the past. They built some pretty awesome ARM-based server chips and they're commercially viable. They're actually built these things out to be used across multiple clouds.

And we know that SoftBank has been very interested in ARM technology and uh, they've been involved in Project Stargate, which is a $500 billion investment in AI infrastructure in the us. Tom, why is SoftBank spending yet more money on arm? Well, they already own arm and I think that when they tried to sell it to Nvidia and that failed, they realized something, they have an asset that they can't offload easily, right?

There is way too much, I don't know, tension around who could possibly own this? Well then that means you're stuck with it. So you've gotta do something, right?

Well, you gotta diversify and that's the first thing that happens. Well, what is ARM really used for? Well, uh, it's used for mobile devices and that's where ampire comes in.

Ampire says, well, why can't we use it for servers? Just because everybody else is making X 86 servers doesn't mean that we can't. So Ampire kind of goes all in on arm, right?

And they start developing arm architectures and they succeed and they create a server architecture that people want to use. Now granted, you have to basically make your software run on arm, but that's not hard anymore. 'cause most people are developing for multiple architectures anyway.

But who else could use arm? Well, it'd be nice if you could use it in some kind of an accelerator, right? Like, like that's the other thing that ARM really gets used for is like DPU and Smart Nicks and things like that.

But there's more than just those on the market. There's, there's other kinds of accelerators too for specialized workloads like OpenAI, you know, that little scrappy startup company that's, uh, looking to make their name for themselves and oh yeah, it controls a massive amount of, um, you know, capital and infrastructure out there. And they look at that big trillion plus dollar valuation that that NVIDIA has that just keeps climbing and they're like, Hey, we want some of that too.

We want the hardware part of it. You know, I don't care if people are running open AI software on Nvidia, what if they could run open AI software on open AI hardware or on Partners Hardware? Well, who would partner with them?

I don't know. What if the same company was owned by SoftBank? Hmm hmm.

So they own arm, they own ampire. Now, what would happen if Ampire decided to make an accelerator specifically tailored for open AI workloads? There's no risk in it because most everybody runs on open AI right now.

Yeah, yeah, yeah. I know there's other models out there, but you know, the fact that LLM based research is literally synonymous with chat, GPT tells you that you, you've reached the Kleenex, Velcro, Oreo level of genericized trademarks, right? So developing for that market is not a bad way to do it, especially if you have somebody who's willing to foot the bill until you can get that moving along.

I think what's ultimately gonna happen is Ampire is gonna continue to do their server stuff, but the majority of their workflow, their research teams are going to go to building AI accelerators. And then open AI is gonna come out and say, well, open AI runs on anything, but if you run it, run it the fastest that you can, you need to run it on our AI accelerator cards, and they'll partner with other companies to put those cards and those servers because realistically speaking, other than the chips, they don't care about the rest of it. And they'll try to get those servers and accelerators put into clouds, which is where MPR was gonna put all their, uh, chips anyway.

And then you have open AI farms running whatever their latest model is optimized to run on ampire, ARM-based server architecture, and then you get to laugh all the way to the soft bank. So we'll see if that pans out. 5 billion is actually not that big of an investment when you think about it, considering there's $500 billion just sitting out there in the Stargate program.

Uh, by the way, that's the other Stargate program and the other one is O'Neill with two Ls, uh, which was still one of my favorite shows of all time. But I think that they're gonna try to get as much of that as they can and keep it in-house so that they can use it to pay back, um, the failed arm divestiture. The whole thing with WeWork, uh, SoftBank's looking for a win, and I think they might have found it here.

Now, Al, I don't know about you, but I keep hearing that public cloud is a very cost effective place to fail, but it can be a really expensive place if you wanna succeed. The shock of large charges for new cloud applications is well known and often followed by a real challenge of analyzing cloud providers bills to link costs to value a whole new category of cloud finops. Applications have grown up and sometimes they're driving repatriation of applications back to on-premises data centers.

So I have to ask the $64 trillion question, if you've ever gotten one of those Amazon bills, is cloud not the solution to every business? Whoa. Well, yeah, you'd you'd think that move it virtualize the process and move it to the cloud to, to quote, uh, Wally on a, uh, a cartoon from many years ago was the solution to everything.

And that suddenly everything is somebody else's problem. We just have our applications and our applications are wonderful, but we've all heard the stories of those bills coming back from cloud providers, those massive amounts of costs that we hadn't necessarily realized we were going to get. And the complexity of analyzing what's contributing to that cost is a significant challenge.

Uh, I know the story of Netflix having an entire Hadoop cluster to analyze the actual bill that they get from AWS. Uh, this seems like a huge amount of infrastructure required in order to work out what the heck is going on. And so cloud finops tools turning up is, is absolutely awesome.

Uh, these are tools that will automate the process of looking at your spend on a cloud provider and your utilization of resources and make optimization recommendations. A lot of the cloud finops vendors that I've looked at are about optimizing your use of a cloud rather than necessarily doing some arbitrage of where should we run this application? Maybe this application is better suited to somewhere we would not paying for the availability of an infinite pool of resource, because of course, public cloud providers, what you get is this near infinite pool of resource and you only pay for the resources you use if you don't need that scalability of the infinite pool of resources.

Maybe it's more cost effective to not use that near infinite pool and not pay the premium for having a near infinite pool available. And so we are definitely seeing some selective movement of applications, and this is just sensible business. The cloud's a great place for bursty workloads, workloads that are going to expand up hugely for a short period of time and then collapse back down again.

Now whether that short period of time is maybe spinning up, uh, Lambda functions, uh, functions as a service that run for 30 seconds at a time, and you may have a thousand of them running one minute and then five minutes later you may only have two of them running. That sort of scalability is hard to achieve on premises, but it doesn't characterize a heck of a lot of the traditional enterprise applications where the workload goes up a bit during the day as as staff are in their offices. And maybe it decreases a little bit overnight, but there aren't these huge peaks and troughs and there's the kind of applications that may end up being better on premises and Cloud finops tools are starting to drive some of this, starting to drive some of the sensible decisions about where you should place or which applications, which ones will benefit from being on a cloud provider and which ones won't get any pay off for being out in the cloud.

So being all in on just one platform can be a good solution for a small organization. But as the organizations get larger and larger, the diversity of requirements within the company tends to lead to a, a need for a diversity of solutions. And Cloud fops tools are helping us to work out where applications go.

I wouldn't say there's been a mass exodus from public cloud platforms. I think overall organizations that are using CloudOps tools will tend to be the mature organizations who are pretty committed to using cloud platforms and are probably just building more and more applications on public cloud, but are choosing some of the applications to remain on premises because they make more financial sense on premises than they do in the cloud. That sort of dogmatic everything in the cloud or Will die, uh, goes away.

And we start thinking more seriously about where's the right place to run this application, this part of this application. And we'll definitely see this continuing maturity amongst organizations. Cloud's been around for a long time, so we should be pretty mature with how we operate on it.

GTC last week was full of hardware talk. Lots of announcements are bigger, this and faster that, and more of those and more of these. But one new piece of software aims to make AI workloads even faster.

Nvidia Dynamo is the name of a new operating system aimed at reducing, uh, latency with AI requests and optimizing both the translation and return of results. Dynamo's a suite that will optimize requests from various inferencing engines such as Tensor and SG Lang, along with a large number of GPUs concurrently. Uh, Dynamo's also designed to work with frameworks like PyTorch.

They don't need to recode everything that you've released, uh, as code on GitHub or as prebuilt container images. Tom, what makes Dynamo so dynamic? In order to understand what they did here, you first have to understand how an AI system processes what you feed it.

So we focus a lot on what the AI system feeds us, right? The tokens that it kicks back, but it starts before that. So you break this down, the first part is what they call the prefill.

That is when you type in a prompt and hit enter, the system has to figure out what you are asking about. It has to translate that prompt into whatever it's gonna translate into, whether it's a SQL query or something else. Now, what you get back from a token perspective is called the decode.

And that is, oh, well I found these results, or I wrote your, uh, you know, essay on all equine on the Western front or what have you. So if you think of Prefill as the input and decode as the output, what Dynamo is doing is it is allowing for the prefill and the decode to be decoupled from each other and spread across a whole bunch of GPU workloads. That is very important because if you tie the prefill to the decode and tie that even if you could tie the prefill to the decode and then have to spread that across a certain number of GPUs, you're gonna run into a problem because do I allocate the same number of GPUs for both of those tasks?

I would argue you need far fewer of them for the average prefill than you do for the average decode. But here's where it gets even screw here. There are workloads that are asymmetric.

So think about the average person using a tool like chat, GPT to ask it what I would consider to be dumb questions. Those are like, you know, when they're using it like a search engine and they're asking you to spell check something or whatever, those are a wa of little decodes, right? Simple prefill, simple decode, but they're everywhere.

So you want to grow horizontally there. You want to have as many resources available as possible to answer those as quickly as as they can, but you need to make sure that they're all decoupled so that you're not tying up any one individual GPU resource, right? But then think about the way that there are certain people who use it.

Maybe you're feeding it a, a really complex image query or your, your, your prefill is very complicated. You know, like those, those things where like you hit enter and it has to chew on it for like three minutes before it even acknowledges that it's, it's received the prompt and then it has to do a lot of work on the backend to give you the decode. That would be what I would consider more of a vertical workload, right?

It's gonna take a lot of resources, a lot of time to build on that. So you're gonna tie up more of those there. You need more pre-fill resources in order to make that happen.

What Nvidia did is they basically wrote a system to figure that out for you. Like you put dynamo in front of your clustering and it will decide, do I need to scale horizontally? Do I need to scale vertically?

How much do I need to do on this prefill? How many GPUs don I need to spread it across. Oh, this looks like a really complicated decode.

I need to spread this further and wider. And it all runs magically on some customized version of Linux. And this is where Nvidia is gonna start trying to do hyper optimizations for all of those AI workloads.

Doesn't matter what you're gonna feed it, whether you're feeding it llama, whether you're feeding it, um, you know, clawed, whether you're feed, whatever you're giving it, whatever the model is, you need to optimize for all of those different dimensions of how it can be, you know, far wide, tall, short, whatever. And the fact that they're basically coming out and saying, all you gotta do is download our code and put it in there, and it still runs with PyTorch and it still runs with Tensor RT and SG Lang and all these other things that you've been building, we will just, we'll, we'll do the work in the background. And I don't know if you've noticed this or not, maybe you're not a coder.

I I know I'm not. But I have noticed this weird thing when you handle those kinds of things for people who write code, they stop writing code that optimizes for handling those things. You know, it's like, uh, I, I've covered this before on, on some things, but like when Facebook engineers wanted to rewrite a routing protocol because they're like, well, why are the hello packets only 512 bytes big?

Our links are way bigger than that. They're the hello packets for this other routing protocol are only 512 bytes. 'cause we used to work in systems that had less than one K that it could transmit in a particular packet.

So people are going to start coding their applications and become reliant upon Dynamo to spread those things around as opposed to hoping that you've coded it correctly so that you're not tying up too many GPU resources, which of course just means more money for Nvidia in the long run because Dynamo is really optimized to run on their hardware and, you know, we'll see what happens. But I props to Nvidia for not just saying, throw more GPUs at it and it'll make sense. So I gotta give 'em credit for that.

All right, it's time for our closer look story and yeah, it's fun. Uh, you may be a proponent of messaging privacy. I know I am.

And this week has been kind of big for that. Uh, there was a news story that broke on Monday that the editor in chief for the Atlantic Magazine was accidentally added to a signal group where members of the US government were talking about highly classified US military actions. The report kicked off a Firestone of, of, or a firestorm of congressional hearings, which are of course still ongoing about the nature of data sharing and privacy, not only for government officials, but for members of the defense and intelligence community.

And of course, it has also raised questions about the way that those same officials will often circumvent policy to facilitate those communications. Now, the nature of the group and their discussion topic is really political. Uh, let's not focus on that part.

Let's focus on the communications aspect. Why did they decide to use Signal? How can we be sure that it really is safe?

And what does this mean for government agencies that are still clamoring to create back doors into these protocols so that anybody can get in there and read whatever they want whenever they want. Al I know you're not from the us but I'm pretty sure this made the news in New Zealand. Hit me, man.

What do you think? Oh, man. Uh, you know, we, uh, we, we like seeing all of the crazy news coming out of the United States just as much as, as you like, seeing it happening in your own country.

Uh, one of the nice things in this, I think is, is that, um, signal is actually a really good secure tool. Uh, and it's also developed by company and a foundation that a US based, so both the signal LLC and the Signal Foundation are US based. And so the, the, the terror that this might all be going on over a, a Chinese owned or an aggressive state owned, uh, platform is, is less of a concern, uh, in terms of, uh, information security for, for transfers across Signal.

One of the principles of Signal is that the platform itself doesn't hold the decryption keys for the data that's being transferred across it. So the encryption is handled between the individual endpoint. So the people who are members of the same signal group are handling their encryption.

And so Signal as a platform can't read the data. That's a good thing. It means that the data that's in, in transit and in transfer is secured provided, of course, there's no back door that's been injected into the open source code for signal.

Ha. So government agencies wanted weakened encryption so that they could read other people's data. Hmm, interesting that this, the choice was to use signal here.

Um, you also hit on a really important question about why the heck are they using this open source tool and platform. Surely this defense communication that's about ongoing operational activity should be on a DOD secured environment. Uh, from the, the very limited exposure I've had to to military, um, comms and security, the sorts of things I was hearing on here are, are definitely not unclassified, they're definitely classified secret or or above.

This was definitely operational details that were being shared and that sort of information should be on DOD secured networks. I know when our defense force here in New Zealand communicates with DOD, there is significant amounts of effort put into making sure that the systems are secure and isolated so that you can't accidentally add some external third party to an operational communication. But it does seem that a bunch of this communication was not initiated by people who were actually in that, in deep in that defense kind of space.

And this is the challenge around having political control in operational components is that there is a discontinuity between the life experience of somebody in politics and the life experience of somebody who's working in defense and defense communications. And so that tendency to not have the ingrained necessity, that feeling of ingrained necessity that we use, the tools that match the security of the information we're conveying just isn't necessarily there for elected officials. And people are a little more tangential to, um, military operations.

So the tendency to then go shadow it, let's use a convenient tool that we can easily communicate with, rather than having to go through all of the clearances required, getting cleared devices, carrying a different device to connect to the secure network. Uh, it's not getting that have that get in the way of sharing information. There's always that, that tension time isn't there between open communication within a tool and flexibility and then the control that's required to do this securely and match operational requirements.

I don't know if you remember this or not, but there was this huge flap back in 2009 about the president carrying a blackberry and everyone was flipping out about it because they're like, oh my God, it's an insecure device. And eventually got to the point where they were able to secure it and that would allow the president to continue to receive email updates and things like that. And like it was a huge, huge deal to the point that when his successor took over an office and obviously seemed to prefer an iPhone, they didn't have a way to harden an iPhone and they weren't actually sure how that was gonna work.

So you ha you, you hit the nail on the head when you talked about the fact that there is a completely different communications infrastructure for secured data. Like the devices, they, they have to go through rigorous testing, right? And they don't have access to app stores, they don't have access to, you know, things that could potentially compromise them.

Here's another thing that you can't do. You can't install any, you can't side load anything. So the fact that Signal was list was that used for this communication means we know they weren't using their approved electronic devices.

What they were using was their personal electronic devices. I don't know about how it works in other parts of the world, but possessing classified information on a non-secured device, I believe is a crime. So we know that they were doing something they weren't supposed to, this is the one thing we know they were doing that they weren't supposed to because the other thing that those devices allow you to do is only create chats or, um, groups with people that have, uh, that have proven that they're on a secured device right?

Now, here's the deal. I trust signal more than just about anything else out there because of all the reasons that you listed off about how it's an in end-to-end encrypted model. I can get notified whenever the device changes, when the safety number changes, all that other stuff.

It's, it's everything you would want in a, in an encrypted secure communications protocol, not the least of which is that nobody really has the ability to get in and, and get that stuff. Could you imagine what would've happened if someone had backdoored the Secretary of Defense's phone or possibly the National Security Advisor's phone and they got access to all of those encrypted chats? Because let's be honest, they're not putting one of these on Telegram and one of these on Signal and one of these on WhatsApp.

They've picked one platform that accomplishes what they want to accomplish. And it goes around all of the other things that are going on because there's another policy implication in here that a lot of people have to understand. It's the preservation of data.

So when you communicate on a government device, all of the data that is communicated on said device is preserved for official records acts and things like freedom of information. Now, if the data's classified, you don't get to look at it unless you have the proper classification, uh, authority and need to know. So it's both, right?

Like that, that is basics of security. If you take your C-I-S-S-P, it's not just that it's top secret, you don't need to know what that data is, so you won't see it. But by going on personal devices and using an encrypted uh, messaging system, you're basically kind of doing an end run around the policy of data retention, right?

Which makes me wonder what exactly are you sharing that you don't want people to know about? Uh, but this, this all gets like stirred up in this huge problem, which is we now live in a hyperconnected society where people expect to be able to have this. And something as simple as whether or not you are allowed to even see information drives people insane.

Uh, think about the number of times that we've heard about Skiffs, secure compartmentalized information facilities. They're basically floating rooms inside of a room that are electronically shielded, where you are allowed to go in and read things, whether they're on an electronic document like an iPad or a Kindle or they're literal paper, but like you can't even bring a phone into a skiff like it is not allowed at all. Uh, here's another thing.

A lot of those devices, like I know for a fact that the nuclear regulatory agency has their own custom iPhone that doesn't have any cameras on it because you're not allowed to bring an electronic camera anywhere near a nuclear reactor. So we can make devices that are highly secured, we can make sure that people are doing things on them that are secured, but that's not gonna stop anybody from poking that and putting that phone down and texting their buddy and be like, Hey, guess what? I just found out?

To the point where if you go ask one of your legal friends, especially if they're a lawyer who works for a state, local or government agency, they have two phones, they have their work phone and they have their personal phone and narrow, the Twain shall meet because if you accidentally text a work thing on your personal phone or if you get a personal text on your work phone, that means that in discovery they can get both of them and that becomes public record from that point forward. And that is a huge problem because as we're gonna find out, I am relatively certain that none of the people involved in this communication understood the legal ramifications of what they did, and it's about to hurt them a lot. I'm gonna get off my soapbox for a minute and talk about something a lot more cool than that.

And that is of course the upcoming Tech Field Day events that we have. We have one coming up, it's actually, uh, in just two weeks. Uh, we're gonna be in Houston for a special tech field Day extra with HPE.

We're gonna be talking all about ProLiant Compute. Uh, Steven is gonna be down there enjoying the fine Texas weather and, uh, humidity and, uh, learning all about these great things that'll be taking place on April the eighth. com to see a lineup of the delegates who are gonna be there, as well as a, uh, agenda for all of the great presentations that you'll get to see.

And then at the end of the month, al, you're gonna be back with some more fun hardware and software. Yeah, there's gonna be a, an absolutely massive AI infrastructure field day too. That'll be the 22nd to 25th of April.

Yeah, you heard that right? Four days of AI Infrastructure Field Day. Uh, we'll be spending an entire day on site with Google.

We'll be at Juniper's office of offices for another day and we've got a whole bunch of other awesome sponsors coming up. This is going to be a, an absolutely epic event and stay tuned in for it. Um, Tom, to get such epicness into May, you've had to split it across two different weeks with Mobility Field Day and Security Field Date, both.

Lucky number 13 for you Exactly. Um, mobility Field Day is gonna be enormous. Just go to the website and check that out.

May 7th and eighth. Yeah, I know know Mother's Day, weekends that weekend, but that's not important right now. What's important is we're gonna be talking all about wifi seven.

We're gonna be talking about other hardware and lots of cool stuff that's going on in, in wireless and mobility. So set your calendar for that. And then at the end of the month, right at, you know, Memorial Day is on Monday, and then we are rolling right into Security Field Day.

And we have, you know, whether it's data protection, whether it's AI security, you name it, we are gonna be adding some big names to the website very, very soon. So you're gonna want to tune in and take a list of all of that. And in both cases, we have amazing delegates who will be joining us.

In fact, they should be listed on the website right now. Uh, if one of those is your favorite, if you have, uh, are a fan of some of the outspoken people that we bring to these events, make sure you follow along and, and, you know, check out social media and use the hashtags for those events because that's where, uh, a lot of our fun conversations get to happen. And we want to thank everybody for watching this episode of The Tech Field Day Rundown.

Remember that we do publish new episodes every Wednesday on YouTube, uh, also on our website and, uh, in favorite podcast application, whatever the case may be. Uh, don't forget that we are streaming on Techstrong TV as well. Uh, we're also listed in amongst the other Techstrong and Futurum group programs.

And, uh, we'll be back next Wednesday to talk about all the IT news of the week. That was, uh, unless we get added to that Super secret Signal group, in which case we'll be discussing the news in there. And then we'll let a reporter, uh, tell everybody about it the next day.

Uh, but for myself, Tom Hollingsworth, for Ster Cook and all the great other people here, ed Tech Field Day, thank you very much for tuning in and we'll see you next week.