Secret Searches
Not all audit data is created equal. Some agencies release complete records; others redact key information. Here's how to understand what you're seeing.
When you search for a license plate on haveibeenflocked.com, you might notice some records have complete information—the operator’s name, the reason for the search, the case number—while others show placeholder text or black boxes.
You may also have noticed what appear to be duplicate searches, or higher numbers of searches than you might expect. This isn’t a bug. It’s a reflection of the accuracy of the logs, and of how different agencies handle their audit data before releasing it.
This post explains why information is missing, how we handle duplicates, and how to interpret what you see. For agency-specific details, check the source statistics page.
Why Is Information Missing?
There are two distinct reasons you might see incomplete data: source redactions, where agencies redact information before its release, or redactions by the haveibeenflocked.com website. This post discusses the former; for details on the latter, see the “about redaction” page.
Source Redactions: Flock
Flock audit logs are partially redacted or obscured by default. Full names of operators are included only in “organizational audit logs.” Those are only accessible to the operator’s agency. Names of operators from other agencies searching the data are obscured; the “network audit log” only shows abbreviated names like “J. Smi.”
Sometimes the “Smi” in “J. Smi” is a middle name, sometimes it isn’t. Sometimes it’s “S. Joh.” Some agencies are staffed entirely by mononymic "a"s and "j"s who appear to be on the clock 24/7. Others are staffed by people like “B. 478” who do a lot of “inv” work.
Whether this is a deliberate choice because agencies don’t trust each other with their employees’ names, a way to create a degree of plausible deniability, or simply a terrible technical design choice is unclear. What is clear is that none of Flock’s customers appear to consider it an issue that there is no way to determine who the “a” or “b” is that’s looking up location histories. They find that “inv” is a good enough reason to disclose detailed location histories, regardless of “a”'s identity.
In transparency portals, Flock goes even further. By default, it omits operator names, case numbers, search timeframes, search types, filters, and text prompts. There is no way to tell whether your local agency is doing convoy analysis, whether it’s pulling long-term location histories based on bumper stickers, or whether it’s looking for people wearing a red shirt.
Flock and its customers consider this lack of transparency a feature; one the company recently expanded because “the burden of compliance shouldn’t stand in the way of public safety.”
Source Redactions: Agencies
When agencies address city councils or the public in general, invariably there are no privacy concerns in relation to bulk collection and sharing of license plates. Flock also claims not to handle PII, a false statement that agencies are happy to parrot. Agencies have no issue with shipping all of this information overseas, placing it in a system with gaping security holes, or even with Flock publishing details on murder investigations, including the victim’s Gmail password.
When a citizen requests that same data, however, it tends to be confidential. In those instances where audit logs are disclosed, they are often disclosed with the columns for “sensitive information” (like license plates), PII (like operator names), and criminal justice information (like search reasons and case numbers) removed.
It leaves a log that, at best, informs you that someone did something at some time for some reason.
This is what oversight and transparency looks like to police.
Working With Duplicate Information
This is the ideal scenario. Agency A releases a network audit for the month of August, and it perfectly matches the audit released by Agency B. This happens sometimes.
Whenever we import a record, we create a fingerprint for that record[1]. If a future import generates the same fingerprint, we don’t store the record again, only the fact that it’s available from more than source. Whenever you see “2(+) sources” in a result, that’s what happened.
For every search of the national network, you would expect that search to show up in every participating agency’s network.
That’s what Flock claims, and that’s what haveibeenflocked’s system was designed to accommodate.
As it turns out, that was an overly optimistic design choice.
Selecting June 2025 as an example:
- There are 1,907,643 unique searches/fingerprints for that month[2]
- We have multiple sources that cover that month.
- The most records in a single source is 382,998.
This means that either:
- No single source shows all the searches on the national network.
- Sources show different information about the same searches.
Both appear to be true.
Missing Information
When a search record for a national search is completely missing, it either means that the “national” search wasn’t actually national (which may lead to false negatives in investigations), or not all searches are logged.
While philosophically we may struggle to reconcile this with the idea of responsible use of the system, technically it is easy to deal with: we simply detect the unique fingerprint and add the record as a search. B.'s your uncle.
But partial records are where it gets trickier. Because our fingerprint is based on the exact text of the record, changing even one letter changes the fingerprint. This is the technically sound way to treat audit records: any tampering is guaranteed to be immediately evident.
But, when Agency A reports a search with the reason “Investigation,” and Agency B redacts that reason to “Inv” or blanks it out completely, our system sees two mathematically distinct fingerprints. It treats them as two separate searches, even though they likely represent the same event.
Contradictory Information
At the same time, we regularly see searches that are logged differently between different organizations.
These variations and irregularities range from small changes in organization names (“University of Iowa PD IA” vs. “University of Iowa (IA) PD”), to completely different organizations or operators.
It’s critical to understand that this is the same data Flock and its customers claim is permanent, immutable and provides the information suitable to perform audits. It’s the exact same information your local police department uses for its audits, and the exact same information available to third party auditors (if such a thing exists).
If Flock used a system to prevent tampering and guarantee their authenticity, something which is standard when dealing with secure audit logs, even small variations in logs would not be possible.
Those types of systems are standard. Literally. ISO 27001 and SOC 2—both standards Flock claims it complies with—require audit logs to be protected against tampering to ensure integrity and accuracy.[3]
The logical conclusion, that Flock’s lack of controls permits data errors, deliberate obfuscations, technical issues, or conversion problems, is off the table. Flock and police have told thousands of elected officials across the country, as well as the general public, that these audit logs are a complete and reliable method for oversight and accountability, and that they fully comply with ISO 27001 and SOC 2.
Because HIBF can’t audit Flock’s systems to show otherwise, and agencies tasked with oversight don’t, we have to assume that Flock and police are not lying to the public about these records, or falsely purporting them to be more accurate or fit for purpose than they actually are.
So, as contradictory as it might appear to you and me, if Flock says that the exact same plate was searched for by two different people, working for two different agencies, in two different states, using the exact same case number, the evidence we have forces us to conclude that’s what happened.
The Choice
So then, how do we handle this? This is a choice.
We can:
- Discard the record entirely.
- Try to figure out if it’s a duplicate, based on available information—a task that is already virtually impossible even without redactions due to the unreliability of the data.
- Assume that the information shows what the agency purports it to show: someone did something at some time for some reason.
There are arguments to be made for each option.
To maximize the utility of available data—even when those data are limited—we rejected option 1.
To minimize the chance of introducing additional errors, we did not select option 2.
Leaving option 3: present the data as-is, treating it as a new search because it could be.
The Problem
The problem with that choice is that it can, and does, lead to both over- and underreporting.
But redacted data is still valuable. Even when agencies hide operator names or reasons, the record proves that surveillance occurred—a specific vehicle was searched at a specific time by a specific organization.
When a license plate is hidden, we may not see stalking, but the reason may indicate improper access. When a case number is missing, we know the agency is uninterested in relating searches to legitimate investigations.
Agencies committed to transparency would not stand for Flock’s baked-in redactions, but would also disclose the remainder.
The Solution
We preserve and display what’s available while being transparent about gaps and limitations.
Check the source statistics page to see which agencies provide complete data and which choose to redact key fields.
Without complete information, haveibeenflocked or its users will be inclined to infer the missing data.
We strongly encourage agencies to tell their side of the story by disclosing complete records.
Technically, an MD5 hash of the complete record. ↩︎
Based on >50,000 devices searched. ↩︎
ISO27k1 control A.12.4.2 in ISO27001 (“Logging facilities and log information shall be protected against tampering and unauthorized access.”); SOC.2 CC7.2 (Processing Integrity) (“must implement controls to ensure the completeness, accuracy, and validity of data.”) ↩︎