Thw issue youll run into is effectiveness at that small scale, sonyoull be tempted to share data with other systems like that, and eventually you’ll end up creating a different flock.

I wonder if a segregated system design could address this. Similar in-system segregation like a TPM for the actual detection/matching part of the system separated from the command and control part.

As in, the camera and OCR operations would be in their own embedded system which could never receive code updates from the outside. Perhaps this is etched into the silicon SoC itself. Also on silicon would be a small NVRAM that could only hold requested license plate numbers (or a hash of them perhaps). This NVRAM would be WRITE ONLY. So it would never be able to be queried from outside the SOC. The raw camera feed would be wired to the SoC. The only input would be from an outside command and control system (still local to our SoC) that and administrator could send in new license plates numbers to search against. The output of the SoC would “Match found against License Plate X”. Even the time stamp would have to be applied by the outside command and control system.

This would have some natural barriers against dragnet surveillance abuse.

• It would never be possible to dump the license plates being searched for from the cameras themselves even by abusive admins. The only admin option would be to overwrite the list of what the camera is trying to match against.
• The NVRAM that contains the match list could be intentionally sized small to perhaps a few hundreds plate numbers so that an abusive admin couldn’t simply generate every possible license plate combination effectively turning this back into a blanket surveillance tool. The NVRAM limit could be implemented as an on-die fuse link so that upon deployment the size could be made as small as needed for the use case.