An open source project can put you under police surveillance without you ever writing a line of illegal code. That is the part of this week's story worth thinking about, and it applies far outside the United States.
404 Media reported on 15 August 2026 that US law enforcement fusion centres are monitoring TikTok, Instagram and Facebook accounts critical of Flock Safety, the automatic licence plate reader (ALPR) vendor. You can read the original report here. I want to talk about the engineering lesson buried inside it.
🔍 A map became an intelligence target
The project at the centre of this is DeFlock, a crowdsourced open source map of ALPR camera locations built by Will Freeman. Technically it is unremarkable: collect user-submitted points about publicly visible hardware, render them on a map, publish the data.
Intelligence bulletins marked "Law Enforcement Sensitive" and obtained through public records requests came from at least six agencies:
| Agency | State |
|---|---|
| Colorado Information Analysis Center | Colorado |
| Wisconsin Statewide Intelligence Center | Wisconsin |
| New Jersey State Police | New Jersey |
| North Florida Fusion eXchange | Florida |
| Central Florida Intelligence Exchange | Florida |
| New Mexico All Source Intelligence Center | New Mexico |
Freeman's response to how his project was characterised is the sentence every maintainer should sit with:
"DeFlock has never called for disabling cameras or covering license plates, contrary to what recent law enforcement bulletins claim."
That is the whole problem in one line. The dataset did not change. The reading of it did.
📊 Documentation and instruction are not the same thing (but they get merged)
Reading the reporting closely, several very different activities ended up inside the same bulletins:
- A map of camera locations built from public observation.
- Instagram accounts such as Nomark.Project, posting daily videos of camera destruction.
- An account, Thepatrioticgoy, that posted instructions for disabling cameras.
- General social chatter, which one bulletin described as "extensive and ongoing chatter on social media platforms such as Facebook and TikTok regarding various methods to interfere with or physically destroy Flock LPR cameras."
- A 25 June 2026 traffic stop involving a device that could be used to locate Flock cameras, from someone the bulletin linked to the movement and described as having written software to scan and locate vulnerabilities.
Flock Safety's position was direct: "Damaging public safety equipment is illegal and puts communities at risk, which is why we strongly condemn this type of behavior."
Here is the split that matters to you as a builder:
| Activity | What it actually is | How a bulletin can render it |
|---|---|---|
| Mapping visible hardware | Public observation, journalism-adjacent | "Target reconnaissance" |
| Publishing an open dataset | Transparency work | "Distribution of operational intelligence" |
| A scanner script in the repo | Security research | "Tooling for interference" |
| Comments section left unmoderated | Community | "Calls to action" |
Key takeaway: Your project is judged as one blob. The map, the README, the issue tracker, the Discord and the loudest person in your comments all get read together by someone who is not a developer.
🛠️ What this changes about how I'd ship a project like this
I build tools in public, and most of what I ship is boring by design: calculators, converters, file utilities. But some categories are not boring, and mapping, scraping and scanning projects are firmly in that group. Three practical changes I'd make before publishing one:
- Write the scope statement first, not last. One paragraph at the top of the README saying what the project is for and what it explicitly does not endorse. Freeman's clarification had to come after the bulletins. A dated line in the repo history is far stronger evidence than a quote given later.
- Separate the dataset from any tooling. A map repository and a scanner repository should not be the same repository. Once "software to scan and locate vulnerabilities" sits next to a location dataset, they read as one system.
- Moderate the surfaces you own. Issues, discussions and comments are part of your project's public record. If you cannot moderate a surface, close it.
None of that is legal advice, and none of it guarantees anything. It just makes the honest reading of your work the easiest reading available.
🌐 Why a Sri Lankan developer should care
The obvious objection is that this is a US story about US fusion centres. Fair. But two things travel:
- The technology is exported. ALPR, camera analytics and vehicle-data platforms are sold internationally. Sri Lanka already has vehicle registration as structured, decodable data. If you have ever used our vehicle number plate decoder, you know how much a plate string alone tells you. Now imagine that string logged with a timestamp and a location, thousands of times a day.
- The framing is portable. "This person mapped things and wrote a scanner" is a description that can be applied anywhere, by anyone, to any developer. It does not need a fusion centre to do damage. A tender dispute, a client falling out, or a bad-faith complaint is enough.
If you are a student or a small-team builder here, the practical risk is rarely a dramatic raid. It is a project you built for a portfolio being described badly by someone with more institutional weight than you.
💡 Personal opsec that costs nothing
You do not need a threat model worthy of an intelligence agency. You need the cheap layer that most developers skip:
| Habit | Why it matters | Cost |
|---|---|---|
| Strip EXIF before posting field photos | Photos of hardware carry GPS coordinates and device IDs | Seconds |
| Keep contribution rules explicit | Sets what your project accepts, in writing | One file |
| Don't reuse a handle across activism and work | Correlation is trivial and automatic | Free |
| Send sensitive files with an expiring link | Nothing sits in an inbox forever | Free |
For the first one, our EXIF metadata viewer runs in your browser, so the photo never leaves your machine. For the last, one-time secret does the expiring-link part without an account.
Assume anything you publish will be read by the least charitable reader you can imagine, and by an automated system that cannot tell documentation from instruction.
What this means for you
Publishing open source is still the right default. I am not arguing for less transparency; the DeFlock project exists because someone thought public infrastructure deserved public accounting, and that instinct is correct.
What has changed is that the gap between "I documented something visible" and "I was described as a threat" is thinner than most of us assumed. That gap is closed with unglamorous work: a scope statement, separated repositories, moderated surfaces, clean metadata and a handle you keep out of your work identity.
Do those five things and your project defends itself when you are not in the room. Skip them and someone else writes the description of your work, in a document you never get to see.
Top comments (0)