IPVM frames the pattern as a structural argument for warrant requirements rather than a one-off scandal. The investigation emphasizes that chiefs were caught only because Flock's audit logs recorded the queries — the system never refused them, because it was built to honor any credentialed query without prior authorization.
Argues the IPVM report reads like a software postmortem: the chief had credentials, the credentials had access, the system honored the query. The absence of any technical control that would have prevented the searches — only after-the-fact audit logs — is the real story for engineers building surveillance infrastructure.
The headline itself — 'Why Warrants Are Needed' — makes the policy claim explicit. IPVM argues that audit-log-only accountability is insufficient when the queries themselves cause the harm; only a prior-authorization requirement (a warrant) can prevent credentialed insiders from weaponizing the network against private individuals.
By posting the IPVM report to HN where it climbed to 441 points, the submitter (IPVM's own founder) elevated the engineering framing of the abuse — that a centralized, lightly-gated plate-query system will inevitably be misused — into a top-of-front-page technical discussion rather than a local crime-blotter story.
IPVM, the surveillance-industry research outlet, published a deep investigation into how police chiefs across the United States have used Flock Safety's automatic license plate reader (ALPR) network to track women — ex-wives, current girlfriends, women they were sexually involved with, and in at least one case a woman who had filed a restraining order against the chief himself. The pattern is consistent enough that IPVM titled the piece as a structural argument for warrant requirements rather than a one-off scandal story. The report hit 441 on Hacker News, where the top comments converged on a familiar engineering observation: the system worked exactly as designed.
Flock operates one of the largest private surveillance networks in the country. Public reporting puts the company at over 5,000 communities served and roughly 40,000 cameras, with a national hot-list and search interface that lets any participating department query plates seen across the entire network. The investigation documents chiefs in multiple states — including cases in Kansas, Florida, and elsewhere — running searches against the women's plates, sometimes dozens of times, sometimes labeling the query with a fabricated case number, sometimes leaving the 'reason' field as boilerplate. The searches show up in Flock's audit logs because Flock built audit logs; they were caught because the system recorded what it was being used for, not because it refused to do it.
The responses from the implicated departments follow a script. Internal affairs review, suspension, sometimes resignation, occasionally a criminal referral. What is conspicuously absent in nearly every case is any technical control that would have prevented the search in the first place. The chief had credentials. The credentials had access. The system honored the query.
If you build software for a living, the IPVM report reads less like a privacy story and more like a postmortem. Flock's query interface treats 'official law enforcement use' as a self-attested checkbox — the same trust model as a SaaS admin panel that asks 'are you sure?' before letting an authenticated user nuke production. There is no judicial gate, no two-person rule, no anomaly detection on a single officer running the same plate forty times in a week, no rate-limiting on personal-relationship-shaped query patterns. The platform's defense, when pressed, is that it provides audit logs and leaves enforcement to the customer. This is the surveillance-tech equivalent of shipping a database with no row-level security and telling customers to handle authorization in the application layer.
The Hacker News thread, predictably, split between two camps that are both correct. The first camp pointed out that this is a policy failure: police should need warrants to run ALPR queries against specific individuals, full stop, and the fact that they don't is a Fourth Amendment problem Congress and the courts have been ducking for a decade. The second camp pointed out that this is an architecture failure: even if you accept the premise that cops should be able to run ALPR searches, the system has no meaningful technical controls distinguishing 'investigating a stolen vehicle' from 'checking where my ex slept last night.' Both groups want the same fix from different directions — a warrant requirement is, functionally, a mandatory authorization step backed by an independent reviewer, which is exactly what the system lacks today.
There is a useful comparison to the face-recognition story that hit HN at 542 points yesterday under a similar thesis: your face is a primary key you can't rotate. Your license plate is also a primary key you can't rotate, and unlike your face, it broadcasts itself at 60mph past every Flock camera on your commute. Clearview hoovered up 50 billion faces; Flock's network is doing the same thing with plates, with the additional twist that the customer base is law enforcement and the access logs are subpoenable but not preventive. The two stories together describe a surveillance stack where the identifiers are immutable, the collection is ambient, and the access control is honor-system.
The deeper engineering lesson is about the gap between observability and enforcement. Logs tell you what happened. Policy tells you what should happen. Controls are what make the gap small. Flock has logs and policy but has chosen not to ship controls — partly because controls would slow down legitimate queries, partly because the business case for selling to 5,000 departments depends on frictionless adoption, and partly because the company can credibly say 'we provided the audit trail, the abuser is the customer's problem.' That argument is going to age badly.
If you ship any internal tool that lets a privileged user query data about a non-privileged person — a customer support console, an admin dashboard, a fraud investigation portal, a healthcare records system, a logistics tracker — the Flock story is your threat model. The attacker is not an external hacker; the attacker is the authenticated insider with a personal motive, and the audit log is a forensic tool, not a prevention tool. If your design assumes that 'we'll catch misuse in the logs' is sufficient, you are building Flock.
The practical controls are not exotic. Require a justification string that is structured, not free-text, and validate it against a case management system. Sample audit logs in near-real time and flag patterns: repeated queries on the same subject, queries on subjects who share an address with the querying user, queries outside the user's geographic jurisdiction. Implement two-person integrity for sensitive query classes — the second person can be async, can be a manager, can be automated against a list of approved investigations, but cannot be the same user. Rate-limit by subject, not just by user. Make personal-relationship discovery part of onboarding: ask new hires to declare conflicts, then refuse queries that match. None of this is novel; it's standard practice in financial services SAR systems and clinical EHR access. It is conspicuously absent from law enforcement surveillance platforms.
For anyone building B2B SaaS where the customer is the abuser's employer, the contract-law version of this is also worth thinking about. Flock's terms presumably push liability for misuse onto the department. That works until it doesn't — the women being stalked are now plaintiffs, and the discovery process is going to ask whether Flock could have prevented this and chose not to.
The IPVM report will almost certainly be cited in the next round of state-level ALPR legislation, and probably in at least one civil suit naming Flock as a co-defendant. The interesting question is whether the company ships preventive controls before the courts force it to, or whether it waits for the inevitable settlement and then ships them as a feature flag for premium tiers. Either way, the engineering takeaway is permanent: if your system can be used to stalk someone, it will be, and the audit log is evidence for the prosecution, not a substitute for a lock on the door.
Remember that scene from "Men in Black" where K watches surveillance video feed of his ex? In the movie it was meant to be wistful and cute, I guess. Now that such systems are getting closer to reality, you realize the potential for abuse in enormous.
This shouldn't be hard to understand. Don't talk to the police, without your attorney present, under any circumstances whatsoever.Dating the police is just such an astoundingly egregious violation of this principle that I can only wonder what, if anything, those people are thinking.Anyway,
Scott Adams' had a great line:"Whenever people have the opportunity to commit fraud and there is no monitoring, you can assume they are committing fraud."
Ultimately, there’s a sort of homeostasis in people’s tolerance for crime. If you need video evidence for prosecution, those who want it prosecuted will produce video cameras. If you make warrants impossible to produce in a timely manner, the camera search will be warrant exempted.Attempts to damage
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
No, it shows that we have a destructive, trust undermining security industry that sells abusive surveillance software that by spirit of the law would be clearly illegal in any country that pretends to be a free and open society and has a constitution in the direction.