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
Related reading: Android's June zero-day patch and shrinking your attack surface.
Top comments (0)