Flock is going after a website called HaveIBeenFlocked.com that has collated public records files released by police.

The Flock saga continues.

A handful of police departments that use Flock have unwittingly leaked details of millions of surveillance targets and a large number of active police investigations around the country because they have failed to redact license plates information in public records releases. Flock responded to this revelation by threatening a site that exposed it and by limiting the information the public can get via public records requests.

Completely unredacted Flock audit logs have been released to the public by numerous police departments and in some cases include details on millions Flock license plate searches made by thousands of police departments from around the country. The data has been turned into a searchable tool on a website called HaveIBeenFlocked.com, which says it has data on more than 2.3 million license plates and tens of millions of Flock searches.

The situation highlights one of the problems with taking a commercial surveillance product and turning it into a searchable, connected database of people’s movements and of the police activity of thousands of departments nationwide. It also highlights the risks associated with relying on each and every law enforcement customer to properly and fully redact identifiable information any time someone requests public records; in this case, single mistakes by individual police departments have exposed potentially sensitive information about surveillance targets and police investigations by other departments around the country.

Archive: http://archive.today/yXLPQ

  • Amju Wolf@pawb.socialEnglish
    3·
    19 小时前

    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.

    • partial_accumen@lemmy.worldEnglish
      1·
      3 小时前

      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.