The Electronic Frontier Foundation documented the audit-log problem in records obtained through public-records requests, while 404 Media first reported the entries and later partnered with Wired on the camera examination. The reporting shows a surveillance product marketed as a searchable investigative tool whose accountability features could be bypassed by careless data entry—and whose physical device security, according to the joint Wired and 404 Media investigation, did not prevent recovery of a substantial local media cache.
Those are separate findings, and they should not be blurred together. The first concerns how authorized police users searched a national database. The second involved hackers physically removing a roadside camera, accessing its Android-based system, and analyzing its storage. But both expose the risk in treating check-box oversight and encryption claims as substitutes for controls that can actually withstand misuse.
Audit logs recorded a system that was not being meaningfully audited
EFF’s analysis includes a July 2025 Lake County, Indiana, search across more than 19,000 cameras in 1,558 cities and towns with “LMAO” listed as the reason. In another case, a Goshen, Indiana, officer searched systems representing data from 82,413 cameras with “idk” entered in the field intended to explain the query.
Other records included “Hehe,” “Haha,” “blah,” “TBD,” “WEIRD KID,” insults, and strings of keyboard characters. A Pasco, Washington, search entry read, “robbery i don’t remember the case number leave me alone.” The language is eye-catching, but the scale is the material issue: EFF found more than 30 agencies conducting over 6,300 searches marked “TBD,” including nearly 2,000 such entries from one Alabama police department.
A free-text rationale box was never a strong privacy control by itself. It could create a useful audit record if a supervisor reviewed entries against a case record, if the platform retained immutable logs, and if improper searches produced real consequences. The records instead suggest that the field often functioned as friction users could dismiss with filler text.
Departments’ responses reinforce that conclusion. Richmond Police Department said officers associated with “Hehe” and “idk” searches were counseled, according to EFF. Columbus Police Department said its inspector general lacked authority to investigate a 2023 “idiot” entry because the relevant 90-day period had elapsed. Fishers Police Department defended an officer’s use of “blah” as a response to slow technology and said the officer had been told to use “test” in the future.
None of those explanations establishes that the underlying searches were unlawful or unrelated to cases. A poor log entry is evidence of failed documentation, not automatic proof of a bad-faith search. Yet that distinction does not rescue the control: when an agency cannot connect a search to a defensible purpose from its own records, the audit mechanism has already failed its job.
Flock replaced visible nonsense with a less transparent menu
The timing matters. The questionable entries highlighted by EFF span 2023 through late 2025, when Flock changed its search workflow. Instead of requiring officers to type an explanation, the company moved to a pre-populated dropdown list of offense categories.
Flock describes the newer process as a way to improve search-reason compliance. EFF argues that the change makes audit records less useful because a user can select a broad category such as a traffic infraction or “Other” without stating the actual reason a person’s movements are being searched.
Both statements can be true. Structured fields improve consistency and prevent obvious garbage entries; anyone who has administered ticketing, incident-response, or SIEM workflows knows why organizations use controlled values. But a dropdown does not establish that the selected value is accurate. It shifts the question from “did the officer enter gibberish?” to “was the category supported by a specific case, authorization, and search scope?”
For an enterprise security team, this is a familiar design failure. A mandatory field measures completion, not legitimacy. A reliable audit system must link the action to a unique case or incident identifier; record the user, time, query criteria, result scope, and approval context; prevent retrospective alteration; and flag searches that lack a valid relationship to an active investigation. Supervisory review must be routine rather than triggered only after journalists or civil-liberties groups obtain logs.
Flock’s network complicates the governance burden because a query may reach cameras beyond the agency that owns the local equipment. Wired reported that records from Alpharetta, Georgia, cameras were accessible to more than 2,000 entities, including police agencies, colleges, airports, and a federal inspector general’s office. In that model, local deployment rules mean little if external access rights and national searches are not subject to comparable oversight.
The camera finding is a physical-security failure, not a remote compromise
The second development deserves precision. Wired and 404 Media reported that a collective calling itself stegan0gram physically removed a Flock camera from a roadway, copied storage from the device, and recovered an encryption key stored in an accessible partition. The reporting does not establish a remote breach of Flock’s cloud environment, nor does it show the group accessed the most sensitive encrypted partitions.
It does show why “encrypted on device” is an incomplete assurance. Encryption protects data only when the keys are protected separately from the content they unlock. If an attacker with physical possession can retrieve both the protected media and the key material from the same device, the encryption boundary has failed for that threat model.
According to the joint investigation, the camera runs Android and roughly 20 Flock-built applications for image capture, motion detection, classification, cellular upload, and remote updates. The researchers found unencrypted partitions including one labeled “media,” which reportedly contained a key capable of unlocking a partition holding captured material.
The recovered files included 27,321 short MP4 clips and logs covering roughly 21 days across several periods. Those logs indicated approximately 1.6 million images of about 50,200 vehicles. Wired reported that a typical passing vehicle caused the system to take around 28 images, with some vehicles generating more than 100. The device also included models that detected people, bicycles, vehicles, and plate-like objects, although the journalists found no evidence that face-recognition capabilities available in the underlying Android software were enabled or used by Flock.
This is more consequential than a camera retaining a few frames during upload retries. The volume described by Wired and 404 Media indicates that a single roadside unit could retain a detailed record of movement around its location for weeks, even though Flock previously said images stayed on devices only briefly after cloud transmission. Older records may have been overwritten, so the recovered period should not be treated as a complete history of the camera’s operation.
Flock told Wired that unauthorized removal and tampering of its cameras is illegal. Asked specifically about the on-device encryption key, the company said it did not have enough detail to assess the claims and urged researchers to use its vulnerability-disclosure process. That response leaves a central question unanswered: whether Flock has confirmed the key’s purpose, identified affected device generations, or issued a remediation plan for deployed hardware.
The practical lesson is about design assumptions
For organizations operating any connected camera, access-control appliance, or edge AI sensor, the Flock reporting offers a straightforward checklist of failure modes. The product need not be compromised over the internet for its security model to break; physical access remains part of the threat model for equipment mounted in public or semi-public spaces.
The first priority is cryptographic key isolation. Keys should be protected with hardware-backed storage where possible, tied to a device identity, and designed so that extracting flash storage does not provide reusable material for decrypting recorded content. Media retention should be enforced and verifiable, with encrypted deletion and auditable proof that locally buffered footage expires as documented.
The second is audit integrity. Systems handling sensitive location, video, or identity data need more than a required text box or dropdown. They need case-linked authorization, immutable event logging, anomaly detection, periodic review by people outside the immediate user group, and sanctions that are timely enough to matter.
Finally, purchasers should ask vendors to distinguish plainly between encryption in transit, encryption at rest, and protection against a device being stolen or dismantled. Those are different claims. A vendor can honestly encrypt data on a camera and still leave the data recoverable if the decryption material travels with it.
Flock’s audit logs showed how weak oversight can turn a nationwide surveillance query into a casual search. The recovered camera data shows why physical possession of an edge device can be enough to turn “on-device encryption” into an empty assurance. Any agency or company deploying these systems now has a concrete question to answer: can it prove who searched the data, why they searched it, and whether a stolen camera can reveal what it recorded?