Thread

1. JKCalhoun · 1791067032 · focus · HN ↗

   License plate reader?

   So the device should require very specific license plates to scan for—not the current dragnet. The software should only "ping" when there is a confident match with said license plate(s)—and merely log which license plate, time stamp a single photo, and note the confidence level of it being a match.

   The frame buffer should be the only place (a frame of) video is ever stored at all (excepting the high-confidence match indicated above).

   The only issue remaining would be whether we trust the device/software to have complied (and not have a backdoor) and of course there needs to be a legal warrant for every license plate uploaded (and it should expire fairly frequently, likely requiring a new warrant to continue canning for the plate).

   1. dataflow · 1791070304 · focus · HN ↗

      > The software should only "ping" when there is a confident match with said license plate(s)

      Are you suggesting the set of all license plates of interest should be stored on the device itself?

      1. jmb99 · 1791072912 · focus · HN ↗

         If there are, say, ten thousand license plates of interest at any given time (which seems high), that’s what, 10KB? Not really that hard to update that every 15 minutes (or hell, every minute).

         I don’t really see any drawbacks with storing them on the device, they should already be quasi-public knowledge (from warrants/etc) so it’s not like there’s a privacy/security risk there

         1. felixgallo · 1791079077 · focus · HN ↗

            You could just store it in a bloom filter, which would be non-public but also give you tunable accuracy. For 1 in a million false positives, a bloom filter would cost 28.8 bits per plate.

Unofficial Hacker News client; not affiliated with Y Combinator.