Privacy and ALPR Are Not the Same Thing

Written By Zain Masood

The wrong question

The public debate about automatic license plate recognition (ALPR) has collapsed into a single question: ALPR or privacy? That framing is wrong. Privacy failures in ALPR come from how a system is built, who holds the data and how it is shared, not from the act of reading a plate.

The backlash is real and, in many cases, earned. In September 2026, the U.S. Senate Judiciary Subcommittee on Crime and Counterterrorism held a hearing titled "Always Watching" on Flock Safety's camera network. The ACLU says more than 200 cities have ended contracts with Flock and other ALPR vendors since the start of 2026, and it now argues that the best protection is to ban ALPR altogether.

Banning the technology would throw away a proven tool for finding stolen cars, missing people and suspects in violent crime. This article argues for a better answer: separate the capability from the architecture. When the customer owns the data, runs the system on its own infrastructure, and sets its own retention and sharing rules, ALPR and privacy can work together.

What ALPR actually is

ALPR is a computer-vision task: find a plate in a video frame and turn it into text. A modern engine adds the plate's region and the vehicle's make, model, colour and generation. The output is a small structured record: a plate string, a timestamp, a camera ID and a few attributes.

Nothing in that task decides where the record goes, how long it lives or who can search it. Those decisions belong to three separate layers that are often sold as one bundle:

  1. Capture: the camera or sensor that sees the vehicle.

  2. Recognition: the software that reads the plate and describes the vehicle.

  3. Custody: the storage, retention rules, search tools and sharing network that hold the resulting records.

Almost every privacy harm in the current debate lives in the third layer. Stalking by an officer, warrantless federal lookups, data kept for years and a vendor breach are all custody failures. None of them is caused by reading a plate.

As a University of California, Santa Barbara computer science professor put it to local press, how an image is post-processed has nothing to do with the camera. The ACLU makes the same point from the other side: in its words, vendor promises of customer control are "a governance claim and not an infrastructure claim," because whoever holds the data truly controls it.

How the conflation happened

The public learned what ALPR is from four large vendors whose products bundle capture, recognition and custody into one vendor-run platform. When that custody layer failed, the whole technology took the blame. The CEOs of Axon, Motorola Solutions and Verkada all declined to testify at the September 23, 2026 Senate hearing, alongside Flock's CEO (Biometric Update).

Vendor Documented issue Where custody sits Root cause
Flock Safety Officer misuse (one charged officer ran 4,400+ searches on his wife and others); ICE access via local proxies; data exposed outside Boston despite a contract barring it; researchers report 55 vulnerabilities Vendor cloud; National Lookup network used by ~75% of police customers Pooled, vendor-held data with self-policed search
Motorola Solutions / Vigilant ICE can search Vigilant data directly via a Thomson Reuters contract; commercial DRN network sells plate data; 2026 class actions allege unlawful sharing of California data Vendor cloud (NVLS), no local-storage option National database plus a commercial data business
Verkada 2021 breach exposed 150,000+ live customer cameras; FTC/DOJ action in 2024 over security failures, with a $2.95M penalty Vendor cloud, proprietary cameras Centralised cloud as a single point of failure
Axon No vendor cap on retention; ALPR bundled into long-term police-platform contracts; can check reads against NCIC hotlists including an ICE list Mostly vendor cloud (Evidence.com); a local option exists Platform lock-in and bundling

Flock Safety

Flock is the centre of the backlash because it built the largest pooled network: it claims more than 120,000 cameras across 49 states. In writing to the Senate, Flock acknowledged it does very little oversight of client searches and leaves agencies to police themselves. In September 2026, prosecutors in Marion County, Indiana, charged five current or former Indianapolis officers over alleged improper Flock searches.

The sharing controls also failed at the technical level. Boston's 2025 surveillance report says Flock data was reachable by outside agencies three days into a pilot, despite a contract requiring sharing to be disabled. Mountain View police say Flock, not the department, turned on out-of-state access to their cameras. Flock's August 2026 fixes, such as case codes and a suggested 7-day retention default, still rely on the customer to enforce them.

Motorola Solutions (Vigilant)

Motorola runs a national sharing service, NVLS, and a separate commercial network, DRN, that puts cameras on tow trucks and fleet vehicles. The ACLU reports DRN claims about 500 million plate reads a month and sells data to insurers and lenders. ICE can search the Vigilant database directly through a contract with Thomson Reuters. In 2026 Motorola faced several class actions alleging California plate data was shared with federal and out-of-state agencies; Merced police said in April they found and disabled federal sharing connections.

Verkada

Verkada is now replacing Flock in some cities, including Santa Barbara, on the promise of tenant-isolated cloud storage and no shared network. Its record shows why vendor-held cloud is still a risk. The FTC alleged that weak security let a hacker reach over 150,000 live customer cameras in March 2021, including cameras in psychiatric hospitals and women's health clinics. Verkada LPR also runs only on Verkada cameras, so the customer cannot swap vendors without replacing hardware.

Axon

Axon markets itself as the ethical alternative, and it does not run a national lookup network. But it lets customers keep data as long as they like on Axon's servers and sells ALPR inside bundled, multi-year platform contracts, which the ACLU and EFF warn creates lock-in. The EFF summed up vendor swapping as simply changing the colour of the camera.

The pattern across all four is the same. The harm came from pooled data, vendor custody, weak security or bundling, not from recognising a plate.

The real problem is architecture

The first two layers, capture and recognition, look similar across vendors. The privacy outcome is decided in the third: whether plate reads flow into a vendor-held, pooled cloud or stay in a database the customer owns.

On the left, the vendor holds the records, so its security, sharing defaults and staff all become part of every community's privacy risk. On the right, the vendor never receives the data, so there is nothing for it to lose, share or sell.

Three architectural choices turn ALPR into mass surveillance:

  • Vendor custody. Data on the vendor's servers is exposed to the vendor's breaches, errors and policy changes. Boston's contract barred sharing, yet a vendor error exposed its data anyway.

  • Pooling by default. A national lookup network turns each local camera into a sensor for every connected agency, including officers searching on behalf of federal agencies.

  • Closed hardware. When recognition only runs on the vendor's own cameras, a community cannot change vendors or terms without replacing its hardware. That weakens its hand in every contract negotiation.

A different model: Sighthound

Sighthound separates the three layers and hands custody to the customer. It sells recognition software and optional edge hardware, and it does not hold the plate reads its software produces. As Sighthound's August 26, 2026 statement puts it, a company cannot share or sell what it never collects.

Open and hardware-agnostic. ALPR+ works with any camera that outputs an RTSP or ONVIF stream, including fixed, PTZ and in-car dashcams. It runs on Windows, Linux and embedded Linux, on CPUs or on NVIDIA, Intel and Qualcomm edge hardware. Agencies and businesses can keep the cameras they already own and leave without ripping them out.

Customer-controlled deployment. Sighthound recommends running the stack on-premise or inside the customer's own cloud account. It ships as a Docker container, an SDK or on Sighthound's US-built Compute cameras and nodes, and it runs fully offline or air-gapped. The customer's retention and access policies govern the data because the data never leaves the customer's environment.

No network by default. Sighthound Retriever, the browser-based search application, runs on the agency's own hardware. There is no central database pooling vehicle movements. An agency that needs to share with a neighbour can choose to share, as a deliberate act under its own control.

Redaction built in. Sighthound Redactor blurs faces, plates and other identifiers in video, images and audio before public release, with audit logs that record what was redacted and who approved it.

Question Vendor-custody platforms Sighthound
Who holds the plate reads? The vendor's cloud The customer, on-premise or in its own cloud
Can the vendor see or share the data? Yes, technically No; it never receives it
Which cameras? Mostly the vendor's own Any RTSP or ONVIF camera
National sharing network? Flock and Motorola, opt-out None; sharing only if the customer builds it
Works offline? Generally no Yes, including air-gapped
Who sets retention? Customer setting on vendor servers Customer, on customer infrastructure

One honest caveat: Sighthound also offers a hosted developer API. The custody guarantees above apply to the on-premise and customer-cloud deployments Sighthound recommends for plate data.

A privacy-by-design checklist

Any community or business can hold an ALPR deployment to these tests, whichever vendor it chooses. Each one targets the custody layer, where the harms occur.

☐ Custody: plate reads are stored on infrastructure the customer owns or controls, and the vendor has no technical access.

☐ No default pooling: the system joins no national or regional lookup network unless the governing body votes to share.

☐ Short retention: reads with no hotlist hit are deleted quickly. The ACLU points to New Hampshire's three-minute rule, or at most 48 hours.

☐ Hardware independence: the software runs on existing, standard cameras, so the community can change vendors without replacing its cameras.

☐ Search accountability: every search requires a case number and reason, is logged immutably, and is audited by someone outside the searching unit.

☐ Scope limits: plates and vehicle attributes only; no free-text searches for people and no algorithmic "suspicious pattern" alerts.

☐ Redaction before release: footage released under public-records law has bystanders' faces and plates removed.

☐ Rules in law, not contracts: retention and sharing limits are written into an ordinance, so they outlast any single vendor.

The ACLU's own comparison of ALPR vendors reaches a similar conclusion: how a system operates matters more than which vendor provides it, and local storage takes the vendor's sharing policy off the table.

Fix the architecture, keep the tool

The 2026 backlash is a verdict on a business model, not on a technology. Pooled national databases, vendor-held cloud data, weak security and self-policed searches produced the stalking cases, the federal lookups and the breaches. Reading a plate produced none of them.

ALPR still finds stolen cars, supports Amber and Silver Alerts and closes cases that would otherwise go cold. Communities do not have to choose between that value and their residents' privacy. They need systems where the customer holds the data, sharing is a deliberate choice, retention is short and the hardware is open. That is the model Sighthound builds, and the standard every ALPR deployment should meet.

Sources

What to do next

See it run on your own image

Zain Masood
Next

Valet Park of America Uses Sighthound ALPR+ for Hospital Parking Access Control