Full transcript
There's a camera sitting beside a road
somewhere near you right now that
doesn't care if you're speeding, doesn't
write tickets, and might not even be
recording actual video. But the moment
your car rolls past, it can read your
license plate, guess the make, model,
color, and body style, log the exact
time, location, and direction, fire that
data up over the cellular network, and
make the whole event searchable in just
seconds. One photo, not very exciting.
But link thousands of those cameras into
one database, and each photo becomes a
breadcrumb. Connect enough breadcrumbs
and you've got an interesting trail. And
that in a nutshell is the promise and
the controversy of flock safety cameras.
Police departments say these systems
help recover stolen vehicles, find
missing people, catch getaway cars, and
turn a vague gray SUV witness
description into real investigative
leads. Privacy advocates counter that
the same network quietly builds a
searchable record of where everyday
people drive without asking permission,
without probable cause, and without a
warrant. Today, I'm not here to cheer
for one side or dunk on the other.
Instead, I'm going to tear the
technology apart conceptually, following
the bits from the roadside into the
cloud, see what exactly the system
records, including what it doesn't know,
and examine the real benefits, the real
risks, the safeguards, the loopholes,
and the tough legal questions. Now, I
fancy myself something of a law-abiding
libertarian, which means I guess I think
there should be as few laws as are
necessary, but people should at least
follow the ones that we have. And that's
part of the problem with Flock cameras
because, as you'll see, the camera
itself is almost the least interesting
part. The best known Flock product is
the Falcon automated license plate
reader or ALPR. Physically, it is a
compact roadside camera that can be
installed without trenching in power or
network cabling. Many installations use
a solar panel for power and an LTE
cellular modem for connectivity, which
means a camera can be placed at a
subdivision entrance, an intersection, a
parking lot, or a rural road without
waiting for somebody to pull Ethernet
through the sewer system. Flock handles
much of the installation and operates
the system as a subscription service
rather than merely selling a camera in a
box. That architecture is one reason the
system is spread so quickly. Traditional
municipal camera projects become
miniature public works programs
involving poles, permits, power drops,
fiber, network closets, and a conference
room full of people debating who owns
the conduit. But a self-contained solar
and cellular node skips much of that.
It's essentially an internet of things
device with a badge nearby. And if you
can get power to it and it's in cell
range, that's all it needs.
Conceptually, the image processing
pipeline works much like any other
modern machine vision system. First, the
camera needs an exposure that freezes a
moving vehicle without turning the plate
into a white reflective rectangle. The
software then identifies a vehicle and
plate region within the frame, corrects
for angle and perspective, separates the
individual characters, performs optical
character recognition, and normalizes
the result into a candidate plate
number. At the same time, additional
computer vision models classify the rest
of the vehicle. Is it a sedan, a pickup,
an SUV, or what is it? Is it red, gray,
blue, or a color best described as
rental car beige? What manufacturer and
model does it most resemble? Are there
visible roof racks, bumper stickers,
damage, or other distinguishing
characteristics? Flock refers to this
collection of characteristics as a
vehicle signature, or a vehicle
fingerprint. Its current search tools
can use plate numbers, partial plates,
make, model, color, location, time, and
natural language descriptions such as a
white sports car with a racing stripe.
The company also advertises location
searches, convoy analysis, hot lists,
custom alerts, and real-time routing
tools. Now, it matters a lot to me
personally where the characterization is
actually done. If it's all happening on
the device using a entirely local model,
I'd be both impressed and relieved.
Impressed because that's a lot of AI
juice to squeeze for a little box like
this, and relieved because it would then
mean that the images of you in your car
never leave the box. If the block cannot
and does not store them and they can
never leave, I could give this thing a
pass. But there are just two problems.
First, the precise division of labor
between the processor inside the camera
and the software in Flux Cloud is an
implementation detail that is not
publicly documented deeply enough for us
to draw any reliable conclusions or make
even a block diagram. But in so far as I
can tell, every detection is forwarded
as both an image and a set of extended
metadata about that image. So, it's not
just recording the fact that your
license plate value is spotted on your
blue BMW a mile from your house. It's
also sending the image this time and
every time that it sees you. And that
database of images and metadata is where
the system stops being merely a camera
and starts becoming something more like
Google for cars. Suppose a convenience
store camera captures a gray SUV leaving
right after a robbery. The plate is
unreadable, but the vehicle has a roof
rack and damage to the left rear bumper.
An investigator can search nearby flock
cameras for gray SUVs matching those
characteristics during the relevant time
window. Instead of manually watching 6
hours of footage from 20 cameras, the
investigator gets a much smaller set of
candidate vehicles. Doesn't prove that
any of them was involved and it does
produce leads. If the plate number is
already known, the search becomes much
more direct. Enter the plate and the
system can return the points where the
participating cameras observe that plate
during the retention period. A single
camera tells you that the vehicle passed
one location at one time. Multiple
cameras can show a direction or a route.
More cameras produce a more complete
route. And this is the semantic fault
line running through the entire debate.
Flock describes its core ALPR product as
taking point-in time images of vehicles
on public roads rather than continuously
tracking people. And that is technically
accurate. There's no transmitter
attached to your axle and the Falcon
does not follow you home like a tiny
airborne probation officer. But critics
respond that querying many point in time
observations is still a form of
tracking. And that is also technically
accurate because just as a movie is
merely a sequence of still images, a
travel history is merely a sequence of
timestamp locations. The distinction
becomes less meaningful as camera
density or image frequency arises. For
those of you who took a little sequel in
college, think of it this way. The
individual records are not where the
power lives. The power lives in the join
across tables. The license plate reader
also operates as a real-time alerting
system. Police can subscribe to what are
commonly called hot lists. These may
include license plates associated with
stolen vehicles, wanted suspects, Amber
or Silver alerts, missing people, or
other active investigations.
Flock says it system integrates with
criminal justice databases such as the
National Crime Information Center. When
a matching plate passes a camera, the
system can notify officers or analysts
immediately. From a software
perspective, this is a classic publish
and subscribe system. The hot list
contains events of interest. The
roadside cameras publish vehicle
detections. The platform compares each
event against the subscriptions and
pushes an alert when there's a match.
And speed matters, not of the vehicle,
but of the report. A stolen vehicle
report that's checked manually tomorrow
is just an investigative record. But a
detection delivered to an officer 30
seconds after the car passes an
intersection can become an interception.
And an interception can end or prevent a
crime. Not in a minority report kind of
way, but in their there was actually a
cop there when I needed one way. Police
departments using these systems describe
them as valuable for recovering stolen
vehicles, locating missing or endangered
people, responding to crimes in
progress, corroborating timelines, and
identifying vehicles when witnesses can
provide only a partial description. Some
cities report successful recoveries and
arrests, although attributing a change
in overall crime rates specifically to
cameras is much harder than documenting
individual cases in which a detection
was actually useful. And that
distinction is important. A screwdriver
can unquestionably repair a machine, but
proving that buying more screwdrivers
reduce mechanical failures throughout
the city is a much larger statistical
problem. Case utility and crime
reduction are not the same metric. The
camera also does not know who is
actually driving. Now, a separate law
enforcement data system may connect that
plate with the registered owner, but the
registered owner might not be behind the
wheel. The vehicle might be borrowed or
rented or sold without updated records,
carrying a stolen plate or displaying a
temporary plate printed by a homing jet
printer that has begun to reconsider its
life choices. Flock says that its core
LPR system does not use facial
recognition and is designed to collect
vehicle information rather than
identifying the occupants. Some
municipalities also state that their
deployments are not connected directly
to the DMV or commercial vehicle history
databases. But because law enforcement
can use other authorized databases, a
plate observation can still become
associated with the person during an
investigation. So calling license plate
data either a personally identifiable or
completely anonymous misses the nuance.
Your plate is not your face, but neither
is it a random number with no connection
to human activity. It's more like an IP
address. By itself, it identifies a
device or vehicle with additional
records and context that can often be
connected to a person. And then there is
accuracy. ALPR is an inference system,
not a divine revelation engraved on a
stone tablet. Rain, glare, darkness,
plate frames, dirt, motion blur, unusual
fonts, damage, viewing angle, and
visually similar characters can all
affect the read. A seven can become a
two. The letter O can become a zero. One
state's plate design can look like it
was created specifically to defeat
machine vision and possibly human vision
as well. And in some parts of Canada,
plates aren't even rectangles, they're
bears. model. Internally, the
recognition model will normally produce
a candidate result and some measure of
confidence. Setting a strict confidence
threshold reduces false matches but can
miss legitimate plates that would
otherwise be read. Relaxing the
threshold catches more possibilities but
increases false positives. This is the
same precision versus recall trade-off
that appears in spam filters, medical
screening, antivirus software, and every
other detector that must decide whether
something looks enough like a target.
From a programming standpoint,
heruristics are useful, but they are by
definition imperfect. And that is why a
responsible deployment treats a plate
reader alert as a lead requiring
confirmation, not as probable cause
descending directly from the cloud. Here
in Redmond, Washington, for example,
they say that alerts must be verified
before any action is taken. Other
policies likewise require officers to
visually confirm the plate and check
that the hot list entry remains still
valid. This procedural distinction
matters enormously. If the computer says
a stolen black Range Rover just passed
by, an officer should verify that the
photograph actually shows the correct
plate, that the alert has not expired,
and that the vehicle description makes
sense. An algorithmic match plus human
confirmation can be a useful tool. An
unverified match followed by a
high-risisk felony style stop can turn
one mistaken character into a very
frightening encounter or worse.
Documented ALPR errors and incorrect hot
list entries have resulted in innocent
motorists being detained and sometimes
they're at gunpoint. Those incidents do
not mean every alert is unreliable, but
to the extent that an exception
disproves the rule, they also
demonstrate why the human validation
step cannot be treated as optional
ceremonial paperwork. Now, we arrive at
privacy, where the details matter more
than the slogans. Flock's default
retention period for license plate data
is 30 days. The company says images and
metadata are encrypted during
transmission and at rest with cloud data
protected using AE26 encryption.
According to its policy, information
remains on the roadside camera only
temporarily and is removed after upload
and is hard deleted from the cloud when
the retention period expires unless
another period is required by law or
established in the customer agreement.
30 days is not forever and that's a
meaningful safeguard. A short rolling
window limits how far into the past an
ordinary search can actually reach. It
also reduces the consequences of a
database breach compared with preserving
years and years of travel records. But
default is not the same thing as
universal. Local laws and contracts can
require or permit different retention.
Now, Flock says that an agency seeking
extended retention beyond the legal
requirements can obtain up to one year,
but the company requires approval from
an elected official or governing body.
An evidence downloaded from the system
for a legitimate cause can be retained
under the AY's own separate evidence
policies after it disappears from the
live flock database. In other words,
automatic deletion applies to the
platform's rolling data store. It can't
make a screenshot already exported into
a case file spontaneously evaporate like
an old Mission Impossible tape. Once
it's in the wild, so to speak, it's a
bell that can't be unrung. Flock also
says that the customers own their data
and that it does not sell customer data
and that sharing is opt-in rather than
automatic and that agencies control
which organizations can receive access.
Its security materials describe
role-based access controls, audit
logging, anomaly monitoring, SOC2 type 2
review, ISO 27001 controls, and
tamperresistant search logs. I take some
comfort in the notion that every search
is logged. That's a substantial
improvement over an invisible query box
with no accountability. A log can and
will record who searched when they
searched, the stated purpose of the
search, the case number if they are
required to provide one, the offense
type and which camera networks were
actually queried. Flux transparency
portal can expose portions of that
information publicly, including
anonymized usage statistics and sharing
relationships. But you need to remember
one key thing. A log is a witness, not a
guard. Logging a misuse does not prevent
it unless somebody reviews the log,
recognizes the pattern, and imposes some
consequences. Every Windows
administrator knows this problem. You
can enable exquisite auditing on a
server, but if the event log is a
digital addict that no human actually
visits until after the burglary, it
provides forensics rather than
prevention. Flock has been adding more
preventative controls including optional
required case numbers, keyword filters
intended to block searches that are
prohibited by state law, labels
identifying requests originating from
federal organizations, and restrictions
on federal access to certain state data.
The company argues that local elected
officials should determine the permitted
uses and that the platform should
provide the tools to enforce and audit
those choices. So, they don't really
want to be in the business of making up
the rules. They just want to know what
they are and follow them. It sounds like
there's also evidence that policy
controls can fail or prove incomplete.
In 2025, an Illinois Secretary of State
audit found that US Customs and Border
Protection had gained access to Illinois
plate reader data in violation of state
restrictions. Illinois ordered the axis
shut down and Flock paused its federal
pilot while adding further controls. The
episode can be read in two ways. Critics
see proof that promise guard rails did
not prevent the prohibited access while
supporters can point that the audit
trail detection shutdown and subsequent
controls as the accountability system
actually working correctly after a
failure. And both readings contain some
truth. Security engineers live in that
uncomfortable territory all the time.
Another concern is network sharing. A
city may own 50 cameras but gain search
access to detections from neighboring
jurisdictions that have agreed to share.
That can be extremely useful when a
kidnapping suspect, stolen car, or
robbery crew crosses municipal
boundaries. Because if old movies have
taught me anything, it's that criminals
have shown remarkably little respect for
the county line. But data sharing also
changes the privacy equation. A resident
may debate and approve 20 cameras
locally only to discover that the
effective searchable network is
regional, statewide, or even larger.
Critics argue that a federation of
individually modest systems can become
something no single community
consciously approved of or even really
considered in advance. Mind you, this is
also the same architecture that made the
internet useful. Independent networks
agreed to exchange traffic and the
combination became much more powerful
than any individual network. The
difference is that the internet packets
usually belong to willing participants.
Cars passing public cameras do not
negotiate peering agreements. There's
also an important product distinction.
The classic Falcon LPR has generally
been described as a vehicle focus system
taking still images rather than acting
like a conventional continuously
monitored CCTV camera. But Flock's
broader platform includes dedicated
video cameras. And in 2025, the company
announced optional live and recorded
video capability for existing LPR
hardware as well as colllocated video
products. That means a community
evaluating flock cameras needs to ask
exactly which hardware, software
options, and retention policies are
enabled rather than relying on generic
descriptions based on the brand name.
Asking whether a Flock camera records
video is therefore a little bit like
asking whether a Windows machine runs
SQL Server. Some do, some don't, and the
logo on the case doesn't answer it for
you. The legal question is evolving for
much the same reason. Courts have
traditionally held that drivers have
little expectation of privacy in a
license plate displayed openly on a
public road. And even I get that. But
the modern question is not merely
whether an officer may look at the
plate. It's whether the government may
automatically collect millions of public
observations, retain them, aggregate
them, and search them retrospectively.
In a 2025 federal case from Kansas, a
district court rejected a fourth
amendment challenge involving nine flock
detections over roughly 4 hours. The
court distinguished those limited
observations from continuous cell phone
or GPS tracking and noted that the
30-day retention period reduced its
concerns, but the same decision
explicitly warned that a denser and more
pervasive network could eventually
approach the kind of systemic tracking
that raises constitutional problems.
That is a remarkably balanced
description of the technology itself.
The constitutional question may depend
not just on what one camera does, but on
scale, density, retention, search scope,
and how the data is used, which leads to
the most useful way to think about
flock. The camera is a sensor. The cloud
service is an index. The hot list is an
alerting rule. The sherry network is a
federation. None of these components
inherently knows whether the person
operating the search is trying to find a
kidnapped child, recover a stolen truck,
identify a robbery suspect, monitor a
protest, investigate immigration status,
locate someone seeking medical care, or
satisfy a personal curiosity that has no
legitimate law enforcement purpose.
Because purpose does not live in the
lens. Purpose lives in policy,
permissions, oversight, and in the
person that is allowed to sit at that
keyboard. supporters see a machine that
observes purely public facts more
consistently than a patrol officer ever
could. It does not become tired,
distracted, or decide that one driver
looks a little more suspicious than
another. It records vehicles rather than
skin color, and it can give officers a
timely objective lead when minutes
matter. Critics answer that decisions
about where the cameras are placed and
which plates enter the hot lists, which
neighborhoods receive scrutiny, which
agencies share data, and which alerts
trigger stops are all human decisions.
Automating observation can reduce one
form of discretion while multiplying the
reach of other forms. Supporters note
that most detections are never actually
searched and disappear automatically
after the retention period. Critics
reply that innocent people are still
recorded first and filtered by suspicion
later. Supporters emphasize encryption,
audit logs, local ownership, opt-in
sharing, and the absence of facial
recognition in the core ALPR product.
Critics point out that encryption
protects data from outsiders, not from
an authorized user performing an
inappropriate search, and that a vehicle
history can reveal sensitive
associations without ever identifying a
face. Neither side is arguing about
imaginary capabilities. They're
assigning different weight to the same
engineering facts. And perhaps that is
why the debate has become so heated.
Flock cameras are not a hypothetical
future surveillance technology humming
inside of a lab somewhere. They are
practical, affordable, easily deployed
network appliances that solve real
investigative problems while creating
real governance problems at the same
time. A community deciding whether and
how to use them therefore has more
meaningful questions available than
simply asking whether cameras are good
or cameras are bad. So what offenses
justify a search? Must every search
include a valid case number? Are
searches for minor offenses allowed? Who
may create a custom hot list? How
quickly must stale entries be removed?
Must every alert be visually confirmed?
Which agencies may share that data? Are
federal requests handled differently? Is
access to sensitive locations
restricted? Who reviews the audit log?
Are misuse statistics published? Are
they public? How long is data retained?
Can exports live longer than that? Does
the public know where the cameras are
and which capabilities are actually
enabled on them? As for me, I think the
technology is incredibly impressive, as
are the potential applications, but the
ways in which the cameras can and
sometimes are used are, as my kids say,
a little sus. So, as usual, the devil is
in the details of how the system is
implemented. Answering those questions
does not eliminate disagreement, but it
moves the argument from bumper sticker
philosophy into actual systems design.
Back when I was working on operating
systems at Microsoft, we learned that
privilege by itself was not
automatically good or bad. Kernel mode
is necessary to make the computer work,
but because the consequences of error
are so much greater, kernel code
receives stricter rules. Smaller
interfaces, deeper review, and more
aggressive auditing. A connected plate
reader network deserves the same kind of
thinking. The more powerful the query,
the narrower the permission should
become. The broader the sharing, the
more visible the audit should be. The
longer the retention, the stronger the
justification should be. And the more
consequential the alert, the more
important the human verification
becomes. So, this is not a verdict on
the camera. It's simply how engineers
handle a system with a large blast
radius. A flock camera may help locate a
missing child one day and record a
thousand completely ordinary errands the
next. Both facts can be true. Its
usefulness comes from remembering events
that would otherwise be forgotten. Its
privacy implications come from exactly
the same feature. The machine does not
resolve that tension for us. It merely
puts it into a database. If you have
comments or questions about today's
episode, please leave them in the video
comments. And remember that we actually
answer and discuss each week's best
topics every Friday on Shop Talk on the
Dave's Addict channel. I'll put a link
to an episode up here. Please check one
out. If you found today's episode
interesting or entertaining, remember
that I'm mostly in this for the subs and
likes. So, I'd be honored if you would
consider leaving me one of each before
you go today. In the meantime, and in
between time, hope to see you next time
right here in Dave's Garage.
Do it. Do it. Do it.