The following transcript was generated by AI and may contain inaccuracies.
Christopher Vance: Hello and welcome back to another episode of Mobile Unpacked with me, Chris Vance. This month, we’re taking a little bit of a detour. For the last few months, we’ve been talking a lot about the stuff that happens in your car, but I want to take a step back. In the fall we always have a lot of deeper research with the new iOS and Android releases that are coming out.
But this month I wanted to take a slight step back and talk about some of the roadblocks that I keep hearing about – ones we all need to be aware of. Sometimes we don’t think of them as roadblocks. Sometimes we don’t think of them as problems at all, because it’s just the way things have always been.
A little bit of backstory on this episode: I went out and talked to a bunch of examiners, and I said, “Hey, what are your roadblocks? What are the things that you’re seeing?” And it turns out, fundamentally, we’re all seeing a lot of the same problems. Some of them have tool fixes.
Some of them don’t necessarily have tool fixes today. But I thought it would be good to use this as a platform to discuss them. So we’re going to look at what a lot of folks out there are dealing with in terms of roadblocks, and some ways that we can try to navigate them.
Even if it’s not a solution, it’s something to consider as you work towards one, because for a lot of these there’s never going to be a single fix. The key is understanding when to adapt and change the things that aren’t working for you now. So let’s go ahead, and if you’re joining us for the first time, welcome.
My name is Christopher Vance, and I’m the Staff Technical Forensics Specialist at Magnet Forensics, which means I get to host Mobile Unpacked with you. I also get to do research for product and try to find new ways of doing the things that we’ve all done for a long time. For those that haven’t met me before, I’ve been in digital forensics for just about 20 years, mostly around mobile forensics, for the West Virginia State Police and Marshall University.
I’ve been with Magnet now for over a decade, helping to make our products better, as well as bringing the research that we’re doing internally to you, the community. If you’re joining us for the first time, welcome – we do this every month, so pull up a chair. With all that being said, let’s talk about some of these roadblocks.
Let’s be honest: mobile forensics has evolved a lot since I started. The days of needing 87 different tools on your desktop to hit a fraction of the phones out there, and buckets and buckets of cable connectors – a lot of those challenges have gone away.
But some of the ones I was dealing with when I was in the lab, we’re still fighting, because we’ve either never seen them as a big enough problem to solve, or we’ve just accepted them. So not every problem we talk about is going to have a really clean solution. Some of them you’re just going to have to think through.
Some of them are going to be changes you might need to make to your own workflows. But the reason I bring them up is that I want people to understand they’re not alone in these. There are some solutions out there that we can talk about, and there are things people have done that might help along the way, and I want to share those with you as much as I can.
Roadblock one: preserving the device state
I think the first and foremost roadblock in all of mobile forensics comes back to the preservation of the device state. You’re going to see some common themes throughout this episode, and this is one of them. Because if we’re not properly treating the device when we seize it, are we ever going to get the most possible success?
We know that in the mobile forensic process, step one is isolation, but isolation is not enough anymore. Simply removing something from the network doesn’t stop data from potentially being changed on the device. There are still processes running. iOS is notorious for this, and we’ve talked at length about it over the past year.
In truth, we need to be better about the device state – and it is getting better. We see more and more people doing this, and hopefully some of you know exactly what I’m talking about. My rule of thumb has always been: whatever state that device came to me in, I want to preserve it as much as possible.
If it came powered on, I’m going to keep it powered on as much as possible until I’m completely done with it. If it came to me locked, I’m going to try to keep it locked and not unlock it until I have some sort of preservation method in place, to make sure I don’t lose any data on state changes.
It really could mean the difference between getting the data or not. There are some devices which can only be accessed in an AFU state, and frankly, the data isn’t always the best if we don’t get the AFU state. So how do we get that information across to everyone? Because that’s really the biggest problem.
We’ll talk about education and some things you can do, but I had some great success reported from one of our examiners internally, who said, “I just started sending out a checklist, a go-by.” I think that’s a brilliant idea. There’s often a huge breakdown in information sharing between the field and the lab, and the best thing we can do is empower those who don’t have the same knowledge as us as much as possible – hence the premise of this show.
Think about an index card-sized checklist that you slip into every Faraday bag that goes out. Or if you’re not using Faraday bags, something you can hand out as a laminated card for officers in the field to keep. We need to get the information out to the entire chain.
People will say, “How are we going to isolate this phone?” Well, isolation can cause its own issues. If I’m isolating a phone through physical methods, I might be causing more power drain. I might not be able to isolate that phone with a software method because the user has locked down the options for me to change that. And do those options always turn everything off?
I like to look at this from two perspectives: software and physical. If you’re using a software method, like turning on airplane mode, that’s fine, but I personally don’t always think that’s enough. A lot of vendor tools now have preservation modes. I’m not going to talk too much about the two main tools that do this, but a preservation mode from either of those tools is great to use as software-based isolation, because both of them do that as part of their preservation process.
And of course, there are physical options: Faraday bags, arson cans, and good old cheap aluminium foil. But the problem is, can we isolate the device, power the device and preserve the device all at the same time? And with software isolation, the question is, can you access the switch?
Can I find the switch to turn on airplane mode? iOS has Control Center, which lets me swipe down from the top of the screen and enable airplane mode. But what if it’s not there, or it’s locked down? A user can change whether that setting appears in Control Center at all.
Also, does it actually turn off all the transmissions? Airplane mode really only turns off a few of them – it doesn’t shut down everything on all phones. At the same time, users can set it so that Wi-Fi and Bluetooth stay on in airplane mode, so my settings might not be the same as someone else’s, and what’s good enough on one phone might not be on another.
Android is the same way. Some Android phones I can’t even restart unless I know the passcode. So we can’t always enable these features from a software perspective. And are your endpoints, as I like to call them – your frontline examiners or whoever’s seizing these phones – educated on how to do this?
Now, it’s getting better, because frankly we’re all using one of two types of phones today: Android or iOS. I know there are probably still some BlackBerry holdouts out there somewhere. But if I’m using Android or iOS, I probably know how to turn it off on at least that one.
It’s a lot better nowadays without having to dive into 82 different menus. But this isn’t the be-all and end-all – it’s just one part of the equation. Personally, I always like to use two methods of isolation, one software and one physical, if I can. I like to use preservation modes and airplane mode, but then I also like to put the phone in a physical Faraday bag.
That way I’m adding a little extra. But remember, our roadblock here is preserving the state. We know we have to isolate the device to prevent remote wipes or remote access, but Faraday bags cost money, and I might not have the ability to preserve a phone on scene using a box that puts it into a special mode.
I might just be flying by the seat of my pants, having seized a phone. So you have to know how to deal with those situations. Faraday bags aren’t just expensive – everybody would need to have them, and you’d have to distribute them. Are they available? Obviously there are lower-cost options like arson cans and aluminium foil, but there’s a bit of education that goes along with those.
The reason I bring up these physical isolation problems is that they can create problems of their own. When you physically isolate a phone by putting it in a Faraday bag, you’re not telling the cellular and Wi-Fi antennas to stop working. You’re actually asking them to work harder, because they’re not seeing the signal they expect to see.
So they’ll often expend more power trying to reach outside the Faraday bag. That causes heat, which can cause damage. It can also simply cause the device to die and lose its state in the process, which is obviously not good. So physical isolation is good, but we also need to power that device.
Can I just slip a power bank inside my Faraday bag? Sure. Some Faraday bags even have shielded cables built in. The key is that if you’re just dropping a phone into a Faraday bag or an arson can, it’s going to be expending more power. So think of that as a potential problem you might encounter as part of this process.
So really, that roadblock is now three roadblocks. We’ve always treated this as isolation, but from the lab perspective, we have to be better about educating those in the field. Isolation has turned into three steps: isolate, maintain power and prevent reboots.
We want to prevent this device from turning off. Maintaining power is a big part of that, but it’s not the only piece, because a new roadblock has appeared in the last couple of years around power. Depending on the isolation method, the power draw can change rapidly. Can we keep up with that?
Travel power banks are great, but have they been vetted and verified? Are you remembering to keep them charged? Does everybody have one they can drop into a Faraday bag along with the phone? This is why I like what I’d call a two-factor approach. If you can use airplane mode, turn those software switches off or use a preservation mode, that’s going to be best, in my opinion.
But if you can’t, using the software and physical methods together will help in those investigations. And of course, we have to prevent reboots, because that’s now one of our biggest problems. On iOS and Android, we now have potential reboots to deal with. On iOS, it’s pretty much every phone running iOS 18 and higher.
It gives us a 72-hour window, meaning I’ve got to get that phone connected to my acquisition tool of choice if I don’t have the passcode. In order to keep that AFU state, I’ve got to get that device connected and preserved.
Otherwise, I will lose that state. And let me be very clear here: I’ve heard a lot of “Don’t pop the SIM” or “Don’t hit the cop button.” Yes, don’t do those things, but not for that reason. The only way for an AFU phone to go to BFU is to reboot it.
That’s in terms of iOS. So we’ve got to prevent that from happening and make sure our devices stay on the clock, so to speak. Preservation modes are great for that. Android is a little different, and because Android is so fragmented, so is our rule here. We know Android devices can have their own reboot timers.
There’s one built in by default, but it’s not enabled by default – it’s part of the new Android Advanced Protection mode. Does that mean it will become more commonplace across all Android phones? I don’t have the answer to that, but it’s likely. And we know some phones, like GrapheneOS phones, can have even shorter reboot timers.
Honestly, on Android it’s just as important to maintain that AFU state. I know Android phones can often be brute-forced a bit more easily and maybe faster, but that could add additional complexity to your investigation. We really need to start treating every single device as though it’s got a timer ready to go off. I look at every phone now as a ticking time bomb.
I’ve got to get that phone preserved. I’ve got to isolate it, handle it with care and work my way around it. So keep that in mind: you’re not necessarily going to be able to stop this with just isolation and power anymore. I’m probably going to spend most of my time on this seizure roadblock, because it’s so important.
We have to make sure we’re connecting the phone to a tool that can prevent that reboot, or at least acquire the data before the reboot goes off. We have to take that into consideration on every one of these phones nowadays. So why does the state matter?
If you’re not familiar with this, the difference between AFU and BFU is significant. AFU and BFU are terms we’ve made up ourselves, but on an iOS device, I’m not going to get pretty much anything I want from a BFU extraction. I’m not going to get the texts, the contacts, the calls, the pictures.
I may get information about them, where they may reside and other sources I can go and look at, but I’m not going to get that data off the phone unless it’s AFU. The difference in data between knowing the passcode and not knowing it is really only a handful of data points.
They’re great data points – health, email, location data, passwords. All of these are amazing. But that’s really all a full extraction is going to give you above AFU. So keep that in mind: AFU is key. And on Android, some devices can only be accessed if they’re in an AFU state, because we might not have brute-forcing capabilities available on the market today.
Those are going to be a problem too. The reason this is in play is that pretty much all phones today use file-based encryption, so a device is at its safest when it’s powered off and just sitting in your pocket. The longer a phone has been powered on, the less secure it is – and I don’t mean that a phone that’s been on for six days is less secure than one that’s been on for ten minutes.
I mean that the longer a phone’s been powered on and the more it’s been used, the more likely it is to be AFU, and that means more data is available. On first boot, the only things decrypted are what’s absolutely required to function. The rest remains sealed. So we’ve got to help ourselves by getting beyond that state, getting the device into a good state and getting the data off when we can. The last thing I’ll say about this – and I know I’ve been talking about it a lot – is that the state is probably going to matter most.
On Android devices, don’t forget that you might have one password, but do you have all the passwords? On Android, there can be a lot of additional users created on the device. We’ve got Secure Folder and Private Space, and all of those could have separate passcodes.
So even though the person may have given you their passcode and you think it’s safe to turn the phone off, you may have just locked yourself out of the crucial data that’s in the vault. Keep those devices powered on. We want to maintain the state the device was seized in as much as possible through the acquisition process.
Roadblock two: device sizes
That’s not the only roadblock out there. Roadblock number one: isolation isn’t just isolation – we’ve got to deal with isolation and preservation. But there are other roadblocks at play when we talk about the device, and one of them to me is that device storage sizes have grown exponentially – a bit ridiculously.
I don’t necessarily need a terabyte of storage on my iPhone, but thanks, Apple, I guess I appreciate that. I want us to start thinking about this differently, and I think this is one of those times where we’re going to have to evaluate how we get around the size of devices by changing our workflow.
A terabyte phone is going to take a long time to pull the data off, and in some cases I may want every single file that’s on there. But do I always need every single file? Can I get to the more crucial data to see if it proves my point?
Warrants are starting to be scoped more tightly, because these devices are getting unwieldy in terms of size. Start paying attention to the amount of data you’re bringing across and how much of it you need to look at in each case. I know a lot of agencies have started changing their policies, so that the crime type determines what type of analysis they do – whether it’s a true full file system extraction, or more of a category extraction where they only target specific pieces.
There’s nothing wrong with doing that as long as your SOP allows for it. Do we need every single file? I’m going to get it if I can, but do we need to process every single file? Probably not. Is it good for us to do it? Sure, it’s always good. But who’s looking at the data?
Are you looking at the data? Did you look at everything when you processed everything? Or are you just hoping to avoid the awkward conversation of, “Well, I didn’t scan that”? These are things we have to keep in mind, because there’s no right answer here. Do we need to scan everything? Do we only scan certain things?
It depends on who you are, your operating procedures, your billable hours. There are a lot of different factors. But device sizes aren’t going away, and we’re always going to be limited by the amount of data we have to pull off and the transfer speed the device supports – even the iPhone 17 still uses USB 2.0 transfer speeds over USB-C.
Roadblock three: unsupported and proprietary data
So that’s always going to be a roadblock. Murphy’s Law says this stuff is always going to keep growing, so we just have to keep that in mind. And of course, unsupported data comes into play too, because bigger storage just means more room to put more stuff.
I have more apps, more things, more caches. And again, who’s looking at that data? No tool can support everything, and user-generated support has to come with some form of validation and verification. Folks, I love this community, and I love watching people put together their own tools, their own parsers and their own things, because that’s great.
We all need that, because it pushes us all forward. But if you’re going to build your own, especially today, you’ve got to do verification and validation. We can’t just vibe code our way into a successful court case. We can’t just say, “I fed this database to AI and it told me what it was.”
Without validation and verification, all you’ve done is guess, and we shouldn’t be going to court with guesses. We should be going to court with evidence that we’ve tried to verify using the scientific method. Alongside unsupported data comes proprietary data. Proprietary data types aren’t going away either.
They’re increasing. A few years ago, none of us knew what SEGB was, but now it’s on the tip of everybody’s tongue, because that’s where Apple puts all the good data these days – in these proprietary SEGB files. Protobufs have been around for a long time, and usually only small bits of data were stored in them, but now protobufs have exploded.
You’ve got things like ABX replacing a lot of the standard XML format on Android, and iOS loves to use different types of plist, some of them nested types within types. Data is going to stay proprietary – that’s just the way these companies are moving. So we have to have tools that can view it.
If your forensic tool doesn’t have a viewer for something, that doesn’t mean it’s not supported somewhere. We can’t rely on a single, solitary source. We have to be willing to go out and expand ourselves. You’re going to need a weird file viewer – something you’ve maybe never used before.
There are database viewers, rich text editors, metadata viewers. FFmpeg and ExifTool are two command line tools that I think every examiner needs to understand better, because they can help us do some really cool things and learn some really cool data points.
Understanding extended attributes is another thing I might need to do. I’m going to need weird file viewers. With proprietary data, the only way to solve that roadblock is to find the viewer – and until your forensic tool has every single viewer built in, be willing to explore other options.
I don’t think every forensic tool can put everything into one product, because then the product becomes too bloated. So you’re going to need something for that weird proprietary view. This is why I love the multi-tool approach – it’s my solution to a lot of the roadblocks that come from unsupported and proprietary data.
And that means the FOSS community. Shout-outs need to be given to the people out there building this stuff, like the LEAPP suite – you’ve got Alexis Brignoni and all of the developers who have contributed to it over time. You’ve got HEART from Metadata Forensics, and APOLLO from Sarah Edwards.
These are great for specialised data, and this is when a multi-tool approach can really come in handy. Do you need unified logs in every case? Maybe not. But if you do, you probably need a tool that does a really good job of looking at them. Should I just slam them into my general forensic case?
Sure, if you want to add a couple of million records that may have no bearing on anything. I don’t, but you might. So sometimes these multi-tool approaches are going to help you out – the LEAPP suite, HEART, APOLLO or anything else that’s out there. These are great.
Their goal is to view this highly specialised data – that’s their purpose. They’re great options, but there are some things we have to consider that come along with them, and this is where I’m going to keep talking about validation and verification. If you write your own data parser, congratulations.
That’s an awesome job. I’ve done it, and it’s great. There’s nothing better than that sense of accomplishment: “I started with a database no tool could parse, and now I have something that looks good.” But how many data points has it been tested against? Did you generate your own test data, or did you just work off the case you were given?
Was it the exact same version? The exact same phone? We don’t always have all this information. What we want to prevent is, “Hey, it worked on my machine.” That’s the last thing I want to say in court: “Well, I was able to parse the data. It worked on my machine. I don’t know why it didn’t for them.”
We have a really cool technology available to us. AI has its place. I can’t tell you how many requests I’ve had from people saying, “I asked ChatGPT,” or “I asked Claude, and it said this. What do you think?” And I’m going to be honest: AI is only as good as its input.
If these LLMs aren’t being kept up to date, they’re only going to have so much data to go off, and sometimes this data is highly specialised and there isn’t much information out there about it. There may be some, but I’m never going to trust AI to do the work for me, because this is a human decision.
I need to look at that data and make sure it is what it says it is. You’re not always going to be able to do that – sometimes you’ll be making a best guess, an educated guess, and validating as much as you can. But the truth is that asking AI is just a new version of asking Google. If you’d ask Google and go to court with that evidence, then you’d probably ask AI and go to court with that evidence.
I wouldn’t do either. Are we confident in the results that we ourselves found, or only in what someone else found? Do I want to say, “It wasn’t me, it was the one-armed man named Claude who did that”? Or was it me – I did the validation, I did the verification, and I proved as best I could that the data is what it is, without knowing the actual code that generated it?
That’s what we need to be doing. I think AI can help us get there faster, but it’s going to come down to human decisions and human judgement. So it all stems from the problem of too much data. Yes, there’s too much data, and we’re not always going to be able to parse and support all of it – and when we can, we want to make sure we validate and verify it as much as possible.
When a tool says, “I found this stuff. It’s pretty cool, right? Do you want to add it to your case?” that always needs to come with a full manual review of the information. I hate to say it, because none of us want to do it, but there it is.
Roadblock four: collaboration and sharing
Collaboration and sharing is the next one. This is one I feel we’ve all just accepted because it’s the way things are. When I was doing this in the lab, we put everything on optical media and mailed it out, and then we moved to USB. But the truth is that examiners and investigators are too siloed. We’re all part of one chain, but there’s information we don’t always get. Examiners don’t know the intricate details of the case – why Easy Money’s number appearing six minutes before the robbery was crucial to the investigation.
At the same time, investigators aren’t always going to understand the complexities of some of these artefacts – why it mattered that he connected to CarPlay at that moment, or why it mattered that a message we couldn’t find in the text messages is available thanks to an intent. That information isn’t always understood even at the examiner level.
So how could we expect it to be understood at the investigator or prosecutor level unless we share that information and collaborate more with them? That’s part of the problem with our current reporting. We typically generate PDFs or HTML, or maybe portable cases or readers, and we just hand them over.
We need a system where we can work together with the investigator. Investigators and examiners have to work together throughout the whole process – it will absolutely change how these cases flow. We’ve all had the case submission form with three pieces of information, and the vaguest information ever.
“One iPhone seized. Type of crime: drugs. Suspect: Joe Bob.” That’s not enough for an examiner to be effective. Examiners need to know what you’re looking for. Investigators need to know what they can look for. This goes back to education again, but you have to be able to collaborate and share that information between the two.
And the sneakernet kills this. Where does the examiner’s work live? Usually on the examiner’s machine in a lab, sometimes offline. I’ve got to get it to a prosecutor or an investigator. How are you going to do that? Are you going to put it on a USB drive or a server? Are you going to archive it?
Are you going to encrypt it? How are you going to protect it? Are you just dropping unencrypted CSAM on a drive and mailing it to somebody? I’m sure we are – we’ve done it in this industry for a long time because it was the only way we had. But tools have evolved. We can use tools like Magnet Review, and there are others out there.
I’m just calling out Review because it’s top of mind, since that’s where I work. But there are a lot of tools nowadays that give you that cloud view, and that’s going to be really crucial. More than anything, did they actually open it? With the way we’re doing things today, how can you tell whether the report got where it needed to go and the right people opened it?
Often we can’t. So the fix for that roadblock is to remove the sneakernet. Move to a system where you have audited control over who can see what. You need logs that tell you who saw what, when they accessed the data, and hopefully where they accessed it from. Then we know the right people are looking at the right things.
We can’t be all-seeing and know everything that’s happening everywhere all the time. But with systems that give us a little more visibility, I think it’ll help all of us in this collaboration effort.
Roadblock five: education
Finally, the last roadblock I think stands in our way is education. It’s time for a hard truth: we’re bad at this – as examiners, as investigators, as everybody in our industry. Sometimes we’re really bad at this. We have a set of knowledge, and either we want to protect it or other people aren’t always interested in it. So we have to figure out what needs to be shared, and share it the right way.
Digital forensics evolves every single day. Things change, and no one is going to be able to keep up with everything. That’s why I’m really glad you’re hopefully still watching this – you’re seeing the benefit of education in videos like this.
I’m not saying you need to go out and start your own Mobile Unpacked, but use these episodes, folks. Send them to other people in the chain so they understand the problems that are happening. Share the blog posts. Maybe give them a TL;DR version.
“Hey, this means we can now get this kind of data.” Use your internal meetings. The knowledge an examiner needs isn’t always the same as what an investigator or prosecutor needs. They may not need to understand the intricacies of the bits and bytes, but they need to understand what the data means.
Consider things like handouts, quick reads and periodic updates. Some of my biggest successes came from making things I could physically hand to someone as a reminder: an index card that lived inside a Faraday bag reminding them of the proper procedures, or a one-page go-by that went with every case submission form, detailing the specific information we wanted and the things we needed them to do.
I couldn’t change the form without a mountain of bureaucracy, but there was nothing to say I couldn’t include an extra page with that form when I handed it out. And don’t sleep on free training. If you’re using a tool like Review, learn about it.
Don’t just assume, “It’s a webpage, I can figure it out.” Take advantage of any free training and learning guides the tool offers, because tools change – especially as we move into a SaaS world, things change very quickly. So: education, education, education.
Clearing the roadblocks
How do we solve any of the roadblocks we’ve talked about? The first step is education. We’ve covered several different roadblocks, and I don’t think any of them will be shockers to most people, but they’re ones we all need to remember we have to deal with and discuss.
Roadblocks aren’t going to stop us. They might slow us down, and they might prevent us from doing some of the things we want to do, but they’re not going to stop us. I always hear, “This is going to be the end of digital forensics,” or “the end of mobile forensics.” We’re not there yet, and I don’t think we’ll ever get there, because we’re going to keep evolving, just like the devices we’re dealing with. The single biggest roadblock you can remove, if you’re an investigator out there, is by maintaining the device state.
Keep it powered on, keep it isolated and prevent reboots. If that can be done, the likelihood of success in a lot of these cases is going to increase. That brings us to the second point: how do we learn about those things? Education. Education is the biggest roadblock-clearer we have. And don’t forget about more data.
More data, more data, more data. We always want more data. We want to parse more data and see more data. Don’t be afraid to use specialised tools for that, and don’t be afraid to break things out. It’s nice when it can all live in one pretty interface, but that’s not the way the world works.
Sometimes I’m going to have to take it to a LEAPP tool, or to HEART or APOLLO, or one of the many other tools out there. Maybe I’m going to need to parse things by hand with a script someone has hopefully written, or I’m going to have to write my own. And if I do, I need to validate it.
I need to show my work. I can’t just slap something together with Claude and say, “Hey, write my own forensic tool,” because I’d only be using it against data I’m never going to know the full story of. And without knowing the full story, we’re going to miss valuable context. More data is going to mean more validation.
That’s not something we can avoid. Key protocols are how we clear that roadblock. Do I need to look at everything? What’s required in this case? I don’t want us to start limiting ourselves by asking, “What’s the bare minimum I need to do?” But we do need to start setting proper boundaries for ourselves.
When is a case done? When I stop. We need to make those determinations internally, because we can’t keep playing around in the same cases when twenty more have come in. So how do we deal with these giant device sizes? We’ve got to look at our own procedures and ask, “Do we need to get everything?
Does this phone need to have absolutely everything dumped from it, or can we dump specific pieces of information and keep the device in evidence?” There are other ways we can go about things. The roadblocks aren’t going to stop us. They may slow us down, but we’re going to continue to evolve. And the biggest thing I can say is: education, education, education.
Keep coming to sessions like this. Go to conferences. Share these one-pagers with folks. If you want something AI is really great for, have it help you make these checklists and hand them out to people. Distribution of proper, correct information is the best way we can succeed.
And with all that being said, that’s another episode of Mobile Unpacked. Thank you so much for joining us. If this is your first episode, or someone sent it to you and it’s your first time watching, welcome. Hopefully you’ll find many more episodes out there that give you something to watch and be interested in.
Until next month, we’ll see you back here at the same time and place. Thank you so much for hanging out with me and talking about some of these roadblocks. We’ll see you again next month. Have a great one.
