In May, the FTC required Cox Media Group to pay $880,000 to settle charges over a product called “Active Listening.” The pitch was brazen: CMG claimed its AI-powered advertising service captured conversations from users’ smartphones (in real time, without their knowledge) and used that audio to target ads. Advertisers paid premium rates for it. The product didn’t work as described. It didn’t work at all. CMG was reselling purchased email lists at a significant markup and calling the result AI-powered audio targeting. Two smaller firms, MindSift and 1010 Digital Works, paid $25,000 each for selling the same story.
Sit with the irony for a second. The most prominent AI surveillance scandal of the year was a company selling the fear of AI surveillance as a product. The listening never happened. The fine did.
The useful question isn’t how CMG got caught. It’s why the pitch worked for as long as it did, and what that tells us about the software we’re building.
Why the myth was a viable product
Most people who hear “your phone is listening to you” don’t immediately dismiss it. They’ve had the experience of mentioning something out loud and then seeing an ad for it within hours. The mechanism is usually mundane (behavioral targeting is very good at surfacing things you were statistically likely to want anyway) but the suspicion isn’t irrational, because real versions of adjacent capabilities have existed and been used.
Apps request microphone permissions routinely. Terms of service that touch sensors run to thousands of words. Data brokers aggregate behavioral signals from dozens of sources and sell profiles whose origins most users can’t trace. CMG’s specific product was fake, but it was fake in a category that feels real. That’s what made it marketable.
If you’re building software that touches a microphone, a camera, location data, or a contact list, this is the trust environment you’re working in. Users assume some collection is happening. They assume the data goes somewhere. Whether those assumptions are accurate depends entirely on what you built.
The policy doesn’t fix the trust problem
A privacy policy describes intent, not behavior. Users can’t verify what the code is actually doing at runtime, and mostly don’t try. The gap between what a policy says and what the codebase does is a trust problem, not a legal one, and better legal language doesn’t close it.
The more useful intervention happens earlier: at the design stage, before any code is written, ask whether the feature actually requires this data.
A fitness app can calculate step counts without streaming raw accelerometer data to a cloud backend. A notes app can search your notes without indexing them on a remote server. A Bluetooth health monitor can display readings from a paired device without routing that data through a vendor API. These features work the same way from the user’s perspective. The data exposure is completely different.
This is the thinking behind our local-first software work. When computation happens on the device and data syncs only at the user’s explicit direction, the trust model changes structurally. There’s no server-side breach surface, no upstream vendor to get compromised, and no ambiguity about what’s being uploaded where. The data doesn’t leave because you designed it not to. That’s a different kind of guarantee than a policy provides: it’s an architectural fact.
What changes when you build the thing yourself
Third-party SaaS products often collect data because collection is load-bearing for the business model: usage telemetry, behavioral data for model training, engagement metrics. You may have limited visibility into what a vendor SDK is doing in the background. You agreed to their terms. That was the deal.
When you build custom software, you make these calls explicitly. The microphone permission exists in the codebase or it doesn’t. Data leaves the device or it doesn’t. Logging is there or it isn’t. You can answer “what does this app collect?” with an actual answer, traceable in code, rather than pointing to a third-party privacy page and hoping.
That specificity has practical value beyond compliance. For products handling health records, financial data, communications, or anything where users are placing real trust in your discretion, the cost of a data incident, even involving data you collected but didn’t need, is severe. CMG’s fictional surveillance attracted a $930,000 fine and national press. Real unauthorized collection, or a breach of data you were holding without a clear reason, costs more. Remediation is expensive. Lost trust doesn’t repair itself.
Three questions before the first line of code
We run through these on every project that involves user data.
Does this feature actually require this data, or can we design it so it doesn’t? Data you don’t collect can’t be breached, subpoenaed, leaked, or misused. This is the most effective privacy control available, and it’s a design decision, not a compliance task.
Where does the data live, and who controls that infrastructure? On the user’s device is better than on your servers. Your own infrastructure, under your management, is better than a SaaS platform where you’re relying on their security posture. Understand the whole chain before you commit to it.
What happens at end of life: account deletion, subscription expiry, device handoff? The answer should be a working mechanism: the data is gone. Not “we’ll design a deletion flow eventually.”
Most apps accumulate more data than they need because collection was the default and restriction required deliberate effort. CMG made that dynamic explicit in the most cynical way possible. They sold data collection as a premium capability even when they weren’t doing it. The quieter version of that problem is more common: data sitting in a backend nobody remembers authorizing, collected for a feature deprecated two years ago, still there because nobody built the deletion path.
If you’re thinking through what your app should and shouldn’t collect before you build it, get in touch. It’s one of the first conversations we have on any new project.