SparrowMap: why the camera, not the cloud, does the thinking

On-device license plate recognition running on a spare phone, with the video never leaving the handset, is the part of SparrowMap worth your attention. Not the politics.

The project (sparrowmap.com, surfaced on Hacker News this week) is a volunteer camera network that photographs government vehicles on public roads and publishes them to a live map. The site says it was "Built in Michigan." Set the subject matter aside for a moment. The interesting thing is the pipeline.

🔍 Two vehicles, two completely different code paths

Most camera projects have one path: capture, upload, sort it out on the server. SparrowMap splits the decision at the sensor.

The site's own wording is blunt about the second row:

"The plate is destroyed on the camera itself, before anything leaves it."

That is a classification decision made before transmission, which is the opposite of how nearly every hobby CV project I have read gets built. The usual shape is "upload frames, run the model on a GPU box, filter later." Filtering later means the unfiltered thing existed on someone else's disk, at least briefly.

⚡ "There is not one" is the strongest sentence on the page

The line that does the real work:

"if the video were uploaded for a server to look at, there would be a video feed to intercept. There is not one."

A privacy policy is a promise. An architecture is a constraint. You can break a promise silently; you cannot intercept a stream that was never created. Compare the two designs by what an attacker or a legal order actually gets:

Key takeaway: Data you never collect cannot leak, cannot be subpoenaed, and cannot be sold by whoever buys your startup in three years. Deleting at the sensor is a stronger guarantee than any policy page you can write.

This matters far outside surveillance. Any product that touches an ID card, a payslip, a medical form, or a face has the same fork in the road.

🛠️ The whole build cost is a phone you stopped using

The setup requirements listed on the site are unglamorous, and that is the point:

• Works on an old phone, a laptop webcam, or a USB camera
• No account, no sign up, no app store
• The camera's exact location is never published, only the street it watches
• The operator can shut it off and leave the network at any time
• Desktop install via a PowerShell command on Windows or a shell script on Linux, with "only detections leave it, never video"

The logic on the device is roughly this shape:

frame
  └─> detect plate region
        └─> is this a government vehicle?
              ├─ yes -> keep photo + plate -> upload
              └─ no  -> destroy plate on device -> upload anonymous dot only

Two things here are directly useful to a small team.

First, browser-based deployment sidesteps the app stores entirely. No review queue, no policy appeal, no developer account, no waiting a week to ship a one-line fix. For a two-person team in Colombo shipping something a platform might find politically awkward, that is not a convenience, it is survival.

Second, inference on a mid-range phone is a solved problem now. A five-year-old Android has more than enough compute for continuous plate detection. That is a server bill of zero, versus GPU-hours for every camera you add. The unit economics of edge inference are what let a volunteer network exist at all.

I could not confirm a license from the landing page, so I will not call it open source. The install path is a one-line script and the site points at GitHub repositories; that is as far as the source page goes, and I am not going to fill the gap with a guess.

🇱🇰 The same trick, pointed at Sri Lankan problems

Copying the politics is not the interesting move. Copying the data-minimisation-at-capture pattern is. A few things I would genuinely like to see someone build here, all of which work with an old phone taped to a window:

1. Bus and three-wheeler counts at a junction, by hour. Publish counts, never plates, never faces. Feed it to the municipality when they argue about lane changes.
2. Road damage mapping from a dashcam feed, where the frame is scored on-device and only a GPS point plus a severity number is uploaded.
3. Flood depth markers during the monsoon, read off existing gauges by camera, so nobody has to stand in the water to report a number.
4. Bus arrival reliability on a single route, measured rather than complained about.

Every one of those is legal-safe because of the architecture, not because of a policy promise. If the identifying data is destroyed on the device, there is nothing to argue about.

If your project needs to reason about Sri Lankan plates specifically, the province and vehicle-class letters follow the Department of Motor Traffic's published format. I built a free Sri Lanka number plate decoder that breaks a plate down into province, vehicle class and registration era, which will at least save you reverse-engineering the format from scratch.

A caution I am not qualified to remove: counting anonymous vehicles and publishing identifiable plates are two very different acts under Sri Lanka's data protection law. I am an engineer, not a lawyer. Before you publish anything that identifies a person or a vehicle owner here, get actual legal advice. The technical fact that you can does not settle whether you may.

💡 What this means for you

If you are building anything that sees, hears or reads people, take three things from SparrowMap and leave the rest:

1. Move the classifier to the edge. Decide what to keep before anything is transmitted. Your server bill drops and your breach exposure drops with it.
2. Ship in the browser when you can. No store review, no gatekeeper, no account wall. getUserMedia plus a small model covers more product ideas than most people assume.
3. Write down what you destroy, not just what you store. "The plate is destroyed on the camera itself" is a better privacy statement than three paragraphs of legalese, and it is testable.

The lesson survives even if you hate the project. Decide at the sensor. Upload the conclusion, not the evidence.