Flock Safety Is More Than a Plate Camera
A driver sees a Flock Safety license-plate camera beside the road. The company's own patent uses a broader phrase: an object-search system built from a "dynamic surveillance network." Its specification discusses classifying humans, vehicles, bicycles, and animals, plus examples involving clothing, physical traits, and face-recognition data points. Those examples show why the privacy analysis cannot stop at reading plates.
One captured Flock Safety search client registers separate routes for at least six investigative modes: lookup, visual search, standard search, multi-geo search, convoy search, and people search. A separate sharing library names grants for search, hotlists, live and historical video, downloads, imaging controls, pan-tilt-zoom controls, and analytics. A third client contains permissions for camera deployment, one-shot requests, bulk settings, device tunnels, live and recorded streams, and stream secrets.
The discovery is not that one camera does all of those things. It is that the retained code describes an ecosystem in which collection, search, organizational access, video, administration, and infrastructure control exist in separate clients. For a driver, passenger, bystander, operator, or person represented in a result, oversight limited to where a roadside camera is installed misses the software that determines what an observation can become.
The patent describes a dynamic surveillance network
Flock Group Inc. is the assignee of U.S. Patent 11,416,545 B1, titled System and method for object based query of video content captured by a dynamic surveillance network. The issued claims focus on searchable video indexed by object class, time, location, and other attributes. The broader specification describes neural-network classification of humans, vehicles, bicycles, and animals; person examples involving clothing, gender, race, estimated height and weight; and a scenario using face-recognition data points to find the same person across footage and construct a timeline (U.S. Patent 11,416,545 B1).
Source excerpt. U.S. Patent 11,416,545 B1 identifies Flock Group Inc.'s object-based-query patent and its dynamic-surveillance-network title.
That distinction is essential. A patent specification records embodiments the applicant chose to describe. Flock currently says its FreeForm people search relies on observable, non-biometric appearance and does not use facial recognition (Flock FreeForm). The patented vision is far broader than LPR.
Source excerpt. The patent specification gives person-class and physical-attribute examples.
Source excerpt. The specification includes a face-recognition-data-point scenario.
The search surface is already broader than plate lookup
The clearest starting receipt is the search router. It includes separate paths for /lookup/:plate?, /visualSearch/:objectId?, /search/:sessionSearchRequestId?, /multiGeoSearch, /convoy, and /peopleSearch.
Figure 2. The captured Jose Cuervo client registers six distinct search routes.
Each path mounts a different interface or search mode. Multi-geo and convoy are not checkboxes inside one exact-plate form; visual and people search get their own routes. An evaluation framed only around exact plate lookup would miss most of the ways this software lets an operator begin or widen a query.
The six modes were packaged into this captured client.
That difference matters to affected people. A narrow lookup begins with a known identifier. Other modes can begin with an object, multiple places, co-travel, or a people-search interface. The later episodes examine those mechanics separately because the privacy cost depends on how a search starts, what it correlates, and whether it discovers candidates who were not already known.
Sharing is defined feature by feature
A separate Garnacha library defines shareable features. Its set includes SEARCH, HOT_LIST, VMS_GO_LIVE, VMS_HISTORICAL, VMS_DOWNLOAD, VMS_IMAGING_SETTINGS, VMS_PTZ, VMS_PTZ_SETTINGS, and ADVANCED_ANALYTICS. The adjacent display-title map renders those entries as Search, Hot List, VMS Go-Live, VMS Historical, VMS Download, VMS Imaging Settings, VMS PTZ, VMS PTZ Settings, and Analytics
Figure 3. The sharing library lists distinct search, hotlist, video, imaging, PTZ, and analytics feature scopes.
The library does more than name shareable products. It maps each feature to a distinct permission set, so search access, live viewing, recorded viewing, download rights, camera movement, settings control, and analytics are separate grants.
The relevant boundary is therefore not simply whether two organizations "share Flock." It is which feature was granted, to which organization, for which devices or networks, under what approval and review process. Granularity conceals the true reach of a grant when reviewers discuss only "camera sharing" without naming video downloads or PTZ control.
The control plane can affect infrastructure
The camera-management client adds another layer. Its permission enum includes creating deployments and one-shot requests, exporting deployments, managing bulk camera settings and device tunnels, viewing live and recorded streams, and viewing stream secrets
Figure 4. Camera-management permission names describe a privileged operations surface, not an ordinary search-result screen.
The permission names appear in the production-labelled captured camera-management artifact. Through those named permissions, the client can gate infrastructure-facing controls spanning deployment records, bulk configuration, tunnels, stream viewing, and stream-secret access.
A privileged-account review must cover operational control along with plate searches. Bulk settings, tunnels, and stream credentials carry a different risk profile from viewing one detection.
One observation can cross several software boundaries
The public-interest concern is that each layer changes reach. A sensor produces an observation. Search modes determine how that observation can be found or correlated. Sharing determines which organizations can reach a feature. Download rights can create copies outside the original interface. Camera-management permissions affect the collection and streaming infrastructure itself. Those are separate decisions, owned by different administrators, and potentially reviewed under different policies.
For people captured by the system, organizational structure is mostly invisible. They think in terms of the camera they passed. The software boundary depends instead on route entitlements, feature grants, network relationships, exports, and privileged accounts.
The reach of a sighting cannot be read off the camera alone: client generation, tenant configuration, and the grants and accounts above can each change what happens next.
The reporting question is no longer "Where is the camera?" It is "What can this observation become, who can reach it, which copies can leave the interface, and who controls the system that produced it?"