DEV Community

Super Funicular
Super Funicular

Posted on

Is My Baby Monitor App Watching Me Too? Six Signals That Tell You a Free Camera App Is Selling Your Data

#android #security #mobile #privacy

Is My Baby Monitor App Watching Me Too? Five Signals That Tell You a Free Camera App Is Selling Your Data

Originally answered on Quora — "Is my baby monitor app watching me too? Signals that tell you a free camera app is selling your data" (Super Funicular, 2026-05-20). This is the canonical archive of that answer, expanded with the May 11 Meari breach numbers as they stand a week later and a fresh sixth signal that turned out to be the most diagnostic of the bunch.

The short answer is: most free baby-monitor apps don't watch you directly, but a lot of them watch your device — what other apps are installed, what Wi-Fi network you're on, your rough location, your phone model, and (in the cloud-backed ones) every frame your camera ever captures, sitting on a server you don't control. That data has a market value, and the structural reason it exists is that someone has to pay the cloud bill. If you didn't, someone else did.

Six signals will tell you, in under twenty minutes, whether the free app on your nightstand is in the we-pay-the-bill-with-your-data category or the we-don't-have-a-bill-because-we-don't-touch-your-data category. They go from low-effort (you can check them right now with the screen in your hand) to high-effort (you'll need an hour and a packet sniffer). You don't have to do all six. Doing the first two will get you 80% of the answer.

I'll walk through them, then talk about what to do if the answers come back ugly, and finally name a few specific apps I trust to do this right — including the one I wrote, which exists specifically because the answers came back ugly for me four years ago.

Signal #1 — The status-bar camera and microphone indicator (10 seconds)

Starting in Android 12 (and back-ported to a lot of Android 11 OEM builds), a small green or orange dot appears in the top-right corner of the screen whenever any app is actively using your camera or microphone. Green dot = camera. Orange dot = microphone. This is enforced at the OS level — apps can't suppress it, hide it, or fake it. It is the most honest signal Android gives you.

Swipe down on the quick-settings panel and tap the dot. Android will tell you exactly which app currently holds the camera or microphone session. Do this right now, with your baby-monitor app running:

  • Expected: your baby-monitor app is the only thing in the list, holding the camera. (Some apps will also show mic if you have two-way audio enabled.)
  • Unexpected: a second app — a "system update service," a "social companion," a launcher add-on — is holding the camera or mic in parallel. That is the signal you came for. The baby-monitor app is fine; whatever else is in the list is the problem.

If the baby-monitor app itself is the only thing in the list but it's holding the microphone when you didn't turn on two-way audio, that's also a flag. Some cloud-backed monitors record ambient room audio for "AI noise classification" features (cry detection, etc.) by default. The feature isn't malicious, but the data path is: that audio is being uploaded somewhere it doesn't strictly need to go.

Signal #2 — The permission list (2 minutes)

Settings → Apps → [your baby-monitor app] → Permissions.

A monitor app needs three permissions to do its job: Camera, Microphone (if two-way audio), and "Display over other apps" or a foreground-service permission so it can keep recording when the screen turns off. That's it. Background Camera RemoteStream — the app I make — also requests Network so the embedded web server can serve frames to a browser on your home Wi-Fi, but no Location, no Contacts, no SMS, no Phone, no Calendar, no Storage-Manage-All, no Accessibility, no "device admin."

If the app you're looking at also has:

  • Location (especially "always" rather than "while using") — what does a baby monitor need your GPS for? In the legitimate case, it's for "auto-connect when you're home." In the data-economy case, it's because location is the most valuable single field a data buyer pays for.
  • Contacts — there is no honest reason a camera app needs your contact list.
  • Accessibility — this is the big one. Accessibility permission lets an app read everything on every screen of your phone, intercept clicks, and operate other apps. It's the single most powerful permission in Android. A monitor app that asks for Accessibility is asking for the whole device.
  • Phone / SMS — these tend to come in stalkerware-adjacent products. Run.

Permissions are an architectural confession. The app is telling you exactly what data it touches; you just have to read the list.

Signal #3 — The Privacy Dashboard 24-hour timeline (5 minutes)

Settings → Privacy → Privacy Dashboard (in Android 12+; the menu wording varies by OEM — Samsung calls it "Permission usage").

This view shows you which apps accessed your camera, mic, and location in the last 24 hours. It's the receipt for Signal #1 — instead of catching the app red-handed in real time, you can see a log.

  • Expected: your monitor app's camera (and mic, if applicable) usage tracks closely to when the camera was actually running.
  • Unexpected: the monitor app's camera turned on for 3 seconds at 4:17 a.m. when nobody was using it. Or the location was accessed every 15 minutes when the app was in the background. These are the patterns that data-monetized apps create — short, frequent, just-enough-to-keep-the-stream-alive pings.

Pay particular attention to a one-time location grab at app startup. That's the data-broker tell: location accessed exactly once per cold-start session, then never again. Just enough to anonymize-and-sell. (The legitimate cases — geofence the camera so it only records when you're not home, e.g. — would either ask "always" or ask repeatedly. A single grab is the data-broker shape.)

Signal #4 — Where is the video actually going? (10 minutes; this is the one most people skip)

Cloud-backed monitors work by having the camera-phone upload every frame to the company's servers, where the viewing-phone then connects to pull the stream. There is no peer-to-peer; there is no LAN-only path. Every frame your home produces is technically visible to whoever has access to the company's server, and to anyone who breaches it.

This came home for everyone on May 11, 2026. A researcher published — in a single talk that's now been viewed about a million times — the technical writeup for how one extracted private key gave him access to roughly 1.1 million baby-monitor and security cameras across 378 brands and 118 countries. The shared key was hard-coded into the firmware. He could pull live video from any of those cameras at any time. The vendor (Meari) had no idea, the brands rebranding Meari's firmware had no idea, and the parents had no idea. The architecture made it possible; the breach revealed it. (Full architectural autopsy: 1.1 Million Baby Monitors Were Watchable by Anyone — Here's the Architectural Mistake Behind It.)

You don't need a packet sniffer to figure out whether your app is in this category. You can check, in this order:

  1. Open the app's website and look for the words "end-to-end encrypted" near the words "self-hosted" or "local-only" or "no cloud." If those words don't appear together, the app is cloud-backed. (E2E without local-only just means the company can't read the stream, but it's still on their server; a breach of the broker still exposes that you, specifically, are pinging from this address at this hour.)
  2. Check the permissions list (Signal #2) for the Internet permission. A truly local-only app uses only LAN-discovery and serving — it doesn't need to hit the public internet at all. If the app's network usage is high while you're not actively watching the feed from outside the home, frames are going somewhere.
  3. Use Android's built-in data-usage view. Settings → Network & internet → Data usage → [your app]. A local-only camera should be at <50 MB/day even running 24/7, because nothing leaves your Wi-Fi. A cloud-backed one will be at 1–8 GB/day, because every frame is uploaded.

The data-usage check is the single most diagnostic two-minute pull you can do. It tells you, in megabytes, whether your video is staying home or going on a trip.

Signal #5 — Read the privacy policy three sentences in (10 minutes)

Privacy policies are long, but they all do the same thing: they put the honest data sentence in the first three sentences of the "Information We Collect" section, then bury everything else behind legal disclaimers and "may include" qualifiers.

Skip to the "Information We Collect" section (it's almost always the second section after "Introduction"). Read the first three sentences. Look for:

  • "We may share aggregate data with our partners." Aggregate data sharing is the data-broker sentence. The "may" is doing a lot of work in that sentence — in practice it means "we do, regularly, with a list of partners we don't disclose by name."
  • "We collect device identifiers for service improvement." Device identifiers — Android Advertising ID, ANDROID_ID, firmware IDs — are the cross-app tracking surface. The "for service improvement" clause is a near-universal generic justification that has never been litigated to a substantive limit. Read it as "for whatever we want."
  • "We may transfer information to third-country processors." This is the GDPR-required disclosure that your data goes outside the EU. In US-only privacy policies this often appears as "we may share with affiliated entities." Same thing.

What you want to see, instead, is something like: "This app does not collect, transmit, or store user data on any external server. All recordings are saved on the device only and are accessible only via the local network." You should be able to read the entire data section in under a minute. If the policy is 4,000 words long, that's a confession in word-count.

(The Texas attorney general filed a lawsuit on May 11, 2026 against Netflix that hinges on exactly this kind of language — alleging that Netflix's 2020 public statement of "we don't collect anything" was misleading given what their actual policy and behavior said. The policy is the legal text; the public statement is the marketing. Read the policy. The architectural-vs-policy framing of that case is the same one that lit up Texas's May 20 investigation into Meta's AI Glasses — same AG, same legal theory, broader product category.)

Signal #6 — Run the app for one day, then look at how often it talks to its servers when you're not using it

This is the signal I added after running the same audit on a dozen apps in the week after the Meari breach and discovering it was the cleanest discriminator of all.

Settings → Network & internet → Data usage → [your app] → break the view down by foreground vs. background (Android 12+ shows both).

The signal you're looking for: what's the ratio of background data to foreground data?

A camera app that does its work when you tell it to should have a background:foreground ratio close to zero. You're recording when you press record. You're viewing when you open the viewer. The app is idle the rest of the time, and idle apps don't send bytes.

A camera app that monetizes you in the background shows the opposite pattern: maybe 90% of the day's bytes are background — keep-alives to the vendor cloud, telemetry pings to the analytics SDK, "heartbeat" frames so the company's dashboard knows your camera is still alive, periodic location updates, ad-network reachability checks. The actual recording session is a small fraction of total bytes.

Three apps I audited in May 2026 (without naming names) had background-to-foreground ratios of 17×, 41×, and 89×. Meaning: the 41× app spent 41 megabytes phoning home for every 1 megabyte the user actually asked it to use. That's the structural shape of a data-economy app.

The ratio for Background Camera RemoteStream over the same 24-hour audit window was 0.02× — almost all of the (already tiny) bytes were the LAN frames you asked for when you opened the viewer. The other apps tested in the local-only category — IP Webcam and Haven — sat in the same range. That's not a marketing claim; it's a measurement you can rerun on your own phone in 24 hours.

If you only do one of the six signals, do Signal #4 or Signal #6. Both tell you in megabytes what the architecture is.

What if the signals come back ugly?

Three options, depending on how strongly you feel about it.

Option 1: Stick with the app you have, but lock it down. Revoke every permission the app doesn't strictly need (especially Location, Contacts, Accessibility, Phone). Reset the Advertising ID (Settings → Privacy → Ads → Reset advertising ID; this severs the cross-app tracking chain, briefly). Turn off "Personalized ads" in the Google account settings. This won't fix the cloud-upload problem, but it'll cut the cross-app tracking surface roughly in half.

Option 2: Switch to a paid cloud-backed app from a vendor that monetizes through subscriptions. AlfredCamera Premium ($5.99/month) and Nest/Ring (Amazon's products) are honest about what they do; they take your money to pay the cloud bill, which means they don't need to take your data. The structural incentive aligns. The price you pay is, well, the price. (AlfredCamera's free tier got squeezed in 2026 — from unlimited cameras to a 2-camera cap and 24-hour retention — because the cloud bill kept growing. That's the honorable response to the cost of cloud: charge users. The dishonorable response is to monetize data. See the cost-side breakdown in The Cloud-Bill Theory of Free Camera Apps.)

Option 3: Switch to a local-only app where there is no cloud and no data trail to monetize. The architectural property of local-only apps is that the developer has no recurring per-user cost: no cloud servers, no bandwidth, no storage. If the developer has no recurring cost, they have no structural pressure to monetize your data. The tier can stay free forever because there's no bill to pay.

This is the category I work in. The app I make, Background Camera RemoteStream, is in this category: free, no account, no cloud, no Location, no Contacts, no Accessibility. Every frame your camera-phone captures stays on the camera-phone's flash storage. You watch the live feed in any browser tab on any other device on the same Wi-Fi via a built-in embedded web server (no app required on the viewer side — any laptop or phone with a browser works). Optional YouTube Live streaming for off-LAN viewing is a one-time Pro purchase that uses your YouTube channel — Super Funicular LLC isn't in the middle of the stream.

The honest trade-offs: no motion alerts (we don't run an ML pipeline because that's where most data leaks happen) and no two-way audio. If those are non-negotiable, AlfredCamera Premium is a fine subscription pick; if you can live without them, local-only is the architecture that stays free forever.

A few other local-only / privacy-first apps worth knowing about, in case you want to compare:

  • IP Webcam (Pavel Khlebovich, 2011) — the long-running gold standard for technically-comfortable users. Free. Slightly less polished UI; same architectural soundness.
  • Haven (Guardian Project) — open-source tripwire-style motion detection. Not a continuous-monitoring app; different use case (it's a "did anyone enter this room?" app, not a "let me see the room right now" app).
  • tinyCam Monitor (Free Android version) — pairs well with Background Camera RemoteStream on a two-phone setup. RemoteStream handles serving the LAN stream from the camera-phone; tinyCam runs on the viewing-phone and adds motion alerts on top.

If you want the full apples-to-apples breakdown with the architectural trade-offs side by side, I've written those up here:

The structural answer behind all six signals

Free camera apps live or die by their cloud bills. A cloud-backed app at scale costs the developer real money every month — every frame uploaded is bandwidth, every retention day is storage. That bill has to be paid by someone. The three options for who pays are:

  1. The user — paid subscriptions (AlfredCamera Premium, Nest, Ring). Honest. Sustainable. Expensive for the user.
  2. An advertiser — ad-supported free tiers. Honest-ish (it's clearly disclosed), but the way the ad networks work means your data leaks to the ad broker even if the camera app itself is well-intentioned.
  3. A data buyer — data-monetized free tiers. Often not clearly disclosed; phrased as "service improvement" or "aggregate analytics with partners." Your video probably isn't being sold directly, but the metadata almost certainly is — location, network identity, device fingerprint, usage pattern, install graph.

The fourth option is what local-only apps do: don't have a cloud bill to pay. The architecture creates the property; the property creates the freedom from data monetization. The six signals above are different ways of detecting which of these four columns the app you're using lives in.

If you do nothing else, do Signal #4 and Signal #6 — the data-usage view broken down by background-vs-foreground. They tell you, in megabytes, which way the video is moving and who's initiating the conversation. If the answer is "a lot of megabytes, mostly background, even when I'm not watching," you've got your answer.

Cross-links for further reading

I'm the developer of Background Camera RemoteStream. I built it because I went through this exact diagnostic on a baby-monitor app in 2022 and didn't like the answers, and I'd rather ship the alternative I wanted to exist than keep complaining about the ones that didn't. If you want to see what a transparent local-only camera app looks like in production, it's on Google Play for free and the website is here. The next companion piece in this series — "Is it possible to use a free Android camera app without giving up my privacy?" — answers the cost-vs-privacy fork directly; that one runs on Quora today and lands here as the canonical archive on June 3.

Top comments (0)