On May 11, the Texas Attorney General filed suit against Netflix. The complaint's core accusation, in plain English: Netflix has been quietly building advertising profiles from what users watch, pause, rewind, and search — including children — while telling the public it does not. The lawsuit specifically cites Reed Hastings's 2020 statement that Netflix "doesn't collect anything" and points to the company's pivot to ad-tech as evidence the public was misled. Coverage: Time, CNBC, Variety, Malwarebytes.
I'm not writing this to dunk on Netflix. I'm writing it because the lawsuit names the exact structural failure mode I tried to design my way out of when I built Background Camera RemoteStream.
The architectural diagnosis hiding inside this lawsuit
Cloud-by-default products collect by default. That isn't a policy choice that can be paper-over with a privacy page — it's a property of the architecture. The moment a stream of user behavior crosses the network to a vendor-owned server, three things become technically inevitable: the data exists somewhere outside the user's control, it can be joined with other data on that server, and it can be repackaged for advertising whenever the business model demands it.
The Texas complaint reads like an architecture review. It says Netflix tracks "viewing activity, searches, location data, pauses, rewinds, and other behavior" to build profiles "shared across the broader ad-tech ecosystem." Note what is missing from that sentence: any specific malicious decision by an engineer. Each of those signals is generated as a side effect of running a streaming product whose backend has to know what the player is doing in order to keep playing it. Once they're on a server, they're collected, whether or not anyone intended to collect them in the consumer-protection sense. Opt-out flows are a UI fiction layered on top of that fact.
This is the trap I wanted to avoid for a camera app — because of all the categories of data on a phone, "what does the camera see and hear" is the worst possible thing to architect around a cloud.
Why I made the design call to keep everything local
Background Camera RemoteStream is a background-recording, screen-off-streaming Android camera. It records when the phone is locked, streams to a local network or to YouTube Live, and never asks for a cloud account.
The architecture is deliberately uncomfortable for any future business model that depends on selling user behavior:
- No account system. The app does not have a sign-up flow. There is no userId for analytics to key off of, because there are no users in the database sense — there is only a phone, holding a file.
- No cloud storage. Every recorded clip is written to the device. The app does not upload, mirror, or sync. If you uninstall it, your footage is wherever Android's MediaStore put it.
- No third-party analytics SDK. Most "free" apps fund themselves by sending behavior to Firebase, Mixpanel, Amplitude, AppsFlyer, or some combination. We don't. There is no analytics endpoint to disable, because there is no analytics endpoint.
- Streaming is peer-to-peer. When the app streams over the local network it serves frames directly from an embedded Ktor server on the phone — so the receiver is a browser on your laptop, not a relay in our datacenter. When it streams to YouTube Live, the frames go to YouTube; they do not pass through a Super Funicular intermediary.
- The crash logs are sparse and on-device. Diagnostic info that exists at all is what Android's stock crash mechanism keeps locally. We don't ship telemetry off the phone.
Some of these are not "best practice" by any 2020s indie-dev playbook. The conventional wisdom is "you can't grow without analytics." But the moment you accept analytics, you accept a server that knows what users do. And the moment you have a server that knows what users do, you have written the first line of a complaint a state AG can file against you in 2030.
What the Texas lawsuit makes easier to say
I have been pitching the local-only architecture for almost a year, and the most common reaction from non-technical users is some version of "surely they all do that?" — "all" being the cloud cameras, the smart doorbells, the social streaming apps. There has been a quiet consumer assumption that the collection is fine, because the brand on the box is trustworthy.
The Texas filing is going to make that assumption harder to hold. The lawsuit is not against an obscure ad-tech company; it's against the household-name streaming service whose CEO publicly said it didn't do this. The complaint alleges $10,000-per-violation penalties under the Texas Deceptive Trade Practices Act and asks the court to require Netflix to delete data and disable autoplay for children's accounts by default.
For builders, the message embedded in that filing is simple: the privacy promises you make on the marketing page are now legally interesting. If you say you don't collect, your architecture had better not collect. If your architecture collects, the marketing-page promise is the lawsuit-ready evidence the AG will cite.
The way out of that exposure is not a better privacy policy. It is to not be able to collect the thing in the first place — to put it on the device, leave it on the device, and stay out of the network path. You cannot be subpoenaed for what you don't have.
What I'd tell another indie builder
Pick one piece of user data your product touches and ask: if this ever gets cited in a complaint, what would I want my architecture to look like? That's the design constraint. Then work backwards from it. Most apps can't take this all the way to "no cloud" because they need server-side features, but almost every app can reduce its collection surface meaningfully. The local-only choice I made for camera footage is the strictest version, available because cameras are a category where the phone is genuinely capable of doing the whole job.
I built the app on this thesis. The Texas lawsuit reads, to me, like a 65-page validation of it.
If you want to see what a privacy-first Android camera looks like when the architecture matches the marketing, Background Camera RemoteStream is free on Google Play — and the project's home is at superfunicular.com.
Coverage cited: Texas AG press release, Time, Variety, CNBC, Malwarebytes.
Top comments (0)