Episode 8

Android On-Device Scam Fighting

with Dave Kleidermacher of Google

Show Notes

Dave Kleidermacher is a vice president of engineering at Google, leading engineering for Android security and privacy. His scope encompasses Android and the Made-by-Google world — Pixel, Nest, Fitbit, and the Play Store.

We talked about Android's answer to scams: smarter defenses that use AI as a shield (on-device detection that catches scams as they unfold), and a deeper structural pivot to "Actor Trust" — establishing provable, cryptographic confidence in who or what a source is rather than forever trying to detect bad things.

Dave has been steeped in these topics for a long time so we get into a bunch of great territory, and I think you'll really enjoy the conversation.

Key Highlights

  • Consumer platforms must pivot from traditional vulnerability exploitation defenses to fighting scams and fraud, which make up 99% of actual practical threats facing users today.
  • The future of mobile authentication lies in reversing security asymmetry through "actor trust" — cryptographically verifying the source device rather than relying on human intuition.
  • Big Tech players like Apple and Google need to publish a transparent, accountability-driven joint priority roadmap to accelerate cross-platform security for critical defenses like caller verification.
  • Mobile network operators remain a critical structural weak point in consumer safety due to privacy-invasive habits like silent third-party app installations and outdated location-tracking protocols.

Chapter Timestamps

  • 00:00Introduction and Background
  • 03:01The Shift from Vulnerability Threats to Scam Prevention
  • 06:01Real-time Voice Spoofing Capabilities and Demonstrations
  • 08:19Platform Defense Strategies and the Whack-a-Mole Problem
  • 11:00Actor Trust and Cryptographic Verification Approach
  • 15:37Google's Security Key Success and Developer Ecosystem Verification
  • 17:35RCS Standards and Industry Collaboration Challenges
  • 27:19Business Caller Verification and Stir Shaken Limitations
  • 31:59Privacy-Security Balance and Binary Transparency
  • 41:30Consumer Role and Stakeholder Responsibilities
  • 43:27Future AI Landscape and Industry Recommendations
  • 49:47Advertising Technology and Platform Accountability

Transcript

There may be transcription errors: we apologize for those in advance.

Rob Leathern: Hi there, welcome to Won't Fix. I'm Rob Leathern, the co-founder and CEO of InfoHawk. Today we talk to Dave Kleidermacher. He leads engineering for Android security and privacy. We worked together when I worked at Google. And today we talk about Android's answer to scams, smarter defenses that use AI on the device as a shield. But also, we talked about a deeper pivot to something they call actor trust, provable cryptographic confidence in who or what a source is rather than forever trying to detect bad things. Dave has been steeped in these topics for a long time, so we get into a bunch of great territory. I think you'll enjoy the conversation. Thanks for joining us. And as always, let us know what you think.

Rob: Hey, Dave, it's good to see you.

Dave: Good to see you, Rob.

Rob: We're not going to bore anyone with how many times it took us to get this going. But you're VP of engineering at Google for security and privacy for Android and Made for Google. Is that what it's called? The Made for Google world?

Dave: Yeah, it's basically the connected products at Google. Yep. So it includes like the Pixel family and our smart home, smart health kind of stuff.

Rob: Right. And we worked together, colleagues a few years ago. We worked on some privacy and security-related stuff, which was a lot of fun. We probably can't mostly talk about. But I know there's a bunch of stuff you can talk about. So just why don't we start with how did you get to Google? What were you doing before? You have a deep security background. Tell us a little bit more about that.

Dave: Sure, Rob. Actually, before I jump in, one of the things that's really cool about your background and my background, I think we both share is this — like, I'm sure we'll talk a lot about privacy and sort of content safety and all that. And there's not that many people that have spent a lot of their time on both sides, right? You have people who focus on privacy, people who focus on trust and safety. And, you know, you and I have, I guess, been lucky or unlucky to kind of straddle both worlds, which I think makes us better defenders of the user.

But I've been in cybersecurity and in general, this general area of security and privacy for pretty much my whole career. So around 35 years. And I've been at Google for the past a little bit over nine years. Right before Google, I was the chief security officer at BlackBerry, where I led product security for the company for a while when they were launching their first Android devices. And that's how I got into a lot of, well, it's not the first experience with Android, but certainly one of the biggest experiences of the Android, especially in the enterprise context.

Rob: Almost a decade of Google. So you've seen a lot of stuff, a lot of interesting stuff. So recently, one of the things that obviously we've been in touch over time, but one of the things that caught my eye recently that you were talking about was the article in Wired about spoofing, the way you were helping a reporter hear their voice in spoofed format. And that's something I've been very worried about. So tell me a little bit about how that moment came about and what folks were talking about around that.

Dave: Yeah, sure. Maybe starting maybe at the highest level, like I think in the security realm that we work in, there's a lot of energy and discussion around traditional cybersecurity threats, like basically vulnerability exploitation, especially nowadays, right? You have the whole AI vulnapocalypse that has been very much in the news. And I think it's very easy to look at the news and the stories and think, well, in cybersecurity, the most important problem is how do we patch faster or get ahead of that whole apocalypse.

But while that is important and happy to talk more about all that, I would say that the biggest problems that face the average consumer in the world, especially the consumer, when you think about how you consume technology on your mobile devices and other sort of digital platforms, it really isn't vulnerability exploitation that users should be worried about. It is really the scams. It's the fraud and the financial fraud schemes that are truly a pandemic in the world. It's like 99 — I don't know what — the vast majority of practical threats are in that realm, not in vulnerability exploitation.

And so even though I am a cybersecurity person, I've spent a lot of my time in my career in that area, we actually spend more time overall in how do you combat those kinds of security threats that are not vulnerability threats. Again, we spent a lot of time on that as well, but it really is these scams and fraud things. And malware is a big piece of that in the mobile world, of course. But it's any format where you see people trying to socially engineer the consumer, get them to do bad things or try to take advantage of them.

Dave: This product, this new product launch that we were talking about with Wired is something that's really exciting because it's addressing one of the most pernicious scam vectors that are facing us today. And it is enabled to some extent with AI, where you have someone in your contact, someone like a family or friend who is calling you. You think they're calling you. You see the phone number ringing. You see it's their phone number and you think it's your friend and family. And actually, it's a criminal with a deepfake of your voice in real time acting like your contact. And of course, you think it's that person and they're going to socially engineer you to try to take some action immediately that will cause you to be harmed.

And so that is, while it is an emerging attack vector, I don't think it's too surprising to people. I remember back in, gosh, it was like 2018 or so. There are people in my team who were working with our AI folks. You might even remember this, Rob. I'm not sure if this hit your desk at the time, but like we were basically taking at the time the latest AI models, which are a far, far cry from where they are now, and taking audio recordings of my own speech and conference presentations and generating — AI generating — my voice. And at the time, it was like it took days, weeks, or whatever to process the data and create the audio. But it was really at the time, it was like, wow. But it showed everybody you cannot use audio as a biometric. That was sort of the point back then.

But fast forward to now, and what Lily did — Lily Hay Newman, by the way, who's an amazing reporter at Wired — what she saw there and we showed her a demo of was essentially imagine you're talking on the phone with yourself. That's kind of the demo, right? It's like you're in real time having a conversation and it's your own voice on the other end. It's kind of mind-boggling when that happens, but that is the exact kind of — it's very practical and feasible for criminals to impersonate someone's voice. Not to mention their video, but the voice one is the one that is really easy and really prevalent right now.

Rob: Yeah, we were at this conference recently and I was just sitting next to someone. I asked them to speak into my phone for 20 seconds. I transferred the audio file into the cloud. I had something set up on a gaming laptop in my garage, literally in my garage. And within three minutes, I had produced something that sounded just like this person, like a fake scam script of them being like, whatever, needing someone to do something on their behalf. So yeah, I think it's — I just don't think people realize how far this stuff has come, how quickly. And so it's really problematic. We've talked about that a bit on the podcast before, but I'm sure we'll talk about it a bunch more.

Rob: But what is the thing that Android is doing differently? Or where do you see the kinds of layers of protection being able to be deployed for not only voice? We can talk about the other — there's a lot of threat surfaces — but I'm very curious on the voice one because I frankly, on the social engineering stuff, I mean, we've talked with members of our family about having safe words and various things like that. I'm sure anyone who's in security has probably had some version of that conversation in the last six to 12 months with their family members. But curious how you see the role of the platform and what role the platform should play in this.

Dave: There's a lot going on with what we think we can do to improve platforms against a lot of these threats. And it's one of the things that's sort of a continual theme, and it's been throughout my career, but I think it's a big theme in this area — a lot of it feels like whack-a-mole. Like the malware area feels like this, right? It's like, oh, okay, we tweak our algorithms and we can detect some more things. But then the attackers just kind of tweak their things and it's just an arms race and you never feel like you're winning. And if you look at a lot of things that we've built, not just Google, but lots of companies that have built things, we have done a lot of that, right?

So the anti-malware area is a lot of really — the world's, I'd say the world's most advanced AI in the area of mobile threat defense. We've built it and we spend a lot of money trying to make it better. And we continue to do that. It's like not something you shouldn't do, but it's just sort of the starting point.

But then there's scam calls. So not the thing — we'll talk more about what we explained to Lily in the new launch — but what we've done before that was, yeah, you're actually trying to do detection of scams. So within the actual phone call, you can essentially, in a privacy-preserving way, using on-device AI, you can listen into the conversation and look for patterns of abuse, patterns of social engineering, sort of scam patterns. And the AI can detect a lot of these things and say, hey, by the way, you might be in a scam. Same thing for text messages. You can examine not just what's on your screen, but actually the whole conversation and do it in a privacy-preserving way.

And so there's like a lot of these AI investments that we have made and we will continue to make. And I find it a very cool thing to be able to take AI, which a lot of people think of as AI assistants and really cool features, but using it in defense is a wonderful thing. And I don't want to minimize it because it is an important defense in depth.

Dave: But the problem is it's this traditional issue we have in the security world that you're obviously super well aware of, and I'm sure many of your listeners — which is the security world has this seemingly impossible asymmetry. So we need to protect every possible angle of attack. And the attacker only needs to find one way to get through it. One way to fool you, one way to exploit you, and then they win. And so that asymmetry is terrible. It is why our job is so hard.

And so I've always, in my career, thought about like, how do you reverse the asymmetry? How do you find an approach that removes entire classes of attack vectors? Can you find a complete game changer? And AI isn't really that. In fact, there are people that say that AI is that. They're like, oh, with AI defenses, we can now scan all of our code for all vulnerabilities before it leaves the building. The AI is getting so good that we can detect all these things. But that's just not really true. I mean, yes, AI is helping us, but it's also helping them. It's helping the attacker. And so a lot of these problems are essentially unsolvable. Being able to prove that you can detect an arbitrary attack in almost all of these scenarios is impossible. So it is very good heuristically, and you should make it as good as you can. But what else can we do?

And so this anti-impersonation defense in calling is an example of that where we pivot from just trying to detect that the call has a pattern of abuse into a new mechanism, which is basically instead of trusting the voice, trust the device. How can we train people to not think of trusting the voice? And your example is another good example of that. It's like an out-of-band exchange of passcode — you're not trusting just the voice of the caller. You're doing something else that's more easy to have high confidence in. And so that changes the game.

And so this one uses a cryptographic verification that the caller was actually — with that phone number, the contact with that phone number was actually calling you from their device. And so if you're calling me and you're in my contacts and it sounds like you, the system will actually reach back and see, is that call being made from your phone? And if it's not, then that's when you know there's a good chance it's a scam.

Rob: I think this makes a lot of sense. Like I think — complete, you can't rely completely on identification. But one of the problems with identification is just that it's a bootstrapping problem. And it's one where we've been very — I don't want to say lazy, but we've kind of — you know, I'll give you a different example, which happened when I was at Facebook.

We were trying to do things like, okay, we want to treat the authorized, the people who are actually running for office and want to run political ads. We want to be able to treat them differently. So we started looking at government databases, the Federal Elections Commission, even state and local databases. Okay, is there like some way we can definitively know who's running for this office? And there really wasn't such a thing. So we ended up just verifying that it was a real person. And we knew we had their address, we had their identity, we had a bunch of stuff. But connecting these things together turns out to be really hard.

And so you have this problem where you can verify that someone is a thing and you can then verify them again later that they're the same person or thing that showed up before. But actually tying it down to something that's objectively true turns out to be really hard. But that said, I don't like the approach where people just say, oh, well, this is really too hard. Let's do nothing. So I think that doing something and then trying to create consistency and then trying to drive standards and trying to push things forward, I think is really important. And I think the perfect can be the enemy of the good when it comes to some of these methods, I think.

Dave: Yeah, I 100%. I don't want to, and again, I don't want to imply that you go after these sort of actor trust mechanisms and that precludes the need for the content detection things. I'm not saying that at all. I just feel like there's been so much energy in investing — investment and thought around detect the bad thing — that we don't spend enough of our energy on this actor trust mechanism, which is sort of fundamentally, you could achieve a higher level of confidence. You could also do, like you said, you can do really poor identity checks and you can get — you know, even we were using the RCS standard for this fake call detection stuff, and you could implement that really poorly. It's not like it's a perfect answer, but fundamentally, the cryptographic verification of identity has really been pretty, I think, pretty adequately proven to be way more powerful.

Dave: I actually have a really great example of this. When I joined BlackBerry, so back over 11 years ago now, on my first day as the BlackBerry CISO, I worked with the CIO to do a phishing test of the employee base. And we sent out a fake LinkedIn message that was basically, hey, I'm the new CISO. Great to meet you. Looking forward to meeting you all. Click here to connect with me. And 15% of the employee base engaged with this fake thing, including my manager who actually typed in his credentials and stuff.

So what that tells you is that even a small business with 20 people, if you're targeted and you're relying on your password as your authenticator, you're going to get compromised.

Now, Google realized this quite some time ago. And as you're well aware, because you had to plug it in and use it when you were here — Google switched to an unphishable security key authenticator around 10 years ago. And Google is like 190,000 employees today. And in that last decade, we have zero known phishing compromises of a Google employee account. Zero.

So going from like, you're almost guaranteed at 20 people to zero compromises with nearly 200,000 employees. And that's not total. Like over the time of the last decade, it's way more than 200,000 accounts, right? Like it's pretty incredible. And so that's a good example of actor trust and shifting from like, can you detect the phishing thing and try to somehow use your human intuition versus a cryptographic check? They're just completely different.

Rob: Yeah. So talk a little bit about the RCS and GSMA part of it and how — I'm always curious and interested in how these things become standardized. And when I was at Google, we open sourced a bunch of privacy-preserving technologies, my team did. And always was, there's obviously the just making it available piece. And then there's the how do you actually drive adoption? How do you get people to use this stuff? Can you talk a little bit about that? Because obviously also you're responsible for working on devices that the company builds, the Pixel, et cetera. And how do you kind of make the decision about how to keep it open, keep it as a competitive advantage, et cetera?

Dave: Yeah. I'm generally a very big proponent of openness in many forms, right? Open source, I think, is a good thing. I mean, it doesn't apply to everything, but it's a good thing to try to push for more transparency. Open standards, I'm a really big believer in that. And I think security and privacy is one of these areas where, yes, there is special sauce, there is intellectual property that's important. But when it comes to fundamental protocols, fundamental defenses, I think you need to lean more into openness.

The RCS standard is a great example of just saying, hey, we really — we have some great ideas here, but we want to make sure that there's carriers involved. There's other platforms involved. We need interoperability. And when you need interoperability, you do need standards. Unfortunately, sometimes those standards move too slow. It can be really frustrating.

In the case of working with Apple and RCS, it's been pretty well documented how we've relied on the RCS standard because it's just more comfortable for a lot of people to know we're not working on some bespoke protocol. We're working on a standard. So the RCS verification is what we've built the fake call detection on, but there's still aspects that are not defined by the standard. And so to make fake call detection work between Android and iPhones, which I hope will happen fast, Apple actually has to go do some work and change their phone call app to be able to handle the same check.

And so yes, the underlying protocol is standardized, but they have to do some work. And that's the part that I think is maybe a little more frustrating — there isn't anything that Google can necessarily do or that open standards or the GSMA can do to get the right entities to move on really important problems.

Dave: I think I hearken back to — you remember all the contact tracing stuff during the pandemic. And there was this amazing moment. It was one of the most rewarding moments for not just myself, but a lot of folks. And our teams, and I'm sure people on Apple's teams too, working together under a very tight deadline to put together this interoperable method of detecting in a privacy-preserving way, detecting these dangerous contacts and alerting to people and to help address the pandemic risk. And it was amazing to see Apple and Google working so closely and so quickly together under this sort of like global duress.

But so many other things don't work like that. And actually, I really wish security and safety, this area that we all work on here, could be an area where we would do more. And I always want to do more. I'm not to call out names, but I reach out to my counterparts at those other companies. I'm like, hey, let's do more together. Let's do interoperable end-to-end encryption for various things. Let's do video call interoperability and private video calling interoperability. And it just moves too slow because there's reasons. There's always reasons.

Rob: But I mean, sometimes I think it comes down to micro incentives almost. How is this team going to get — and I hate to — you know, it isn't always this way. I don't want people to think it's always this way, but sometimes it's like the micro incentive of how's this team going to get a good performance review at the end of the quarter, half year, or whatever it is. And it's like there sometimes seems to be lower hanging fruit vis-a-vis, okay, there's other things that they could build. Or sometimes it's like there's higher priority stuff. It's like, oh, well, we need to ship this regulatory thing that is now impacting us. Or, you know — so I do feel like there's a lot more that can be done. And I agree with you. And I think you and I have both been in some of those kinds of conversations where it's very frustrating because it just seems like it's a win for everyone to be a part of that thing.

Rob: And I guess, you know, one of the other areas — you talked a little bit about verification. So, you know, developer ecosystems, I've been very worried about how developers get access to certain tools and, you know, and you've seen reports of certain models getting distilled by people setting up hundreds and thousands of developer accounts and things in the AI LLM space specifically. But how do you think about the kind of same kind of content versus actor verification approaches to developer ecosystems or that kind of side of the world that you're involved in?

Dave: Right. Yeah, this is actually the developer ecosystem and this actor trust concept — it's another good example where I think the identity verification piece, if done well, can have just this outsized impact.

In fact, I'll share a little bit of a sort of a — well, it's not — we don't publish this metric regularly, but I think we've talked about it before — which is that if you look at the enforcements that happen on the Google Play App Store, around two-thirds of them, of those enforcements, are driven by developer signals and not the app signals themselves. So you look at the anti-malware technology looking at the app's behavior and trying to detect that it's collecting information or it's doing all these very evil things inside the app. It's actually a minority of the enforcements that occur because of that detection versus detecting things related to your identity and the signals around the developer.

And that's why — that's another example why I have such confidence in rooting things at some, you know, with this identity piece. And so we recently announced this program, this Android developer verification program, that is basically saying, look, there's some minimum level of goodness around the developer signal that you need if you want to keep people safe.

And frankly, if you look at Android and iOS, they're on these two sides of — well, I think people are well aware that there are these two sides of the spectrum of like Apple super lockdown, one app store, and no openness, no third-party app stores. And then you have Android, which of course allows third-party app stores, but also allows this like internet sideloading. And it's that internet sideloading that I think is on the wrong side of that spectrum. And I think there's ample evidence that shows that this arbitrary, unverified developer downloads is very dangerous. We have published many metrics. It's orders of magnitude. It's just very dangerous when you don't have a signal of the developer. And so the Android developer verification program is saying you need to have that signal.

Dave: And here's a good example of that. So I think it was in 2021, there was this pretty well-reported malware campaign called FuBot. It was attacking primarily in Europe. And what the attackers did was they basically just used polymorphic applications as well as websites. So they would just rapidly change the signature in the app as well as the source of the app being downloaded from the internet and just like fire out all these phishing messages to people, hundreds of millions of them, that say, hey, there's a package that I'm having a problem delivering. Click on here to learn more. First of all, install my DHL app and then you do that. And then the malware will then ask you to give it permissions. And unfortunately, consumers will fall for these things and be socially engineered into doing that. And then you're toast.

That was a really terrible campaign. You can read about it. You can go online and read about how Europol eventually took down the back-end infrastructure. It was just really terrible. And that kind of a campaign is completely eliminated with Android developer verification because those apps would not be verified. You have to go through what I think most people realize is just a common sense best practice of, does this developer actually — is this actually a developer, an Android developer that we have some confidence in? So that's the idea there.

Rob: Again, I think the theme here that I'm picking up, which is that you can't use — everyone's going to use AI to build stuff and content, the amount of content, I mean, the number of apps will increase, the amount of content will continue to increase. So you're going to have to do some level of identity, actor verification, trust, repetitive kind of trust-related exercises to verify folks.

I guess one thing, going back to calls that we started talking about at the start — so I've always found it insane how the phone system works in the United States, especially. But what about Stir/Shaken and some of the caller ID verification? I recently saw there's folks who are shipping — there's a couple of companies that have been building SDKs for banking apps so that while you're in the banking app and you get a phone call that's supposedly from the bank, you could actually — it could like tell you if that's the case. But I'm curious how you think about, or your experiences of — we can talk about carriers and where they land on some of these things — but some of the caller ID verification stuff to me just seemed like, why has that taken so long? Why has that not happened? What's the failure states been there?

Dave: Yeah, that's a great question. I think, you know, so the fake call detection that we were just talking about is a great solution for an individual and a contact, a family, a friend calling you. And it's a really insidious attack. And it's a good solution for that. But it doesn't solve the problem of a business or organization or government entity calling you and impersonating that entity. And for that, you need a similar concept of how can you know that this entity calling me is actually that entity.

And you alluded to a feature that we've implemented in Android that is a step in the right direction. And we've been piloting it with banks because banks, you know, the financial services industry is the area where we've seen just so much badness happen globally, where you basically integrate a flow where when you get a phone call and it's from a bank and you have that bank app installed, it does essentially a back-channel message to the bank saying, are you calling me? And then the bank integrates that flow into their back end. And they have call processing and customer service systems that know when they are calling a particular phone number and a particular customer. And so that integration takes a bunch of work that they have to do.

Once it's been implemented by a number of banks, it works really well, it's been great. It seems to really be working well. But unfortunately, it does require this sort of bespoke integration that is more energy for the bank to implement. So if you say, how do you now scale that to essentially any business, even a small business that might want to call a consumer and give the consumer confidence that, yes, it actually is the flower shop down the street and not someone impersonating the flower shop down the street — that's a much harder problem.

You mentioned Stir/Shaken. It's sort of like your point before — if you rely too much on identity that is weakly defined, then that doesn't necessarily solve anything either. And Stir/Shaken has some pretty well-understood weaknesses. It's just too easy to fake being on a valid carrier network with the Stir/Shaken thing. I mean, maybe the concept is good, but if the implementation just isn't there.

So I think the Android implementation works because it is actually a very clear integration into that back end. Now we need to think about, is there some better way, standardized way of enabling businesses — which frankly is just a much more difficult problem — any business, any organization in the world to have confidence in it — and not just confidence, like cryptographically verified confidence that the source of that phone call is really owned and operated by that business. That's a much harder problem and something we're definitely really thinking a lot about. And I personally find it to be one of the most important problems to solve right now, the next set of things.

Rob: One of the scams I — so I think that's what's interesting is whoever is lagging behind. And so I think this applies to countries regulatorily, carriers — and it applies to like every level of the stack. Whoever is lagging behind, because of what you said earlier about we've got to defend everything, that weak link will get targeted.

So I think there's lots of issues with just data brokers and lots of data being available there to be like a starting point for a lot of these kinds of attacks. The one I saw recently, which was very clever, was fake permits — like using scraping public permit information and then creating fake contractor invoices, fake city requests for payments, otherwise permits are going to be canceled. Just leveraging that information is something that — I think everyone, every subcategory of entities has an identity problem that they have to think about. Local governments, banks, telcos, everyone. And so I don't have a good solution for this. I think a lot of us are going to have to work on this from lots of different perspectives to try to protect people.

Rob: And I think also the other thing that I know you and I have talked a bunch about is like, I think there's this temptation when you have these kinds of shaped problems to then say, well, okay, we now all need to be okay giving up privacy. Like, you know, now we need to throw privacy out the window. And I don't agree. I know you don't agree with that either. But I'm curious how you think about the privacy trade-off. I know we've talked a bunch about encryption in the past, you and I.

Dave: Yeah. Well, I'm glad you brought that up, Rob, because as you know, it's near and dear. And also you as well. I'd love to hear your thoughts because again, we're maybe too rare in this industry of having been on both sides of the fence. And like my team, the security and privacy team — our team is in charge of both of those things. And so I actually feel very fortunate that I have so much of my brain invested in the privacy side and so much in the content safety and just trust and safety and traditional cybersecurity side that I've had to be thinking about that balance for so many years. And I think that makes us better — better protecting people holistically.

One of the things that really worries me in this area of this tension between privacy and general content safety and having more and more signals to try to defend against bad things is you see a lot of polarization. You know, it's kind of like our politics right now. There's just — people take these just such massively polarizing views on things.

You see the privacy community saying things like any form of processing messages — even though, realizing that when you type in your keyboard app that your keyboard is accessing your sensitive data — like any processing of information is bad. It's like a slippery slope and it can be abused. And so you have these privacy advocates that I think take these sort of very unrealistic positions that aren't really that helpful.

And then I think on the other side, you have these content safety and child safety folks and law enforcement that say encryption is bad. It's killing people. We have to turn off encryption. And that's obviously not the right answer either.

And it just makes it so hard to find the right balance. And that's what I am all about — trying to figure out how to find the right balance. And that doesn't mean, in my opinion, making unacceptable trade-offs.

And I think one of the really great examples of this is the stuff that we've been talking about, right? Like, how do you implement content behavioral abuse and these scam protections in a privacy-preserving way? And yeah, there might be some trade-offs in general with the level of accuracy and precision. Maybe they're — you know, I'm not saying it's a perfect answer, but let's focus on the overlap. Let's focus on areas where we can make progress. Can we help make children more safe with privacy-preserving detection on device? And obviously, Google and Apple have both launched solutions that help protect kids online or in their mobile devices with solutions that work today. These sort of nudity detections that give the user more agency and more awareness of what's going on and try to limit the spread of bad things — that does not violate the privacy promise. And I think that is the thing. Those are the kinds of things we should be focusing on.

Dave: There is another really important technology underlying this that I think helps bridge the gap. So sometimes you have the privacy people thinking, oh, this is a slippery slope. And then you have the content safety people saying, you know, because you're not listening to us, we're going to sort of like secretly force you to do something. And there's been some reports about that that are really troubling.

I am a really big believer in this concept of binary transparency, which is going to sound maybe a bit esoteric to the consumer, the average user, average listener, maybe, but those of us in this industry, I think we need to embrace this concept.

And what it basically means — it says, I'm going to implement a system that I claim is privacy preserving, but don't just trust me because I said it was. And don't just trust me to never be maybe compelled by some external entity to changing what it does. Don't have to trust my word. Trust the bits. And we're going to actually take that system and we're going to publish the bits that correspond to it, basically the hashes of it. And we're going to put it into a public ledger. And that public ledger is independently witnessed, so it can't be tampered with. And there's a track record of every production software that's ever been shipped.

And this is a beautiful thing because it means that, well, first of all, no one can secretly compel me to do anything because there's always going to be a track record of it. And that slippery slope argument is mitigated because it means that it's not like I built this thing and then someone can just go change it. You can't, actually. It's a certified public implementation that anyone can verify and inspect, and especially with AI now, it becomes much easier.

So I'm really a big believer in binary transparency. We're seeing it. There's been a recent set of implementations. Android now has a very thorough — I've always been leading this area, but we recently announced a huge expansion where all Google's mobile production software is now in a public ledger. So it's very comprehensive coverage. It's something that other platforms, including the other mobile operating system, doesn't have.

And then there's a bunch of stuff going on in the cloud where, of course, if you're going to start doing more and more AI processing in the cloud, which is something that we would like to enable both for features but also for counterabuse technologies, because they're maybe less visible to the attacker if they're running in the cloud — well, how do you do that in a privacy-preserving way without exposing all these signals to the cloud provider? And so these sort of trusted execution environments are really important. But you need — you essentially need the same idea. You need binary transparency from end to end. You need it on the device and then you need it up in the cloud. And if you have that, if you have a comprehensive binary transparency approach, then you can make guarantees that are not just what the thing is doing now, but what the thing has ever done. And that is a really strong deterrent to the slippery slope. So it's pretty cool stuff.

Rob: I'm a big fan of the 80-page, $50,000 security audit of the app with the thing. But then it's like, oh, well, but they could just change the code. And so it's fine on September 25th, but in three months, who knows? So I think anything where you're not just relying on what someone says is important.

I think the other thing that is kind of related, depending on the context, right? So messages between two people are one thing. But for example, some of those message channels might be used in an advertising context to — again, it's a valid use case. A small business doesn't need to have a website. They could just start an end-to-end encrypted chat, start with an ad or some other way with a consumer. But just saying, oh, well, if the consumer gets into trouble, they'll know how to report it or what — like, you need to also just think through the abuse cases and how it makes sense to protect people while not breaking the privacy promises that the channel has. And to your point, I think there are ways to do that. It just requires people to think through the consequences and how to do it.

Dave: Yeah. And of course, the user can decide to share something, right? That's it. But that's the user decision and not the platform's decision.

Rob: Yeah, exactly. But that said, we have technology now, whether it's an on-device model or something where you can now process stuff. You can keep the thing on the device. You can keep the thing in an enclave or an execution environment. You can essentially have other guarantees that — but I think as humans, we haven't figured out how to even talk about this stuff well. Like, you know, is it a little thing that sits on my phone and is protecting me and is acting in my interests? I've talked to a couple of folks building this kind of stuff. And no one really knows how to talk about this stuff yet. And I think it'll happen. So we're going to have to evolve it.

Dave: I'm working on a paper that is trying to sort of define these levels of maturity or rigor in binary transparency. It is difficult to talk about to the consumer. That is for sure. I mean, I guess we'll start with the technical community should at least have a common way of discussing it and maybe some standards around it because there actually isn't a standard on even — the stuff that, you know, Google has private AI compute in the cloud and you heard Apple's private cloud compute and Meta has something called private processing. They all kind of sound very similar. But as of today, there actually isn't a published standard that explains it. So that's something that we'll be pushing on.

Rob: The other thing that occurs to me, and maybe you have seen some of this, which is that there's just a bunch of signals that consumers generate on phones that I always wonder where they end up going. Like if I report, you know, I got a spam message — or what I saw years ago on ads was like a lot of the user reports you get are actually not that useful. People think, oh, just because I don't like this thing, it's against policy or it's not necessarily a scam. But within those signals, there's a lot of really valuable stuff that can come out of it if it's handled correctly.

So do you think — how do you — I guess coming back to what we were just saying — does the consumer have a role to play in protecting other consumers? Because if I'm a knowledgeable person and I'm seeing stuff, I know things are scams. How do I protect the people around me in my community and so on? And what are the responsibilities of the various people involved? It's carriers, it's platforms, it's banks. How do you think about the consumer responsibility and the businesses and platforms responsibility?

Dave: Yeah, I think there's no doubt that consumers — I mean, even just the messaging example we were talking about earlier — there's no doubt that consumers reporting scams, reporting attacks, your email flagging things as spam and attacks, those things help. They improve the model. So when the user decides to share that information, there's no doubt that it helps everyone. It helps their neighbors and the industry. And it's a beautiful thing. I think that platform providers should build into their systems capabilities that enable users to be more helpful. I think those are good examples. I think that is part of building a good solution is to be thinking about how does the user provide the right feedback and giving them that agency, transparency — all those things are good.

But fundamentally, I do — yes, I do subscribe to the secure by default concept in that I think when you're building systems for billions of users, you need to be thinking of, you got to put the user first and you need to be building systems that — I mean, I'm stating the obvious here — but build systems that work to protect the user, both their privacy and their safety, and not rely too much on the user. The users can help, but you can't depend on them to be your solution. And so, yeah, I mean, there's a role to play, but I would say a minor role compared to the roles of platform providers, regulators that can really push what platform providers are doing in a hopefully more healthy way, those kinds of things.

Rob: So in five years — look, in five years, we're going to have AI that's much, much better than we have today on both the defender and the attacker side. So what do you think some of the things that the different participants in the ecosystem need to do, like setting aside the user who now is going to have to deal with all of these things? Like what is one thing that each of the different folks in the value chain can do to help make things safe by default or secure by default?

Dave: Yeah. Well, it turns out that today the company Google published a blog. It wasn't my blog personally, but it was a corporate blog that explains that in this AI space, there's all these discussions around how AI has to be regulated. I think, you know, Google and OpenAI, all the major frontier AI model companies are all saying, yes, of course, regulation has a place, but it also can't stifle innovation and all that. But how do we actually do it? How do we actually ensure that we have the right guardrails when we know that regulations traditionally move way too slow?

The international standards organizations like ISO and others — they just, I mean, by the way, lots of great people do lots of great work on them. I'm not trying to badmouth the standards organizations. And I work a lot with them myself, and I've contributed to many of them. And I've written a bunch of them. It's just that they move slow, right? And AI is moving too fast.

And I think the blog we had today was like, what you really need here is a much faster-moving sort of NGO where you have the industry experts — because that tends to be where they are — defining what good looks like right now because it's going to change tomorrow, but it's going to move very fast. And government needs to empower and partner with that group on defining what good looks like, both from just a general AI safety perspective, but also a lot of the areas we talked about now, right? Like what level of content safety is a reasonable bar and what are the reasonable mechanisms to do that that balance privacy and safety. Those are all things that need a better, like this more balanced view we talked about, right?

So it's like, there's certain people I might not bring into that room because they'll just be yelling at each other the whole time. But — no, seriously — let's get the real, the true experts building these systems, trying to find the right balance, into the room and the government folks. And let's essentially not write the standard, but let's define at least the guidance on what we collectively think is what good looks like. That's one thing I would say as a general call to arms for big tech and for government.

Dave: I think Apple and Google — I alluded earlier that I think Apple and Google — I'm biased when I think about mobile, obviously, but in this mobile world we live in, so much of the world is consuming digital technology through their phones and similar connected devices, wearables and things. We have an outsized responsibility to work together in ways that we're not doing. And I will be the first to sit down and do more. And I have asked for that. And we got to find a way to do that.

We got to find a way for Apple and Google — like one example might be, we have a list, a publicly documented list of the top problems that we're trying to collaborate on. Is interoperability of fake call detection one of those things? I don't know, but let's create the list. For a while, years ago, it would have been like contact tracing would have been at the top of that list and then it would fall off the list, maybe, or maybe it deserves to still be on the list. But let's come up with that list and let's hold ourselves accountable to it. The things that we think are the biggest impact areas that we have to collaborate on for security, privacy, and interoperability. And let's commit to those things and hold each other — and have the world be able to hold us more accountable because we've been public about it — instead of these weird back-channel rounds and negotiations and weird things that happen. There's a lot of area for collaboration there.

Dave: I mean, carriers — there's a bunch of things that carriers do that — again, I have a biased view in the mobile phone industry. A lot of the mobile network operators, unfortunately, don't hold the same bar when it comes to privacy, especially, that they should, in my opinion. And there's a lot of things going on where there's a lot of tense discussions.

And it's like a simple example would be like, there's a lot of mobile network operators that think it's okay — still in 2026, think it's okay to silently install a bunch of apps on your phone. And that's just not like games and other things. Like a bunch of apps that you didn't ask for are getting installed on your phone and that just should not happen. And we have policies that try to govern that, but they're always trying to find the angle around it. And so stop doing that. Stop doing the privacy-invasive things. I realize why people want to do these things. I mean, there's strong business things, but — and location, precise location access is another one. Like the mobile networks are broken when it comes to precise location. They're still broken. Every mobile device is trackable through the way mobile network protocols work today. Permanent identifiers are bound to your location that the carrier knows all the time. And that is broken and we should fix that.

Regulators, as I mentioned — we need to work more private-public partnership. I think there's good models of doing that. A bad model might be something like the DMA Article 6(7), which recently — the recent findings where the EU, the EC basically said, you know, I think we should just let users put any system-level agent they want, download it off the internet on your phone and give it full permissions and access to all of your personal data without any kind of security model or defense at all. Just let them choose. Like, wait a second — that's not a good idea. I think you need better public-private partnership that's based on technical expertise and not politics.

I think the activists — I think there's a place for them. But really, when it comes to this encryption debate, let's lower the temperature. Let's stop calling everyone but yourself evil. And let's get in a room and come up with the right balances.

Yeah, those are a few of the key stakeholders.

Rob: Some hot topics there. I think we're going to have to have another conversation about this at some point or a series. What do you think about the ads business, by the way? I know your newco is working on that area. I'd love to hear what you think about the ads, you know, just the ad tech.

Dave: Well, at some point, I wrote a blog post like a decade ago about saying how I would explain working for a decade on ads. And then I spent another, I don't know, five, six, seven years working on ads. So I don't know. I've been kind of stuck in ads. It's hard to get away from ads.

Rob: But I think the thing with ads that's interesting is that, you know, you can kind of set a higher bar for what should happen in an ad than just organic content on a platform because, you know, people are paying to put this message in front of other people. So, you know, I think we see this as one very important public data source. I think of it as a public data source because that's essentially what it is. It also is a huge financial incentive for different platforms. They're using the money they're making from this — I mean, Google included, right? My former employer, your current employer — to fund a whole bunch of other stuff.

And I do think that most of the people I encounter who are working on this really want to do the right thing. I think there are various incentive challenges and there's things that are tricky. And because there's so much money here, the adversarial nature of bad stuff happening in ads is — I think people would not really, people don't really understand how tricky some of these challenges are at scale. That said, I also do firmly believe that platforms can be doing more than they're doing today. So I think it's really about finding the balance of those things.

You brought up the DMA — folks, I've had super productive conversations over the last few years with folks in the EU and elsewhere about the laws that they have on the books and how to make them more useful, e.g., the DSA, the Digital Services Act. There's a bunch of transparency requirements there for platforms that are really not helpful. They're not being consumed by anyone. They're not being used even by companies to do anything to hold platforms accountable. So there's a lot of work that can be done in the ad space, but there's a lot of work also to be done elsewhere.

I agree with you that I think — it's maybe I would come down a little more strongly on — I think you need content, AI to figure out what's happening with content as well as the actor side and the identity side. You need to find the right balance of those things. And frankly, as running a startup, we're trying to figure that balance out and figure out who has one set of signals in one area and not the other that we can help connect.

Dave: Well, we didn't talk a lot today about the just ad fraud and some of the bad things happening. And obviously just content safety issues and ads. And we didn't talk about it a lot, but it is what I have found also in my own experience — it's one of the most complex and difficult areas. And I'm glad you're working on it. And I think you're bringing more transparency to these things. Like you said, I mean, I like to say transparency is the tide that raises all boats in many, many things. And this is another example — shine a light on it.

I know internally we've done — we have metrics that show, we've done these tests where we show that Google ads, content safety specifically, like way, way safer on average than other ad platforms that we're able to test. That's not something I personally test, but I've heard of these things. But where's an independent way of measuring and understanding that? And if InfoHawk is — if you're working on it, I mean, I think it's exciting that you're working in that area. So good luck to you, man. Appreciate it.

Rob: Yeah, thanks. I mean, I guess since you mentioned that part, I'll plug this part as well. We set up a nonprofit called Collective Metrics, actually, that is trying to create metrics, kind of a baseline set of metrics. And to your point about trying to be open about it — that's really one way we think that can also be helpful in that journey.

But yeah, there's just — like I said — there's a lot of work to do on all fronts of stopping bad stuff, sharing data, connecting people who aren't connected. The good news is there's a lot of really well-intentioned smart people who have been and are working on these problems. And so it's really just part of why we're having these conversations — to let them know that there are other people who care, and they're all over at the big companies and startups alike.

So I really appreciate you taking the time to talk with us, Dave. It's always great to catch up.

Dave: Thanks, Rob. It's good to catch up with you. Keep fighting the good fight, man. It's a war of good versus evil and we got to keep it up.

Rob: Yeah, 100% agree.

← All Won't Fix episodes