DEV Community: Super Funicular

Ring Was Just Sued for Scanning Strangers' Faces Without Consent — Here's Why a Local-Only Phone Camera Can't Be Named in That Suit

Super Funicular — Thu, 11 Jun 2026 08:05:33 +0000

Amazon's Ring was sued in Seattle on Monday, June 2 over its "Familiar Faces" feature, in a proposed class action that claims Ring scans and stores the faces of people who walk past its doorbell cameras without their consent (Reuters). The plaintiff, Virginia resident Charles Sigwalt, puts the problem in one sentence: "Millions of other Americans passed by a Ring security camera and unknowingly had their facial recognition information collected."

If you build camera software, that sentence is worth sitting with — because it describes a liability that has nothing to do with bad intentions and everything to do with where the data lives.

What Familiar Faces actually does

Ring announced Familiar Faces last September and shipped it in December, over objections from the EFF and Senator Ed Markey. The feature is genuinely convenient: it uses AI facial recognition to learn the people who regularly come to your door, so instead of "A person is at the door," you get "Dad is at the door."

The Ring owner opts in. The mail carrier, the neighbor, the kid selling raffle tickets, and the stranger cutting across your lawn do not. They never installed the app, never saw a consent screen, and in most states never had a way to say no. Their faceprint gets computed anyway. That asymmetry — consent from the buyer, none from the people actually being scanned — is the entire legal theory of the lawsuit.

Amazon's defense, offered when the feature launched, is that face data is encrypted, never shared, and that unidentified faces are auto-deleted after 30 days. That may all be true. It also doesn't touch the claim. The complaint isn't "Ring leaked the faces." It's "Ring collected and processed them in the first place, from people who never agreed." Encryption protects data in transit and at rest. It does nothing about whether the data should exist on a server at all.

This is a pattern, not an incident

The Familiar Faces suit lands on top of a long Ring privacy record. In 2023, Amazon settled with the FTC for $5.8 million after the agency found that essentially every employee and contractor could access any customer's private video, whether they needed to or not. Ring spent years granting police a way to request footage from users, in some cases without a warrant. Earlier this year, the company's Super Bowl ad for "Search Party" — an AI feature that scans Ring footage across the network to find lost pets — drew enough backlash that founder Jamie Siminoff spent weeks doing damage control, and Ring canceled a planned partnership with Flock Safety, the surveillance-camera network that has reportedly handed footage to ICE and other federal agencies.

None of these are the same story. But they rhyme, and the rhyme is structural: a camera that sends everything to a vendor's cloud, and a vendor that keeps finding new things to do with the footage once it's there. The footage is the asset. New features are new ways to monetize or analyze the asset. The privacy incidents aren't bugs in that model — they're the model working as designed. (We made the same architectural argument when cities started bagging their own street cameras: the bag is a patch, the architecture is the bug.)

Why a local-only camera can't be the defendant in this kind of suit

Here's the part worth saying plainly, because it's the whole reason this matters for how you choose camera software.

To recognize a familiar face, a system has to (1) capture the face, (2) compute a biometric template from it, and (3) store that template somewhere it can compare against later. A cloud camera does all three on a server it owns. That server is exactly where a "you collected my faceprint without consent" claim attaches.

A camera that does none of those things has nothing to attach to. That's the design behind Background Camera RemoteStream. It turns an old Android phone into a recording camera, and it is built on a few deliberate refusals: storage is local-only — footage stays on the device, not on our servers, because we don't run servers for your footage. There's no account and no sign-up, so there's no identity to tie footage to. There's no cloud upload, no tracking, and no facial recognition at all — the app doesn't compute faceprints, doesn't have a "Familiar Faces" mode, and couldn't build a neighborhood scan even if someone asked, because the data never leaves the phone in your hand.

You cannot be named in a class action over biometric data you structurally never hold. The strongest privacy guarantee isn't a policy promising to protect the faces — it's an architecture that never collects them. (We've written before about the tells that a camera app is quietly uploading more than it admits, and why a hidden upload is the one thing a camera business can't easily give up.)

The honest caveats

A local-only phone camera is not a doorbell, and it is not for everyone. You don't get cross-device AI search, you don't get "Dad is at the door" notifications, and you are responsible for your own footage instead of outsourcing that to Amazon. For some people the convenience of cloud features is worth the trade. The point of the lawsuit, and of this post, is that it is a trade — and that the people being scanned on the sidewalk never got to weigh in on it.

If your reaction to the Familiar Faces suit is "I want a camera that simply never sends anyone's face anywhere," that camera exists, and it's probably already in a drawer in your house as an old phone.

Background Camera RemoteStream — local-only storage, no account, no cloud, no tracking, no facial recognition: play.google.com/store/apps/details?id=com.superfunicular.digicam · superfunicular.com

Sources: TechCrunch, June 2, 2026; Reuters, June 2, 2026; EFF.

What Are the Signs Your Camera App Is Uploading More Data Than It Admits? Five Tells, Four of Them Free to Check

Super Funicular — Thu, 11 Jun 2026 07:11:01 +0000

Originally answered on Quora, June 4 2026. Expanded here with all five tells in detail, the 2026 pricing-and-breach context that keeps making people ask, and the structural reason a hidden upload is the one thing a camera app can't actually hide.

TL;DR

A camera app can write anything it wants in its store listing. What it can't do is move your video off your phone without that movement showing up somewhere — because the upload has to physically happen, and Android keeps the receipts. There are five tells that an app is sending more data than it admits, and four of them you can check without installing a single thing: the background-data number, the Privacy Dashboard timeline, the Play Store Data Safety panel, and (with one toggle) the system DNS log. The fifth — a packet capture — is only needed if the first four disagree, which they rarely do. The apps that fail this test fail it for a structural reason, not a sloppy-marketing reason: running a camera 24/7 costs bandwidth, somebody pays that bill, and if it isn't you in cash, it's you in data.

If you've ever looked at a "free" camera app that promises "no tracking, private, local-only" and thought how would I even know if that's true — this is the article that answers it with observable signals instead of trust.

Here's the thing the marketing copy doesn't want you to internalize: a hidden upload is a self-incriminating act. To send your frames to a server, the app has to open a network connection, resolve a domain, push bytes across your router's WAN port, and do it on a schedule. Every one of those steps leaves a trace that a stock Android phone will show you if you know which screen to open. You are not at the mercy of the description. You're holding the audit tools already.

Below are the five tells, sorted from "obvious in twenty seconds" to "definitive but takes an evening." Most people get a clear verdict from the first two.

Tell 1 — The background-data number isn't near-zero

Where: Settings → Apps → [the app] → App data usage (sometimes "Mobile data & Wi-Fi" or just "Data usage"). Read the Background number specifically.

A camera app that records to your phone and streams over your own Wi-Fi should use roughly zero background data. The traffic never leaves your house — it doesn't touch your cellular bill and it doesn't cross your router's WAN port. So when an idle phone on a nightstand is burning tens or hundreds of megabytes of background data per day, that data is going somewhere outside your home.

For reference: I've watched apps in the wild log 200 MB of background data per day sitting idle. That is not "checking for updates." Update checks weigh kilobytes. 200 MB a day is continuous low-bitrate upload, and the only thing a camera app has worth uploading is frames.

If this number is near-zero, you can often stop right here. If it isn't, the next four tells tell you where it's going and whether the developer admitted it.

Tell 2 — The Privacy Dashboard timeline doesn't match how you actually use the app

Where: Settings → Privacy → Privacy Dashboard (Android 12+; on Samsung it's "Permission usage").

This is a 24-hour, timestamped log of every camera, microphone, and location access on the phone. You're hunting for three shapes:

The app touching the camera for a few seconds at 4:17 a.m. when nobody picked up the phone.
The app reading location on a regular interval while it sits in the background.
A second app — a "system update helper," a "social companion," a launcher add-on — holding the camera in parallel with your camera app.

A legitimate app's access timeline tracks your use: it lights up when you open it and goes dark when you don't. A data-monetized app's timeline has a different signature — short, regular, just-enough accesses that exist to keep a session warm or to sample for "AI detection," not because you asked for anything. The shape is the tell. When access happens on the server's schedule instead of yours, you're looking at the server's app.

Tell 3 — The DNS log shows ad-tech or unknown-cloud domains

Where: Settings → Network & internet → Private DNS. Set it to dns.adguard.com for a day, then read AdGuard's per-app domain list. (Android 9+.)

This is the tell that turns "I think it's phoning home" into "here is the domain it phoned." For a genuinely local-only app, the per-app list should be almost empty — at most an occasional update-check endpoint.

What you do not want to see is a list like *.appsflyer.com, *.adjust.com, *.branch.io, *.kochava.com, *.singular.net, *.facebook.com (in an app with no social feature), *.googleadservices.com (in an app advertising "no ads"), or vendor backends like *.aliyun.com, *.alibaba.com, *.tencent.com, and *.qq.com. The first cluster is advertising and attribution infrastructure. That last cluster is the family of cloud backend behind the Meari breach in May 2026 — 1.1 million baby monitors across 378 vendor brands, exposed through a single hard-coded key. When an app touches any of these while its listing promises "no ads, no tracking," that's not a misunderstanding. That's the architecture saying what the copy left out.

Tell 4 — The Data Safety panel contradicts the description

Where: the app's Play Store listing → scroll to Data safety.

This one takes two minutes and costs you nothing, and it's the most under-used tell of all. Google requires every developer to self-declare what data the app collects and shares. That makes the Data Safety panel the publisher's own sworn statement — and when it contradicts the flowery description above it, the sworn statement is the one that carries legal weight.

If "Data shared with third parties" is populated, or "Location," "Photos and videos," or "App activity" appears under collection, while the description three paragraphs up says "we don't collect anything" — believe the declaration, not the description. Developers update these panels precisely when their collection changes, which is also why re-reading it on an app you've had for a year is worth the two minutes. 2026 has been a year of quiet downgrades: AlfredCamera squeezed its free tier to two cameras and watermarked 24-hour clips, Arlo Secure went from $4.99 to $7.99 a month, Wyze's Cam Plus pricing crept upward, and Eufy's per-camera cloud fees kept stacking. When a free app's economics get worse, the collection side tends to get heavier to compensate — and the Data Safety panel is where that shows up first.

Tell 5 — A packet capture shows steady multi-MB uploads to one endpoint

Where: route the phone through a laptop hotspot and run Wireshark (or use a local-VPN capture app like PCAPdroid, no root needed).

You only need this rung if Tells 1–4 somehow disagree, which is rare. What you're watching for is the unmistakable shape of video leaving: steady, multi-megabyte TLS sessions to the same endpoint every few minutes, continuing while the phone sits untouched. Bursts when you open the app are normal. A continuous outbound stream to one server while nobody is watching is frames going to the cloud. This is the definitive test, and it's the one almost nobody has to climb to, because the free tells settle it first.

Why a hidden upload is the one thing a camera app can't actually hide

Step back from the screens for a second, because the reason all five tells work comes down to one structural fact.

Running a camera continuously costs real bandwidth and real server capacity. Somebody pays that bill. If you're not paying it in a subscription, then the business is paying it — and a business doesn't pay to move your video for free out of generosity. It pays because the video, or the data around it, is the product. That means the upload is not optional to the business model. And a thing that isn't optional can't be quietly removed to pass an audit; it has to keep happening, which means it keeps leaving a trace.

That's why "trust the listing" is exactly backwards. The listing is the cheapest thing to change. The data flow is the expensive thing that can't change without breaking the business. So you check the data flow.

It also points at the only real way to skip the audit entirely: run a camera app that has no server to upload to in the first place. If the app keeps recordings on the device and serves live video from an embedded web server on your own LAN, there is no cloud bill, no data product, and nothing on the other end of a connection — so all five tells come back clean by construction, not by promise.

That's the app I build. Background Camera RemoteStream records with the screen off, stores everything locally on the phone, and streams live to a browser through a small built-in web server on your own Wi-Fi. No account, no cloud, no subscription that can shrink next year. You can run every tell above against it and watch Tell 1 read zero — because there's nothing on the other end to upload to. It's free on Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam&utm_source=devto&utm_medium=post&utm_campaign=2026w24

The short version

You don't need to be a network engineer to know whether a camera app is honest. Open the background-data number (Tell 1) and the Privacy Dashboard (Tell 2) — two minutes, no installs — and you've settled it for most apps. Cross-check Data Safety (Tell 3 of the no-install set, formally Tell 4) and skim a day of DNS logs if you want certainty. The packet capture is there if you need it and almost always you won't. The apps that fail do so because the upload has to physically happen and Android won't help them hide it. The apps that pass, pass because there's no server in the picture at all.

Cross-links for further reading

The full step-by-step procedure, framed as "how do I check": How Do I Check if My Android Baby Monitor App Is Sending Data Somewhere Else? A 5-Step Diagnostic Ladder
The six external signals that a free camera app monetizes you: Is My Baby Monitor App Watching Me Too? Six Signals That Tell You a Free Camera App Is Selling Your Data
Why the 2026 subscription squeeze is pushing free apps toward heavier data collection: Did My Wyze, Arlo, or Eufy Plan Just Get Worse in 2026?

More about the app and the local-only approach: https://superfunicular.com

Background Camera RemoteStream is built by Super Funicular LLC — a privacy-first Android camera app developed in the open with AI-assisted tooling. Free on Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam&utm_source=devto&utm_medium=post&utm_campaign=2026w24

I spent 19 days marketing a free Android camera app with a $0 ad budget — here's the exact organic cadence that 2.5x'd my reads

Super Funicular — Wed, 10 Jun 2026 09:08:02 +0000

I spent 19 days marketing a free Android camera app with a $0 ad budget — here's the exact organic cadence that 2.5x'd my reads

I build Background Camera RemoteStream — a free, local-only Android app that turns an old phone into a screen-off security camera with no signup and no cloud. The product is the easy part. The hard part, for a solo dev, is getting anyone to read about it without paying for ads.

So I ran an experiment in public: pure organic distribution, zero ad spend, one writer (me), and a strict content cadence. Over 19 days the catalog went from 253 article reads to 644 — about +154% — and in the final week followers stepped up on three platforms at once (Bluesky 3→9, dev.to 5→10, LinkedIn 5→11).

This is the honest write-up: what worked, what got falsified, and the one mistake that nearly cost me an account. No "10x growth hacks" — just the cadence and the data.

The cadence that actually moved the numbers

The core loop is boring on purpose. Boring is repeatable.

Answer a real question first. Every topic starts as an answer to a specific question people actually ask ("can I use an old phone as a security camera without a subscription?"). If I can't write a genuinely useful answer, there's no article.
Let it breathe, then write the canonical. Seven days after the short-form answer, I publish the long-form canonical article on dev.to — the version with the full argument, the cost tables, the architecture diagram in prose. The 7-day gap (I call it T+7d) means the canonical lands on a topic that already has a warm audience instead of a cold start.
Cross-post, don't copy-paste. Each platform gets a natively rewritten version — never the same text. The X thread leads with the surprising claim; the Bluesky posts lead with the threat-model; LinkedIn leads with the one concrete metric.

The single biggest lever was step 2. When I tested publishing the canonical first (before warming the topic), it died — 0 reads at day one. When I warmed the topic first, the same archetype carried. That's the whole game: sequencing beats volume.

What got falsified (the part most write-ups skip)

I pre-registered a hypothesis: that leading with LinkedIn (a "LinkedIn-first" sequence) would give long-form pieces a better runway. I wrote down the success criterion before I ran it.

It failed. The LinkedIn-first canonical read 0 views at day one against the criterion, and the supporting data all pointed the same way (8 impressions on the native LinkedIn post vs. 34 on the previous cross-post). So I retired the idea instead of moving the goalposts.

If you're doing build-in-public, write the kill-criterion down first. It's the only thing that stops you from narrating noise as a win.

The mistake that nearly cost me an account

I was putting a Play Store link in nearly 100% of my answers on a Q&A platform. It worked right up until it didn't: a moderator flagged one answer as spam and deleted it. First strike. A second strike likely takes the whole account — and that account had 60+ answers of accumulated equity.

The fix wasn't "stop linking." It was link discipline: include the link only where the question genuinely asks for an app, keep it to one outbound link, and lead with value the reader gets even if they never click. Distribution that gets you banned isn't distribution.

The counter-intuitive winner: impressions came from format, not follower count

The single highest-reach post of the whole run wasn't a carefully written article — it was a short, native-format post that happened to ride a distribution mechanism the platform favored. It out-reached my best native post by 13x with the same tiny follower count.

The lesson I took: on most platforms, format and mechanism dominate follower count at small scale. You don't need an audience first. You need the post shaped the way the platform wants to distribute it.

What I'd tell another solo dev

Sequence beats volume. Warm the topic, then publish the canonical. T+7d beat everything.
Pre-register your kill-criteria. Falsify your own ideas on schedule or you'll fool yourself.
Link discipline is survival. One platform strike is a warning; two is a funeral. Lead with value.
Honest numbers travel. The post that got my first-ever comment was the one where I just showed the real trajectory — 253 to 644 — with no spin.

If you want to see the product the whole experiment was about, it's here: Background Camera RemoteStream on Google Play. And if you're weighing whether your own camera app's "free" tier is quietly shrinking, that's the companion read: Did My Wyze, Arlo, or Eufy Plan Just Get Worse in 2026?

Building in public as Super Funicular LLC. Everything above is real data from a single solo run — including the parts that didn't work.

Did My Wyze, Arlo, or Eufy Plan Just Get Worse in 2026? Here's What Changed — and What to Do If You're Done Paying

Super Funicular — Wed, 10 Jun 2026 07:07:16 +0000

If you've opened your security camera app this year and felt like the free version does less and the paid version costs more, you're not imagining it — and it isn't one company being greedy. It's the same economic squeeze hitting every subscription camera vendor at once. Here's the honest, vendor-by-vendor scan of what actually changed in 2026, why it's happening to all of them simultaneously, and the one option most people don't realize they already own.

What actually changed, vendor by vendor

The headlines are easy to dismiss as routine price creep. Lined up together, they tell a clearer story: across the major vendors, 2026 has been the year the free tier shrank and the paid tier climbed — at the same time.

Wyze — long the budget darling — raised Cam Plus Annual in March 2026 from $19.99 to $29.99 per camera per year, and now steers multi-camera households toward Cam Unlimited at about $9.99/month (roughly $99/year). The useful stuff — longer cloud event history, the better person/package AI events — increasingly lives behind that line, and the no-subscription experience keeps losing features it used to include.
Arlo — the basic Arlo Secure single-camera plan moved from $4.99 to $7.99/month (about $96/year), as widely reported. Single-camera plans have been quietly de-emphasized in favor of the pricier multi-camera tiers, and core conveniences are gated behind the subscription.
AlfredCamera — tightened its free tier into something closer to a trial: a small cap on the number of cameras, shorter clip retention, time-limited live sessions, and watermarked exports. The paid plan's annual price also rose (the widely reported jump to around $35.99/year). The free tier is now essentially a guided tour of the paywall.
Eufy — marketed for years as the "buy the hardware, no monthly fee" option — has steadily layered cloud storage and AI-feature charges on top. Facial recognition, extended event history, and richer notifications increasingly sit behind an optional cloud plan, eroding the no-subscription pitch that made the brand popular.

Four different companies, four different product philosophies, one identical direction of travel. That's not a coincidence, and it's not a coordinated cartel either. It's arithmetic.

Why it's happening to all of them at once

Here's the mechanism, because once you see it the pattern stops feeling like bad luck and starts feeling inevitable.

A cloud-backed camera is genuinely expensive to run. Every frame your camera uploads is bandwidth the vendor pays for. Every clip it retains is storage the vendor pays for. Every "watch from anywhere" session and every ML motion-alert is compute the vendor pays for. For a popular app with hundreds of thousands of cameras online, that's a five-, six-, or seven-figure bill every single month — and it arrives whether or not the user ever pays a cent.

There are only four ways to cover a recurring bill like that:

Charge a subscription. The honest option, and the one the reputable vendors take.
Run ads — which on mobile usually means embedding leaky third-party SDKs that harvest data.
Sell your data or metadata to make the "free" tier pay for itself.
Shut down — which stranded-camera users discover the hard way.

When the monthly cloud bill grows faster than free users convert to paid, a vendor has exactly two levers left: raise prices or shrink the free tier. In 2026 they've all been pulling both. It isn't malice. It's the unavoidable consequence of building a product whose core feature — "your video, on our servers, watchable from anywhere" — is also its biggest permanent cost.

Which means the price hikes aren't a bug you can wait out. They're the business model working as designed. Next year's version of this article will have different numbers and the same shape.

The structural risk hiding inside "watch from anywhere"

There's a second cost to the cloud-relay model that doesn't show up on the invoice, and 2026 made it concrete.

On May 11, a firmware exposure in Meari-based devices left roughly 1.1 million cameras across 378 brands watchable by anyone who extracted a single hardcoded key. One key, more than a million living rooms. That is the structural risk of the cloud-relay design: if your video lives on a vendor's server so you can watch it from anywhere, then a breach of that server is a breach of your home. You did nothing wrong, your password was fine, and your nursery feed was still exposed — because the architecture put it somewhere a stranger could reach.

Every "camera footage leaked" headline you've ever read had a cloud account in the middle. The convenience and the vulnerability are the same feature viewed from two sides.

The option most people already own

If you're done paying — and done being one breach away from exposure — there's an entire category of camera app that has none of this pressure, because it has no cloud bill in the first place.

These apps record to the phone's own local storage and let you view the feed over your home Wi-Fi through a small built-in web server. No vendor server means no monthly bill means nothing to raise or shrink — and no central server to breach. The hardware is something almost everyone already has: that old Android phone in a drawer. A Pixel 3a, an aging Galaxy, a hand-me-down on Android 9 or newer. It has a good camera, a battery, Wi-Fi, and a processor that once ran a whole smartphone. As a security camera it's wildly overqualified, and it costs nothing because you already own it.

The honest trade-offs, stated plainly so nobody feels misled:

No view-from-anywhere out of the box. By default you see the camera when you're on your home network. If you genuinely need to peek in from outside, you set up a free VPN back into your own home or route through your own YouTube Live channel — more work, still zero recurring dollars, and the footage never touches a third party.
No vendor-server ML motion-alerts, because there's no vendor server running the model.

If those two features are worth ~$100/year to you, a subscription is the honest way to buy them — and I'll say that plainly rather than pretend otherwise. But if what you actually want is "point a camera at the back door, the crib, the driveway, or the garage and watch it on my phone at home, for free, without anyone holding my video on a server," an old Android phone plus a local-only app does exactly that.

The app I work on, Background Camera RemoteStream, is built for exactly this pattern: it's free (the whole product is free; a one-time Pro purchase only adds optional YouTube Live for off-LAN viewing), records with the screen off, keeps everything on the device, serves the LAN feed behind a PIN, and asks for no Location, no Contacts, and no account. You can grab it on Google Play. IP Webcam and Haven are other apps in the same no-cloud category — I mention them because the point here is the category, not just my app.

How to verify "free" actually means free — in 60 seconds

"Free, no cloud" is easy to print and hard to trust, so don't trust it — check it. Open Settings → Network / Data usage on the camera phone, find the app, and watch its background data while it records. On a true local-only app that number sits near zero, because nothing is being uploaded. If a so-called "free" app is quietly streaming your footage to a server, the data counter is where it shows up.

That single check is the whole difference between "free because it's efficient" and "free because you're the product." A camera that uploads is a camera that costs someone money to run — which is exactly why, sooner or later, it costs you money too, in dollars or in data. The full architectural fork behind the word "free," plus the longer version of this self-audit, is here: Is It Possible to Use a Free Android Camera App Without Giving Up Your Privacy? The Architectural Fork Behind "Free".

The honest cost comparison

Here's the per-year picture for a single camera, recurring costs included:

Setup	Year-1 cost	Recurring	Notes
Old Android phone + free local-only app	~$0–$3 (electricity)	none	Reuses hardware you own; recordings local; LAN viewing behind a PIN; no cloud server to breach
Wyze Cam + Cam Plus Annual	camera + $29.99/yr	yes	Annual raised from $19.99 in March 2026; multi-cam steered to ~$99/yr Unlimited
Arlo + Arlo Secure	camera + ~$96/yr	yes	Reported $7.99/mo per-camera plan; cloud relay
AlfredCamera (free → paid)	$0 → ~$35.99/yr	yes	2026 free tier capped, watermarked, time-limited; paid plan raised
Eufy + cloud/AI features	camera + growing fees	growing	"No-fee" positioning eroded by add-on charges

The old-phone row isn't a rounding trick. The only ongoing cost of a phone left on a charger is the electricity it draws — call it a couple of dollars a year. Everything that makes the other rows expensive is the cloud subscription, and a local-only setup simply doesn't have one. If you want the cheapest-possible build spelled out step by step, I walked through the whole $0 setup here: What's the Cheapest Way to Set Up a Home Security Camera Without a Subscription in 2026?.

The catch nobody mentions: keeping it alive

I'd be doing you a disservice if I stopped at "install an app, you're done." There's one genuinely technical hurdle, and it's why a lot of DIY "old phone camera" experiments fizzle: modern Android aggressively kills background work to save battery. A naïvely built camera app can record beautifully for three or four hours and then silently die — and you find out at the exact moment you needed the footage.

Beating that requires the app to own a proper foreground service, handle wake locks correctly, and configure its Camera2 session to survive the OS's power management. A free app doesn't have to get that right; a good one does. If you want the full breakdown of why old-phone cameras die after a few hours and how a well-built one fixes it, it's here: Why Your "Old Phone Security Camera" Dies After 4 Hours (And How to Fix It on Modern Android). Read it before you rely on any DIY camera — it's the difference between a toy and something you'd trust on your front door.

So — is it worth switching?

If your plan got worse this year, that wasn't an accident you can wait out; it's the cloud-camera business model doing exactly what it's built to do. The price went up because the vendor's monthly bill went up, and that bill never goes away.

The escape is the same regardless of which logo is on your current camera: a phone from your drawer, a free local-only app you can audit in 60 seconds, and a charger. No recurring invoice, and — just as importantly in a year that put 1.1 million cameras one key away from exposure — no vendor server holding your footage for someone to breach.

You don't have to fire your subscription today to find out. Dig out the old phone, install a local-only app, and run the data-usage test for yourself. The app is free on Google Play, and there's more on the project at superfunicular.com.

Background Camera RemoteStream is a free, local-only Android camera app by Super Funicular LLC — record with the screen off, view over your own Wi-Fi in any browser behind a PIN, no account and no cloud. Built in the open with Claude Code over 75+ AI-assisted sessions.

What's the Cheapest Way to Set Up a Home Security Camera Without a Subscription in 2026?

Super Funicular — Tue, 09 Jun 2026 07:06:52 +0000

The cheapest home security camera in 2026 isn't a camera you buy. It's a phone you already own, a free local-only app, and a charger. Total new spend: $0. That sounds like a slogan, so here's the honest math behind it — and the reason the gap between "buy a cheap camera" and "pay nothing" got wider this year, not narrower.

The hardware was never the expensive part

Walk into any electronics aisle and you can find a security camera for $25–$40. That low sticker price is the whole trick. The camera is the loss leader. The subscription is the product. And in 2026, the subscriptions didn't get cheaper — most of them got more expensive, and several "free" tiers quietly turned into demos.

Here's what actually changed this year across the popular options:

AlfredCamera tightened its free tier into a trial: free accounts are capped to a small number of cameras, clip retention got shorter, live sessions are time-limited, and saved clips are watermarked. The paid plan's annual price went up too (the widely reported jump to around $35.99/year). The free tier is now a tour of the paywall.
Arlo Secure raised its single-camera plan again — the reported move from $4.99 to $7.99/month. That's roughly $96 a year. Per camera.
Wyze, long the budget darling, raised Cam Plus Annual in March 2026 from $19.99 to $29.99 per camera per year, and now steers multi-camera households toward Cam Unlimited at $9.99/month (about $99/year). Useful AI events and longer cloud history increasingly live behind that line.
Eufy, marketed for years as the "no monthly fee" option, has been steadily layering on cloud storage and AI-feature charges.

So the real question was never "what's the cheapest camera." It's "what setup has no recurring bill and no cloud middleman." Once you frame it that way, the answer stops being a product on a shelf.

The $0 setup, step by step

Almost everyone reading this has a drawer with an old phone in it. A Pixel 3a, an aging Galaxy, a hand-me-down that still charges and runs Android 9 or newer. That phone already has a good camera, a battery, Wi-Fi, and a processor that ran a whole smartphone OS. As a security camera it is wildly overqualified.

Here's the entire setup:

Dig out the old Android phone. Wipe it if you like, but you don't have to. Anything on Android 9+ that holds a charge works.
Install a free, local-only camera app from Google Play. "Local-only" is the load-bearing phrase: recordings stay on the phone, and viewing happens over your own Wi-Fi. No vendor account, no cloud upload, no subscription — because there's no server in the middle that someone has to pay for.
Plug it into a charger where you want eyes: front door, nursery, driveway, garage, the spot the packages land.
View it from your laptop or another phone's browser over your home network.

That's it. Four pieces — old phone, free app, charger, your existing Wi-Fi — and none of them generate a monthly invoice.

The app I work on, Background Camera RemoteStream, is built for exactly this pattern: free, no account, recordings stored locally on the device, and optional in-browser LAN viewing protected by a PIN. You can grab it on Google Play. I'm not going to pretend it's the only local-only app out there — but it's the one whose claims I can tell you how to verify, which matters more than my word.

If you want the friendly, screenshot-level walkthrough of getting that first phone running as a camera, the full guide lives here: Turn Your Old Android Phone Into a Free Security Camera — No Subscription Required.

How to confirm "free" actually means free

"Free, no cloud" is easy to print and hard to trust. So don't trust it — check it. This takes about a minute:

Open Settings → Network / Data usage on the camera phone, find the app, and watch its background data while it records. On a true local-only app, that number sits near zero, because nothing is being uploaded. If a so-called "free" app is quietly streaming your footage to a server, the data counter is where it shows up. A camera that uploads is a camera that costs someone money to run — which is exactly why, sooner or later, it costs you money too.

That same check is the difference between "free because it's efficient" and "free because you're the product." If you want the deeper version — the five-sign, 60-second self-audit for whether a camera app could be watching you without your knowledge — I wrote that up separately and it pairs naturally with this setup.

The one real tradeoff (and why it's usually a feature)

Local-only has exactly one honest downside, and I'm not going to bury it: viewing happens over your own network, not through a vendor's "watch from anywhere on Earth" relay. By default you see the camera when you're on your home Wi-Fi.

For the overwhelming majority of real use cases — the front door, a sleeping baby, a pet, the driveway, whether the package arrived — that's exactly what people wanted anyway. They were never going to check the nursery cam from a beach in another country. And the absence of that always-on cloud relay is precisely why there's no monthly bill and no breach surface. Every camera-footage-leaked headline you've ever read had a cloud account in the middle. Local-only doesn't have one to leak.

And if you genuinely do need to peek in from outside the house, you don't have to rent the vendor's cloud to get it. You can run a free VPN back into your own home network and reach the camera as if you were sitting on the couch. More work, zero dollars, and the footage never touches a third party.

The honest cost comparison

Here's the per-year picture for a single camera, recurring costs included:

Setup	Year-1 cost	Recurring	Notes
Old Android phone + free local-only app	~$0–$3 (electricity)	none	Reuses hardware you own; recordings local; LAN viewing behind a PIN
Wyze Cam + Cam Plus Annual	camera + $29.99/yr	yes	Annual raised from $19.99 in March 2026; multi-cam pushed to ~$99/yr Unlimited
Arlo + Arlo Secure	camera + ~$96/yr	yes	Reported $7.99/mo per-camera plan; cloud relay
AlfredCamera (free → paid)	$0 → ~$35.99/yr	yes	2026 free tier capped, watermarked, time-limited; paid plan raised
Eufy + cloud/AI features	camera + growing fees	growing	"No-fee" positioning eroded by add-on charges

The catch nobody mentions: keeping it alive

I'd be doing you a disservice if I stopped at "install an app, you're done." There's one genuinely technical hurdle, and it's the reason a lot of DIY "old phone camera" experiments fizzle: modern Android aggressively kills background work to save battery. A naïvely built camera app can record beautifully for three or four hours and then silently die, and you don't find out until the moment you needed the footage.

Beating that requires the app to own a proper foreground service, handle wake locks correctly, and configure its Camera2 session to survive the OS's power management — none of which a free app has to bother getting right, but a good one does. If you want the full breakdown of why old-phone cameras die after a few hours and how a well-built app fixes it, that's here: Why Your "Old Phone Security Camera" Dies After 4 Hours (And How to Fix It on Modern Android). It's worth reading before you rely on any DIY camera, because it's the difference between a toy and something you'd trust on your front door.

While we're on streaming: if your "watch it" need is actually "broadcast it" — a live event, a workshop, a wildlife feeder — the same old phone can push a YouTube Live feed for free, and I compared the apps that do it well here: Best Apps to Stream YouTube Live from Your Android Phone.

So — what's actually cheapest?

Cheapest in 2026 is local-only, on hardware you already own. Not the $25 camera with the $96-a-year leash. Not the "free" app whose free tier is a watermarked demo. A phone from your drawer, a free local-only app you can audit in 60 seconds, and a charger.

The subscription camera business is built on the bet that you'll value convenience over the recurring charge and never do the multiplication. Do the multiplication. For a front door, a nursery, a pet, or a driveway, the $0 setup isn't a compromise — it's just the version where you keep your footage and your money.

You can start with the phone in your drawer today. The app is free on Google Play, and there's more on the project at superfunicular.com.

Why Your Favorite Security Camera App Is Getting Worse — and How to Run a Free Local-Only Camera on an Old Android Phone

Super Funicular — Mon, 08 Jun 2026 07:06:49 +0000

Originally answered on Quora, June 1 2026 — the opener of a "your camera plan got worse, here's why" batch. This is the dev.to canonical at T+7d, expanded with the AlfredCamera 2026 pricing change now confirmed in their help center, the cloud-bill economics behind all three trends, and the architectural fix that sidesteps the whole pattern.

TL;DR

Three things are happening to the cloud-camera category in 2026 at the same time: free tiers are tightening, paid tiers are getting more expensive, and the apps that didn't do either are running into the cloud-bill problem. None of these is a single vendor making a single bad decision — they're the shape of subscription-camera economics catching up with everyone, on roughly a 6–12 month lag between vendors. The category that is structurally immune to all three is local-only: the recording stays on the phone, the viewer connects to the phone over your own Wi-Fi, and there is no operator whose P&L can change the product underneath you. Here's the mechanism behind each trend, and how to migrate to a free local-only setup on a phone you already own.

If your security camera app feels like it got worse this year, you are not imagining it, and you are not unlucky. You are on the receiving end of at least one of three trends that are hitting the entire cloud-camera category at once. Let me separate them, because the fix depends on which one is squeezing you — and there's a fourth option that makes all three stop mattering.

I'm the developer of Background Camera RemoteStream, a free, no-cloud, no-account Android app that turns an old phone into a continuously-recording home camera with the screen off. I spend a lot of time watching this category, because the architecture I chose is a direct bet against the trends below. So treat the rest of this as an interested party's read — but the mechanisms are checkable, and I'll show my work.

Thing #1 — free tiers are getting tighter

AlfredCamera was, for years, the default answer to "how do I turn an old phone into a security camera," for one reason: the free tier was actually usable. That changed in 2026.

Per AlfredCamera's own help-center announcement on the 2026 plan and pricing, the free tier is now limited to up to 2 online cameras. The premium tiers stack above that — Premium Standard up to 4 cameras, Premium Plus unlimited — and the annual price for new Premium Standard subscriptions rose roughly 20%, from $29.99 to $35.99 per year. The US effective date was March 16, 2026; other regions saw in-app pricing update from April 7.

Read that as a product change, not a press release. Anyone who ran three or more old phones as cameras, anyone who relied on more than a glance of clip history, anyone who kept a continuous live view up — their setup quietly degraded. Free-tier squeezes are designed to be discovered, not announced, because the cleanest version of the move is the one existing users surface themselves when they hit the new wall.

This isn't an AlfredCamera-specific indictment. It's the most legible recent example of a category-wide motion. Wyze, Ring, and others have run their own versions of the same tightening.

Thing #2 — paid tiers are getting more expensive

The AlfredCamera annual bump is one data point in a broader curve. Arlo Secure raised its entry-tier subscription from $4.99 to $7.99 per month in 2026 — covered by Tom's Guide and most of the consumer-tech press. Eufy's per-camera cloud fees crept further into territory that used to be bundled; what reads as a one-time hardware purchase becomes a $2.99-per-camera-per-month recurring line item on top.

The throughline: subscription camera services are an annuity business. An annuity has to grow, and there are only a few levers — raise the price, narrow the free tier so more users convert, or add paid features above the line where the old free tier sat. Most vendors pull all three over time. The reason it feels coordinated, even though it isn't, is that everyone is responding to the same underlying cost structure.

Thing #3 — the "still generous" free apps have a cloud-bill problem

Here's the trend that's easy to miss because it hasn't fully arrived for every app yet.

A free cloud camera service has a per-user bandwidth and storage bill that scales linearly with active users. Every camera streaming to a vendor backend, every clip retained, every live session relayed — that's egress and storage the operator pays for, whether or not the user ever pays them a cent. The bill comes from somewhere. As paid conversion gets harder (see Thing #2), the weight on the remaining options grows: tighten the free tier (Thing #1), or monetize what's already on the servers — the data.

I wrote the long version of this as What Data Does a Free Android Security Camera App Actually Collect? A Five-Minute Architecture Audit — including how to read an app's real data behavior off settings screens that ship on every Android phone, instead of trusting the Play Store description. The short version: when a free cloud app's economics get tight, the data on its servers stops being a liability and starts being an asset, and you usually can't tell from the marketing copy when that line gets crossed.

The 2026 reason this stopped being abstract is the Meari breach. A single private key gave one researcher access to roughly 1.1 million baby monitors and security cameras across 378 brands, because the shared architecture is "every frame uploaded to a central backend." I broke that down in Is My Baby Monitor App Watching Me Too? Six Signals That Tell You a Free Camera App Is Selling Your Data. The architecture is what scaled the breach from one key to a million cameras. A better promise from the next cloud vendor doesn't fix that; a different architecture does.

Add them up

Tighter free tiers, more expensive paid tiers, and a structural pull toward monetizing data on the servers — together, that's the feeling you have. The category you started with isn't the category you have now, and the cost of migrating is starting to look smaller than the cost of staying.

The option that's immune to all three: local-only

There is one architecture where none of the three trends can reach you, because the thing each trend monetizes simply doesn't exist in the software.

In a local-only setup, the recording is written to the phone's own storage. The viewer connects to the phone directly over your home Wi-Fi, through an embedded web server running inside the app — any browser on the same network can pull up the live view, with no app to install on the viewing device and no cloud relay in the middle. There is:

No cloud bill, because the camera uploads nothing. So there's no Thing #3 pressure to monetize data — there's no data on anyone's server to monetize.
No free-tier squeeze, because the "free tier" is the phone you already own. There's no operator to narrow it.
No per-camera subscription, because the operator running the service is you. No watermark, no 24-hour retention cap, no time-limited live sessions, because there's no vendor cost to ration.

That's the whole pitch, and it's an architectural claim you can verify rather than trust. The free app I built on exactly this architecture is Background Camera RemoteStream: records to local storage, serves a LAN-only web view, no account, no cloud, no subscription, no per-camera fee.

What it actually takes to migrate

I'm not going to pretend local-only is free of trade-offs. Two things to set expectations honestly.

It's on-your-LAN by default. Viewing the camera from inside your home is automatic — open a browser on the same Wi-Fi, done. Viewing from outside your home takes one extra step: a free mesh-VPN like Tailscale or WireGuard, which gives you a private path back to your home network without exposing anything to the public internet. Both have free tiers; setup is about five minutes. This is the honest version — anyone who tells you local-only does remote viewing with zero configuration is selling a cloud relay you'll eventually pay for.

You maintain the phone. Keep it plugged in (continuous recording is power-positive against any battery), keep it on Wi-Fi, keep it on a shelf with a clear view of what you care about. The harder-than-it-looks part is surviving Android's battery management — every major OEM (Xiaomi, Samsung, Oppo, Vivo, Huawei) layers its own service-killing logic on top of stock Android, which is why a camera app that works for a weekend on a dev phone often dies after four hours on a real device. I wrote up the three layers of aggression a foreground service has to survive in Why Your "Old Phone Security Camera" Dies After 4 Hours — and How to Fix It on Modern Android. Getting that right is most of the engineering.

The trade, stated plainly: do a small amount of setup once and never pay anyone monthly, versus pay $4.99 → $7.99 → next-tier forever and accept that the product shape changes whenever the operator's P&L does.

A bonus the same architecture gives you

Because the recording pipeline already lives on the phone, the same app can also push a live stream to YouTube Live when you want something public — a porch feed during a storm, a nest box, a hackathon table. That's the opposite end of the privacy spectrum from a LAN-only home camera, and it's a deliberate choice each time rather than a default. If that's a use-case for you, I compared the options in Best Apps to Stream YouTube Live from Your Android Phone (2026). The point worth keeping: local-by-default and public-on-purpose are both architecturally clean when there's no mandatory vendor cloud sitting between you and your own camera.

The bottom line

The three trends squeezing the cloud-camera category in 2026 are real, they're structural, and they'll keep repeating across vendors on a lag. You can keep chasing the least-bad cloud plan each renewal, or you can step out of the pattern entirely by picking the one architecture none of the trends can touch. The migration cost is a free app, an old phone, and twenty minutes. The recurring cost after that is zero — by design, not by promise.

Free, no account, no cloud: Background Camera RemoteStream on Google Play · superfunicular.com

This week on @Digital_Nomad_Media — 25 new clips (2026-W23)

Super Funicular — Sun, 07 Jun 2026 14:01:41 +0000

Quick weekly digest from my YouTube channel — every clip below is fresh in the last 7 days.

Your Pitbull vs My Pitbull ✌️🤠

16s

Lifestyles of the Rich and famous 🎅✌️

94s

Adventures with the pack

167s

The infestation of Digi Nomad ✌️🤠

43s

Adventure Girl - Lady the Pitbull

174s

Wait for it.................

180s

Let there be light....at McDonald's

180s

Can we do a reboot?

13s

No means No ✌️🤠

10s

Good one? ✌️🤠

We frozed all upz up here ✌️🤠

He did it 😮

12s

END your rentals at Grover.com ✌️🤠

93s

How we catch alligators in Louisiana!

Friends for life?

22s

Your Doordash order is on its way!

13s

Working dog

15s

You think you had a rough labor and delivery?

Dat sneaky Squeaky!

15s

Open says me

15s

New Paradigm in fast food

15s

I don't get this $#!T man

15s

Amazon Viagra delivery

12s

You're all gambling crazy!

15s

Capitania Monsteronious

15s

I also built an app — DigiCam

I also made DigiCam, listed as Background Camera RemoteStream on Google Play. It's the world's first screen-off YouTube live streaming app: stream live with the screen off for ~10× the battery life, plus background recording, remote web console control, file-based YouTube Live, and playlists. Privacy-first, all local storage. Free with ads or Pro for the full feature set:
https://play.google.com/store/apps/details?id=com.superfunicular.digicam

Watch the full channel: @Digital_Nomad_Media

Tags: #SuperFunicular #DigiCam #DigiNomad #LadythePitbull #YouTubeShorts #ContentCreator #comedy #voiceover #doordash

Cities Are Putting Trash Bags Over Their Surveillance Cameras — The Bag Is a Patch, the Architecture Is the Bug

Super Funicular — Sat, 06 Jun 2026 08:06:39 +0000

Reactive analysis of the Dayton Flock camera suspension, June 2026. Sources linked throughout.

TL;DR: Dayton, Ohio is covering its license-plate-reading cameras with trash bags after an audit found 7,000+ searches of its camera data by outside agencies in violation of city policy. The deeper lesson isn't about one vendor or one city — it's that a written policy cannot protect data that is architecturally searchable by third parties. The only camera data that can't be misused by someone else is data that never leaves your device.

What happened

This week, city workers in Dayton, Ohio began pulling black trash bags over dozens of automated license plate readers (ALPRs) operated by Flock Safety, after the Dayton Police Department found more than 7,000 cases of searches relating to immigration enforcement made by outside entities — searches that city policy explicitly prohibited (Fortune, June 3). City officials called them "egregious violations of policy" and appropriated an extra $30,000 to audit the camera data logs.

Dayton isn't alone. 404 Media and Techdirt report a wave of cities bagging or removing cameras, and dozens of communities have cancelled contracts over the past year. Some cities discovered a second problem on the way out: they signed multimillion-dollar contracts without a legal or technical mechanism to force the vendor to actually shut the cameras down. Hence the trash bags — a physical workaround for an off switch they don't control.

The part that matters for everyone, not just cities

Strip away the municipal politics and a clean engineering lesson remains. Dayton had a policy: this data shall not be used for X. The policy failed 7,000 times. Why? Because the data sat in a centralized, networked system that outside entities could query. A policy is a promise. Architecture is a guarantee. When data is searchable by parties you don't control, the policy governing it is only as strong as every single party's compliance — forever.

This is the same structural argument Senator Wyden made about adtech data flowing to foreign adversaries (my analysis here), and the same one at the center of Texas v. Netflix (covered here): once data exists in a place others can reach, "we won't" eventually becomes "we did."

And there's the second lesson, the one hiding under the trash bags: whoever controls the off switch owns the camera. Dayton is bagging hardware bolted to its own poles because the shutdown path runs through a vendor.

Ask the same two questions about the cameras in your home

If you run a consumer cloud camera — or a free camera app on a spare phone — the Dayton questions apply directly to you:

Where does the footage live? If it relays through a vendor's cloud, your footage is governed by policy (their terms of service), not architecture. Breaches, subpoenas, partner integrations, and "pilot programs" all happen at the server, regardless of what the app told you.
Who controls the off switch? If your camera stops working when a subscription lapses or a server is sunset, you never really controlled it.

How I built around this

I'm an indie developer, and these two questions are why my app, Background Camera RemoteStream, is built local-only:

Footage stays on the device. No vendor cloud, no relay server, nothing for a third party to query — 7,000 times or once.
No account required. There is no server-side identity to subpoena, breach, or cross-reference.
Zero tracking. No analytics SDKs phoning home.
The off switch is yours. It's your phone. Uninstall ends everything — no contract, no bagging required.
Streaming is opt-in and yours. If you want remote viewing, you push to your own YouTube Live channel, on your terms, when you choose.

It turns any spare Android phone into a security camera with screen-off recording (setup guide here) — and the architecture makes the Dayton failure mode structurally impossible, because there is no central pile of footage for anyone to search.

Get it on Google Play: Background Camera RemoteStream
Website: superfunicular.com

Build-in-Public Week 4: Channel-Pivot Pilot Verdict — +196v Catalog Lift, +182v Quora 30d, and an Honest First Read on LinkedIn-First

Super Funicular — Sat, 06 Jun 2026 07:11:45 +0000

Originally published on LinkedIn, May 30 2026, as a native long-form post — this dev.to canonical lands at +7d per the reverse-channel-order rule. X long-post ran June 1 (+48h). Same content asset, three surfaces, inverted order.

TL;DR: The channel-pivot rule (Quora-first → X long-post → dev.to canonical at +7d) just finished its second full 7-day evaluation window at +196 catalog views (+60.3%) — more than double the +92v (+39.5%) it produced in window one. Quora 30-day views added +182 (+19.8%) and crossed the 1K monthly milestone. The secondary experiment — publishing Build-in-Public to LinkedIn first — produced honest, smaller numbers: 8 impressions on the LinkedIn native post, 1 view on the X long-post. The deciding read is the Day-1 view count on this very article. Build-in-public means publishing the verdict either way.

For eight weeks, my dev.to catalog was a museum exhibit. Articles got published, decent ones earned a slow trickle of views from search, and the 1-day post-publish window — the part of dev.to traffic that's supposed to matter — was almost always a flat zero. I was reading the analytics weekly, and the weekly story was: "no measurable change."

Then I changed the publish order. Not the writing, not the topics, not the platforms. Just the order.

This is the two-window verdict on that change, plus the secondary experiment that this article is itself the test instrument for.

The pilot in one paragraph

I'd been writing dev.to as the canonical surface. The article published first, then a Twitter thread, then a Quora answer, then LinkedIn — pillar to derivatives, the standard waterfall. The Week-3 scorecard compared two real numbers from that approach: on Quora, our "Spying" answer climbed from 135 views to 447 views in 24 hours. On the matched-content dev.to publish, Day-1 traffic was zero. Same words. Same week. Wildly different surfaces.

So I flipped it. Starting 2026-05-19, the rule became: Quora first, X long-post at +72h, dev.to canonical at +7d. Pillar content lives on the surface where its audience is already searching. The waterfall reverses. The dev.to canonical becomes the durable backstop, not the launchpad.

Window one (5/19–5/24): catalog +92 views (+39.5%) — the first material lift since the feed-pickup throttle started. Window two (5/24–5/31): +196 views (+60.3%), from 325 to 521 — the largest 7-day catalog lift in our scorecard era, and a clean doubling of window one's record. Two-week rolling: +288v dev.to (+88.6%) and +568v Quora 30d (+106.8%), both starting from a flat 8-week pre-rule baseline. As of this writing the catalog sits at 614 cumulative views — up from 253 on May 19, +142% in 18 days.

That's the pilot. Now the details.

What "+196 views" actually means after eight flat weeks

A throttled dev.to account looks like this: your existing catalog keeps slow-trickling views from search (good), but any new publish hits a wall on Day 1. We confirmed it across thirty articles in early May. Three consecutive newsjacks hit identical 0–2 view ceilings inside 96 hours of publish, while 4-day-old pieces in the catalog continued to accumulate views normally. The pickup mechanism had quietly shut off for new submissions on this account.

The conventional fix is "wait it out and reduce publish cadence." We did that for a week. The throttle didn't lift. The new theory came out of looking at where our content actually moved people: not at dev.to discovery, but at Quora's intent-graph. A question like "What information does a free Android security camera app collect about my home?" has the exact shape of intent we want — anxious, specific, ready to act — and Quora routes those questions to answer-writers who have published in the topic. The audience is already on the page. The reader doesn't need a feed to find us; the question itself is the feed.

The pilot moved the pillar to where the audience already was. The dev.to article stopped being the publish event and became the destination link people followed after they'd already engaged with the content somewhere else. The throttle didn't lift — but the throttle stopped mattering, because the new traffic was external referrals onto an existing catalog, and dev.to's referral-traffic surface is not throttled the same way feed-pickup is.

Window two's composition tells the story even better than the total. The +196 concentrated in three places: a newsjack on the Kimwolf botnet bust (id 3747395) that climbed 0 → 32 views across its first seven days; the Texas/Meta newsjack adding +20 more before saturating at 52v; and a canonical (Six Signals) breaking 0 → 20 on Day 4. Every one of those was co-published with a same-week Quora pillar on the matching anxiety question. The pieces that weren't paired stayed flat. Cross-channel pairing is the variable. It's now confirmed across two consecutive windows with monotonically increasing magnitude.

What "+182v Quora 30d" actually means

Quora was a side surface in our marketing plan. The account had 16 answers and 64 monthly views as of the 2026-05-10 scorecard. Then a single answer on the "Is my phone spying on me?" question shape moved 135 → 447 views in a 24-hour window, and we rebuilt the production line around what it taught us.

Window two: 30-day content views moved 918 → 1,100 (+182, +19.8%) — crossing the 1K monthly milestone — on the largest single-week publish volume ever (+17 net-new answers, 30 → 47). That's roughly 23 views per answer on the catalog average, far above any other channel we operate. The viral "Spying" answer crossed 1,000 views on its own and is still compounding.

The shape that works, every time: the question begins with "Is [thing happening] to me?" or "How do I know if [thing] is doing [bad behavior]?" The reader is anxious. The reader does not want a polished comparison list. The reader wants the diagnostic ladder — a step-by-step way to check the thing for themselves, starting with the lowest-effort test. Our app comes in at the end as the option whose architecture removes the question entirely, not as the first-paragraph plug.

That structure works on Quora specifically because Quora's recommender treats answer length plus question-specificity as signal. Comparison lists are good for search-engine acquisition; diagnostic ladders are good for Quora's internal recommender. We pivoted the writing to match the surface.

The Texas/Meta newsjack as a control variable

A newsjack is a special case of pillar content: the topical urgency is the discovery vector. We published id 3723597 on 2026-05-22 in reaction to Texas AG's investigation into Meta AI Glasses (the "always-enabled mode + facial-geometry collection" complaint). The article used a three-architectural-questions frame: opt-in vs. always-on, local vs. cloud, on-device vs. off-device inference. Our app is a worked example on each.

That article did something no dev.to publish on this account had done since the throttle began: it broke double digits on Day 1. It compounded to 52 views by Day 7 and holds there today, still the catalog's best performer.

The Texas/Meta NJ is meaningful as a control because we did not change the dev.to-side publishing mechanics for it. Same API, same tags, same byline. The variable that moved was the cross-channel pairing: this NJ ran alongside a Quora pillar the same week, and the Quora pillar referenced the dev.to article inline. External Quora traffic landed on the dev.to canonical via the cross-link. Then the Kimwolf NJ repeated the pattern (0 → 32v) under the same pairing rule, beating Texas/Meta at the same days-since-publish offset. n=3 NJs now confirm it: cross-channel pairing, not topic narrowness, is what clears the throttle. The pairing rule is now a hard gate in the content engine — no newsjack ships without a same-week Quora companion on the matching frame.

The LinkedIn-first experiment: honest numbers, verdict pending

The pilot above is the headline finding. The secondary experiment is the one this article exists to measure — and the early numbers deserve to be reported as plainly as the good ones.

The hypothesis came from Week 3: when we cross-posted that week's Build-in-Public to LinkedIn on a 4-follower account, the post earned 34 impressions. On dev.to, the same content, published the same day as the canonical, earned 0 views on Day 1. That ratio said: for the build-in-public format specifically, LinkedIn is the carrier and dev.to is the archive. So Week 4 — the piece you're reading — reversed the channel order. LinkedIn published first (Friday May 30, native long-form). The X long-post followed June 1 at +48h. This dev.to canonical lands today, June 6, at +7d.

Here are the measured numbers, pulled this morning before publish:

LinkedIn native post (5/30): 8 impressions. Lower than Week 3's 34 — going native-first did not, by itself, buy more LinkedIn reach on a 5-follower account.
X long-post (6/01): 1 view. The long-post format continues to underperform on our X account, where reply-driven engagement has always beaten timeline posts.
dev.to canonical (this article): publishing now. The Helm-locked decision criterion: if this piece records ≥1 view on Day 1 — something Week 3's canonical could not do — the LinkedIn-first runway hypothesis survives. If it lands at 0, the rule is falsified and the E-archetype channel mix gets rethought.

Two honest observations while the verdict is pending. First, the LinkedIn-side lift the hypothesis predicted has not materialized — 8 impressions is a real number on a 5-follower account, but it is not a runway. Second, even if Day 1 comes in at zero, the experiment cost nothing: the content was written once and published three times, and the dev.to canonical was always going to be the backstop, not the carrier. That asymmetry — cheap experiments with one-directional downside — is the only reason a solo developer can afford to run a pilot like this at all.

The peer-dialogue compound: from comments to disclosure

One quiet result from the window deserves its own section, because it produced the catalog's first comments — a column that had read zero since launch.

We've been leaving thoughtful, non-promotional comments on third-party dev.to posts in our topic area for six weeks. On 2026-05-18, a comment on a peer's end-to-end-encryption article landed on the AI-snippets surface within 24 hours — faster than our own articles index. On 2026-05-22, a third party (@privacyfish, from the privacy.fish mail service) joined the same thread, replying to our reply. And on 2026-05-31, a developer we'd been in a multi-turn dialogue with (FuriousOfNight) disclosed his own unreleased desktop camera project in a reply on our Week-3 build-in-public thread — the first verbatim author-disclosure the comment graph has produced, and the reason the Week-3 canonical now carries 2 comments.

Dev.to's article-level signals (reactions, comments, follows) are noisy, but the thread shape itself is the kind of signal that algorithms pick up — depth of replies, breadth of participants, time-to-second-response. We're maintaining six waiting-for-turn-back peer-dialogue nodes in the comment graph. It's the slowest channel we run and the only one that produces relationships instead of views.

What we're keeping, what we're changing

Keeping

The channel-pivot rule for content with anxiety-question shape: Quora-first, X long-post at +72h, dev.to canonical at +7d. Two windows of evidence, +288v dev.to and +568v Quora on the two-week rolling read.
The diagnostic-ladder writing shape for Quora pillars: low-effort tests first, high-effort tests last, app as architectural existence proof at the end.
The newsjack pairing gate: no NJ publishes without a same-week Quora companion on the matching frame. n=3 confirmations.

Changing

Publish-cadence watch: window two shipped 8 net-new dev.to pieces in 7 days — the same regime that triggered the original feed-pickup throttle. A deliberate gap day is now scheduled weekly to keep the rolling cadence at or under 1.2 articles/day.
Quora wave 3 pivots from privacy-anxiety to subscription-shrinkage framing — the dominant competitive moment right now is camera-app vendors squeezing free tiers (AlfredCamera's 2-cam/24h watermark squeeze, Arlo Secure's $4.99 → $7.99 hike, Eufy's per-camera cloud-fee creep). Same question shape, new anxiety.
UTM tagging moves to the daemon level — a five-scorecard gap between deciding to do it and doing it consistently. Still fixing.

Open questions

Does this canonical land above zero on Day 1? (The LinkedIn-first verdict — this article is the instrument. Answer lands 2026-06-07; the full +7d read on 2026-06-13.)
Does the diagnostic-ladder shape carry from privacy-anxiety to cost-anxiety questions, or was it topic-specific? (Wave-3 batch is the test, running now.)
Does the canonical-cohort 10-view plateau (three pieces stuck at exactly 10v for days) represent a real ceiling or a view-counter artifact? (Watching through 6/08.)

Where the app actually is

Numbers as of this morning's API pull:

dev.to: 62 published articles, 614 cumulative views, 4 reactions, 2 comments. Up from 253 views on 2026-05-19 — +361v / +142% in 18 days, the largest sustained lift since launch.
Quora: 47 answers, 1,100 monthly content views (up from 64 in early May), 11 followers. The highest-yield organic surface in the system.
Google Play: live on production. The app is privacy-first and local-only by architecture, with an embedded Ktor server for LAN streaming and optional YouTube Live for opt-in cloud streaming.
The system: 15 scheduled tasks across content generation, distribution, analytics, strategy, and community pulse — built on Claude Code, the same way the app itself was built across 75+ AI-assisted sessions.

If you're building something similar — a solo product with a marketing problem that has to be solved without a team — the lesson from these two windows is the one I keep relearning: the surface determines the format, and the format determines the order. We optimized two of those three for eight weeks before fixing the third. The third was the one that mattered.

The app: Background Camera RemoteStream on Google Play

The website: superfunicular.com

Cross-links for further reading:

Originally published on LinkedIn May 30, 2026. X long-post June 1. dev.to canonical June 6. Same content, three surfaces, inverted order — and this article is the measuring instrument for whether that order works.

Why Does My Android Phone Heat Up When I Leave a Camera App Running? A 5-Layer Thermal Diagnostic

Super Funicular — Fri, 05 Jun 2026 07:07:02 +0000

Originally answered on Quora, May 29 2026. Expanded here with a full five-layer diagnostic ladder, the architecture behind each layer, and a 2026 build-in-public addendum.

TL;DR: Heat from a camera-recording phone is a downstream signal, not a verdict. About 80% of the time a warm phone is doing its job correctly. The other 20% of the time, the heat is the app telling you — in physical form — that something architectural is wrong: a runaway encoder profile, a wake-loop instead of a foreground service, or a cloud-upload pipe running 24/7. This is the five-layer ladder I use to tell which one you have, from a 30-second battery check to the architectural fix that makes the whole question disappear.

I'm the developer of Background Camera RemoteStream — a free, no-cloud, no-account Android app that turns an old phone into a continuously-recording home camera with the screen off. I've spent more hours than I'd like to admit measuring the thermal profile of phones that record video for hours at a stretch. The single most common question I get is some variant of "my phone gets hot when I leave the camera running — is that normal, and is it safe?"

The honest answer is: heat is a symptom, and symptoms have causes you can isolate. Here's the diagnostic ladder, lowest effort to highest.

Layer 1: Is it the camera, or is it the radio?

Open Settings → Battery → Battery Usage and sort by app over the last six hours.

If your camera app is at the top, that's expected and fine. Recording video is genuinely the most expensive sustained thing a phone does. On a 2019-era device, 8–15% battery per hour at 1080p/30fps is normal, and the warmth that comes with it is normal too.

If "Cellular standby" or "Wi-Fi" is at the top instead, the heat is the radio, not the camera. That usually means the app is pushing frames over the network constantly — the chipset is warm because the modem is warm. Disable mobile data on the camera-phone if you only need it on Wi-Fi, and watch the temperature for twenty minutes. If it drops, the radio was your culprit, and that tells you something important about the app's architecture (see Layer 4).

Layer 2: Is the app a foreground service, or is the OS waking it on a loop?

A correctly-built camera-recording app holds a single foreground service for the entire session. The screen turns off; the service stays alive; the encoder stays open; CPU usage stays steady — around 8–12% sustained on a 2019 phone at 1080p/30.

A badly built one leans on WorkManager or AlarmManager to wake up periodically and re-acquire the camera. Every wake costs more energy than continuous running, because the camera hardware has a non-trivial cold-start cost each time it spins up. The counterintuitive result: the phone gets hotter doing intermittent work than it would doing steady work.

You can spot the bad pattern without any tools. Check the persistent notification. If the recording notification sits there, steady, the whole time — that's a foreground service, and it's correct. If it flickers in and out, or never appears at all, the app is doing something else, and the heat is the side effect of constant restart cycles.

There's a whole essay on why WorkManager is the wrong primitive for video recording — Why Does My Android Camera Stop Recording When the Screen Turns Off? Doze, WorkManager, and the Right Way to Build a Foreground Service. The short version: Doze and App Standby are designed to kill background work to save battery, so an app that fights them with periodic wakes is both fragile and hot. A foreground service is exempt by design, which is why it's both more reliable and cooler.

Layer 3: Is the encoding profile reasonable?

This is where most user-side heat actually originates. Camera apps that record at:

4K / 60 fps on an old phone — the encoder is being asked to do roughly twice the work it can sustain. The chipset thermally throttles within 20–40 minutes, recording quality degrades, and the phone gets hot enough to make you nervous.
1080p / 60 fps with HEVC — about right for a recent phone, too much for a pre-2020 device.
1080p / 30 fps with H.264 — the sweet spot. This is what most well-behaved apps default to (Background Camera RemoteStream does, on devices that report a sub-2020 SoC). Steady CPU around 8–12%, surface warm but never alarming.

If your phone is hot, drop to 1080p / 30 / H.264 and watch for 20 minutes. Ninety percent of the time, that stabilizes it. The lesson underneath: resolution and frame rate are not free, and the marketing-friendly "4K!" default is often the thing cooking your phone.

Layer 4: Is upload load adding heat?

If your app is local-only — recording to the phone's own storage and serving a live stream over your home Wi-Fi to a browser tab — the upload load is whatever a laptop pulls live, usually 4–8 Mbps and only when someone is actually watching. Light, intermittent, cool.

If your app is cloud-backed, it uploads every frame, all the time, even when nobody is watching — a constant 4–8 Mbps over Wi-Fi or cellular that warms the modem and the SoC simultaneously. This is one of the architectural costs of cloud cameras that nobody quotes upfront. Your camera-phone runs warmer because it's continuously funding the cloud company's broker function. The heat in Layer 1 that traced back to the radio? This is usually its source.

There's a full walkthrough of the local-only setup — same end state, much cooler phone — in The Most Privacy-Respecting Way to Use an Old Android Phone as a Home Security Camera.

Layer 5: Is the phone actually safe?

"Hot" and "unsafe" are different things, and modern Android phones manage the gap for you. The OS will throttle the CPU, drop camera resolution, or pause recording outright before any hardware-damage threshold. If you ever see "Camera is too hot, please wait," that's not a failure — that's the system protecting itself exactly as designed.

The one component worth respecting is the lithium battery. Sustained surface temperatures above ~45°C shorten battery lifespan over months. Three practical moves:

Take the case off. Cases trap heat against the back glass where the SoC sits.
Use a hard surface. Beds and couches insulate; a desk or shelf dissipates.
If it's a dedicated, always-plugged-in camera-phone, stop worrying about battery health entirely. A phone that never battery-cycles (held near 100% indefinitely) degrades far less than a daily-driver, and heat only meaningfully ages a battery that's also discharging.

The architectural shortcut

If you'd rather skip the ladder, the underlying lever is simple: pick an app that's structurally efficient, not one that merely promises to be. Local-only, no cloud upload, foreground-service-only, defaulting to 1080p/30/H.264 on old hardware. That architecture minimizes thermal load by design — Layers 2, 3, and 4 all resolve at once.

Background Camera RemoteStream is built that way — full disclosure, I made it. Free, no account, no cloud: play.google.com/store/apps/details?id=com.superfunicular.digicam. And if you want a deeper look at the background-recording machinery that keeps it efficient with the screen off, the Camera2 internals are written up in Camera2 API: Handling Orientation, Focus, and Exposure in Background.

The TL;DR, restated: a camera-phone that's warm but steady is doing its job. A camera-phone hot enough to alarm you is reporting an architectural problem — almost always the encoder profile or the cloud-upload load. Fix the architecture, and the heat fixes itself.

Architectural addendum — building this in public, late May 2026

A note on how this app and these write-ups actually get made, because it's relevant to the "structurally efficient by design" claim above.

Background Camera RemoteStream was built across 75+ AI-assisted development sessions, and the tooling underneath that workflow keeps shifting. On May 28, 2026, Anthropic released Claude Opus 4.8 — a model update 9to5Mac covered the same day — alongside a Claude Code research-preview feature called dynamic workflows, which lets one orchestrator session spawn many parallel subagents, each with its own context window, and aggregate the results. Simon Willison's hands-on writeup called the model itself "a modest but tangible improvement."

Why mention it in a thermal-diagnostics post? Because the same discipline applies to both. A dynamic-workflow orchestrator that fans out hundreds of subagents is making the exact trade-off this article is about: parallel work is faster but more expensive to coordinate, just as a continuous foreground service is steadier-but-warmer than an intermittent wake-loop is cooler-but-fragile — except the wake-loop isn't actually cooler, because the coordination cost dominates. Efficient systems, whether they're camera services or agent fleets, win by minimizing wasteful restarts and choosing the right sustained primitive, not by looking busy. The phone that runs one steady service beats the phone that wakes up a hundred times an hour, and it's the same lesson at both scales.

I'll fold the concrete development-velocity numbers from this tooling shift into the Week-5 build-in-public recap. For now, the timestamp matters: this is the toolchain the app was being maintained on as of late May 2026.

Cross-links for further reading

Why Does My Android Camera Stop Recording When the Screen Turns Off? Doze, WorkManager, and the Right Way to Build a Foreground Service — the OS-level reasons behind Layer 2.
Turn Your Old Android Phone Into a Free Security Camera — No Subscription Required (Updated May 2026) — the full setup if you're starting from scratch.
The Most Privacy-Respecting Way to Use an Old Android Phone as a Home Security Camera — the local-only architecture that resolves Layer 4.

Background Camera RemoteStream is a free, privacy-first Android app by Super Funicular LLC. Record with the screen off, stream to a browser over your own Wi-Fi, no account and no cloud. Get it on Google Play.

How Do I Check if My Android Baby Monitor App Is Sending Data Somewhere Else? A 5-Step Diagnostic Ladder

Super Funicular — Thu, 04 Jun 2026 07:07:23 +0000

Originally answered on Quora, May 28 2026. Expanded here with the full diagnostic ladder, the 2026 breach-and-pricing context that keeps making people ask this question, and the architectural reason some camera apps can't pass the test no matter how their listing reads.

TL;DR

You do not need a packet sniffer for 80% of this. Android ships three diagnostic surfaces — the per-app data-usage view, the Privacy Dashboard, and the system DNS log — that, used together, tell you exactly which baby-monitor apps are quietly phoning home and which ones aren't. Add a 2-minute Play Store Data Safety read and an optional evening with a packet capture, and you have a five-step ladder from "anybody, twenty seconds" to "definitive, slightly nerdier." Doing the first two steps usually settles it. The apps that fail this test fail it because the data-flow has to physically happen — and Android records that it happened, then lets you see the record.

If you've ever set a "free" baby-monitor app on a nightstand and then wondered, at 3 a.m., whether the thing watching your kid is also watching you — this is the article that answers it with steps, not vibes.

The good news is that you are not at the mercy of the marketing copy. An app's Play Store description can say "no ads, no tracking, private" all it wants; what the app actually does on the network is observable from settings screens that ship on every modern Android phone. Below is the ladder. You don't have to climb all of it. Most people get a clear answer from the first two rungs.

Step 1 — Open the data-usage view (30 seconds)

Settings → Apps → [your baby-monitor app] → App data usage (sometimes labeled "Mobile data & Wi-Fi" or just "Data usage"). You're reading two numbers: Foreground data and Background data.

A camera app that records locally to your phone and streams to a browser on your own LAN should use essentially zero background data. The streaming traffic stays inside your house — it doesn't touch your cellular bill, and it doesn't cross your home router's WAN port. So if your "free" baby-monitor app is burning 50 MB, 100 MB, or 500 MB of background data per day, that data is leaving your home. This is the single cleanest signal of cloud-backed monitoring.

For reference: I've watched apps in the wild log 200 MB of background data per day on an idle phone. That is not "checking for updates." That is continuous low-bitrate upload.

If this number is near-zero, you can often stop here. If it isn't, keep going — the next steps tell you where the data is going.

Step 2 — Open the Privacy Dashboard (5 minutes)

Settings → Privacy → Privacy Dashboard (Android 12+; on Samsung it's "Permission usage"). This is a timeline of every camera, microphone, and location access in the last 24 hours, stamped with the time it happened.

Three patterns are the ones you're hunting for:

Your monitor app touching the camera for 3 seconds at 4:17 a.m. when nobody was using it.
Your monitor app reading location every 15 minutes while it sits in the background.
A second app — a "system update helper," a "social companion," a launcher add-on — holding the camera in parallel with your monitor app.

Any one of those is the signal you came for. A legitimate monitor app's camera-access timeline tracks your actual use. A data-monetized app's timeline shows the regular, short, just-enough-to-keep-the-pipe-warm shape — access events that exist to keep a session alive or to sample for "AI sound detection," not because you asked for anything.

Step 3 — Read the Private DNS log (15 minutes)

This is the surface most people don't know exists, and it's the one that turns "I think it's phoning home" into "here is the domain it phoned."

If your phone is on Android 9+ and you've turned on Private DNS (Settings → Network & internet → Private DNS → Automatic, or pick dns.google, one.one.one.one, or dns.adguard.com), the system resolves every domain through a logged resolver. The lowest-effort version: switch Private DNS to dns.adguard.com for a day, then open AdGuard's dashboard at the end. You get a per-app list of every domain the app contacted.

For a local-only baby monitor, what you want to see is nothing — or, at most, one connection to the app's update-check endpoint every few days.

What you do not want to see is a list like *.alibaba.com, *.aliyun.com, *.alipay.com, *.tencent.com, *.qq.com, *.bdimg.com, *.amazonaws.com (when the app never told you it uses AWS), *.appsflyer.com, *.adjust.com, *.branch.io, *.kochava.com, *.singular.net, *.tenjin.io, *.facebook.com (in an app with no social feature), or *.googleadservices.com (in an app that advertises "no ads"). Each of those is the app reaching out to advertising infrastructure, attribution networks, or — in the case of the Alibaba/Tencent endpoints — the kind of vendor backend that was the architecture behind the Meari breach in May 2026, which exposed 1.1 million baby monitors across 378 vendor brands through a single hard-coded key.

If an app is touching ad-tech or attribution endpoints while its Play Store listing promises "no ads, no tracking," that's not a misunderstanding. That's the architecture telling you what the marketing copy left out.

Step 4 — Cross-check Data Safety on the Play Store (2 minutes)

Open the app's Play Store listing and scroll to the Data safety section. Google requires every developer to declare what data the app collects and shares. Two flags matter most:

"Data shared with third parties" — if this is populated for a baby-monitor app, the app is, by its own declaration, sending video, audio, location, device ID, or analytics to companies other than the maker. That is the publisher telling you, in writing, that the data goes elsewhere.
"Data this app may collect" — read it carefully. "Approximate location" and "Device or other IDs" are common and not automatically alarming. But "Precise location," "Photos and videos," "Audio recordings," and "Contacts" inside a baby-monitor app are warnings.

The declaration you want to see reads something like: "No data shared with third parties / only Camera, Microphone, and Network are used, and none of it leaves your device." That's the kind of declaration my own app makes. Background Camera RemoteStream is the camera app I build: free, no account, no cloud, records continuously with the screen off, and streams to any browser on your home Wi-Fi through an embedded web server. Source-of-truth Play Store link: https://play.google.com/store/apps/details?id=com.superfunicular.digicam&utm_source=devto&utm_medium=article&utm_campaign=2026w23

Step 5 — Pull the packets (1 evening; only if Steps 1–4 disagree)

This is the definitive answer, and you almost never need it. Set up a Wi-Fi hotspot on a second device. Connect the phone running the suspect app to that hotspot. Run Wireshark on the hotspot device with a capture filter for the phone's IP. Let the camera run for an hour, then read the capture.

You're looking for the same domains Step 3 surfaced — but now with the payload size attached. If the app is uploading frames, you'll see consistent multi-megabyte TLS sessions to a single cloud endpoint every few minutes. If the app is upload-free, you'll see only DNS resolves, periodic NTP, and OS-level update traffic. The packet capture is what settles the ambiguous cases — including the ones where the app authors are sophisticated enough to hide their endpoints behind a CDN that looks innocent. A $30 Wi-Fi dongle on a Raspberry Pi is enough hardware to do it well.

What the answers come back to

Climb as far as you need to, then read the result:

If Steps 1–4 say the app sends nothing, you're fine. The architecture matches the marketing.
If they say the app sends data to a single cloud the app discloses in its Data Safety panel, you're in the "trust the cloud vendor" case. Before you settle there, re-read what the Meari breach actually was: 1.1 million cameras across 378 brands, one hard-coded key, "view any feed." You may decide your trust is well placed. You may not.
If they say the app sends data to ad-tech endpoints, attribution networks, or backends not disclosed on the Data Safety panel, the app is monetizing your video — either by selling derived data or by selling raw frames. Either way, the architecture is misaligned with what you wanted from a baby monitor.

Why this question keeps getting asked in waves

People don't ask "is my monitor app phoning home?" in a vacuum. They ask it after something in the news makes the abstract worry concrete. In 2026 the prompts have stacked up fast: the Meari breach in May (1.1M cameras, one key); the Texas Attorney General's suit against Netflix alleging deceptive "we don't collect anything" claims; the Texas investigation into Meta over data practices; and a steady subscription-shrinkage wave from the camera vendors themselves — AlfredCamera's 2026 free-tier squeeze down to two cameras and watermarked, 24-hour clips; Arlo Secure's jump from $4.99 to $7.99 (per Tom's Guide); Eufy's creeping per-camera cloud fees. Each headline sends another batch of people to the settings screens above, asking the same structural question.

And the structural answer is always the same. It's the Cloud-Bill Theory of Free Camera Apps: an app that runs your camera 24/7 has a real bandwidth and storage bill. Either the user pays it, or the data does. Apps in the second column will always be findable with the five steps above, because the data-flow is not optional — it has to physically happen, Android logs that it happened, and Android hands you the log.

The cleanest way to never have to run this audit on yourself is to use an app that has no server to call in the first place. Background Camera RemoteStream was built on exactly that brief: recordings stay on the phone, the live view is an embedded web server on your home Wi-Fi, there's no account and no signup, and there is no outbound data path because there's nothing on the other end of it. The full walkthrough of how a no-cloud camera app survives Android's background-killer — Doze, WorkManager, and a correctly-built foreground service — is in Why Does My Android Camera Stop Recording When the Screen Turns Off?.

Cross-links for further reading

Is My Baby Monitor App Watching Me Too? Six Signals That Tell You a Free Camera App Is Selling Your Data — the architectural companion to this diagnostic ladder.
Best Android Baby Monitor Apps — No Cloud, No Subscriptions (Updated May 2026) — the comparison-list version, with our app at #1.
Why Does My Android Camera Stop Recording When the Screen Turns Off? Doze, WorkManager, and the Right Way to Build a Foreground Service — the engineering behind a local-only design.
Can a Camera App on Your Old Android Phone Watch You Without You Knowing? A 5-Sign, 60-Second Self-Audit — the faster, no-tools version of this check.
Is It Possible to Use a Free Android Camera App Without Giving Up Your Privacy? The Architectural Fork Behind "Free" — the cloud-bill economics in full.

Background Camera RemoteStream — free, no account, no cloud. Record with the screen off, stream to any browser on your home Wi-Fi, keep everything local. Built in Kotlin with the Camera2 API and an embedded Ktor server over 75+ Claude Code sessions.

Get it on Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam&utm_source=devto&utm_medium=article&utm_campaign=2026w23

More at https://superfunicular.com

Android Just Patched an Actively-Exploited Zero-Day (CVE-2025-48595) — Patch Now, Then Shrink Your Attack Surface

Super Funicular — Wed, 03 Jun 2026 08:04:56 +0000

Google shipped the June 2026 Android Security Bulletin on June 1, and it patches a zero-day that was already being exploited before the fix landed. If you have an Android phone, the first thing to do is update. The second thing — the part nobody emails you about — is to look at how much of your life is sitting in the cloud, waiting to be scooped up the next time the OS itself gets popped.

This is not a "switch to our app and you'll be safe" post. An OS-level zero-day is not something any third-party app fixes. But there's an honest, useful question on the other side of "did you patch?": if a device does get compromised, how big is the blast radius? That part you can control.

TL;DR

Google's June 2026 update patches CVE-2025-48595, an actively-exploited elevation-of-privilege zero-day in the Android Framework, affecting Android 14, 15, 16, and 16 QPR2. (CyberInsider, official bulletin)
The most severe flaw fixed this month, CVE-2025-65018, is a critical Framework bug allowing remote privilege escalation with no user interaction — no link to click, no app to install.
Step 1: Patch. Check Settings → Security & privacy → System & updates for security patch level 2026-06-01 or 2026-06-05.
Step 2: Shrink your attack surface. Every cloud-connected app on your phone is a remote copy of your data that survives independently of your device. Local-only apps don't add to that pile.

What actually got patched

The headline vulnerability is CVE-2025-48595, an elevation-of-privilege (EoP) flaw in the Android Framework component. Google said there are "indications" it's under limited, targeted exploitation — the language Google typically uses when a bug is being used quietly against specific people rather than sprayed at everyone. It did not name who's behind it. (The "2025" in the CVE ID is just the year it was reserved; the patch is brand new.)

EoP flaws are rarely the whole attack. They're the stepping stone — the part of a chain that lets code that already got a foothold climb to "broader access to device resources than normally permitted." In plain terms: a foothold becomes control.

The scarier entry in this month's bulletin is CVE-2025-65018, rated critical, which Google says could allow remote elevation of privilege without any additional execution privileges or user interaction. The June update also closes several critical System-component bugs (CVE-2026-0043, CVE-2026-0097, CVE-2026-21352, CVE-2026-21353) and three critical Qualcomm closed-source issues (CVE-2025-47392, CVE-2026-25276, CVE-2026-25277).

Fixes ship at patch levels 2026-06-01 and 2026-06-05. Pixels get them first; Samsung, Motorola, Xiaomi, OnePlus, and the rest land on their own schedules.

Step 1: patch (genuinely, do this first)

Open Settings → Security & privacy → System & updates (wording varies by manufacturer).
Tap Security update and install anything offered.
Confirm your Android security patch level reads June 1, 2026 or later.
Keep Google Play Protect on, and don't sideload from sources you can't vouch for.

If your phone is too old to be receiving June 2026 patches, that's its own signal — an unpatched OS is the real exposure, and no app changes that.

Step 2: think about blast radius, not just the patch

Here's the part the bulletin coverage skips. Patching closes this hole. It does nothing about the next one, or the one being held privately right now. The defensive posture that actually compounds over time isn't "patch faster" — it's minimize what a compromise can reach.

A phone compromised by an EoP chain can read what's on the device. But the bigger prize is usually what the device gives it access to: the cloud accounts your apps stay logged into. A camera or recording app that uploads everything to a vendor's servers has created a second copy of your footage that lives on, fully indexed and searchable, regardless of what happens to your handset. That trove is exfiltratable from the device, and it's also exposed by every breach on the vendor's side — see the recurring pattern of camera-cloud incidents where one leaked key exposes hundreds of brands at once.

Local-only apps don't add to that pile. If recordings never leave the phone, there's no server-side archive to steal, no account to hijack, no vendor breach that reaches you.

Where Background Camera RemoteStream fits

Background Camera RemoteStream is built on exactly this principle, and it's worth being precise about what that does and doesn't buy you:

It does not protect you from CVE-2025-48595. Nothing in user space patches a Framework zero-day. Update your OS.
It does shrink blast radius. Recordings are stored locally on the device — no cloud, no account, no sign-up. There is no server-side copy of your footage to exfiltrate or to leak in someone else's breach.
It minimizes what's logged in. No account means there's no credential on the device for an attacker to ride into a cloud dashboard.
Live streaming, when you want it, goes through your own YouTube Live — your pipe, your account, not a third-party relay quietly holding your video.

This is the unglamorous version of "privacy-first": not a promise that you'll never be attacked, but a design that keeps the damage small when something upstream fails. A privacy policy is a promise. Local-only storage is an architecture that makes the promise unnecessary.

A 4-step checklist for today

Patch. Confirm security patch level 2026-06-01 / 2026-06-05.
Audit who phones home. Settings → Privacy → Privacy Dashboard shows which apps touched the camera and mic; Settings → Network → Data usage shows who's uploading in the background. Anything moving data while idle deserves a second look.
Prefer local-only and no-account apps for anything sensitive — cameras, recorders, notes — so a single device or vendor compromise doesn't hand over a cloud archive too.
Keep Play Protect on, and stop sideloading from sources you can't trust.

Patching is necessary. Reducing what's at stake when patching isn't enough is the part you own.

Further reading from our archive:

App: Background Camera RemoteStream on Google Play — local-only Android camera, no cloud, no account.
Web: superfunicular.com

Sources: CyberInsider — Android June 2026 update patches actively exploited zero-day (June 2, 2026); Android Security Bulletin — June 2026.