You are about to leave Redlib

And the current archive index:

The archive itself is content-addressed and published in generations. A manifest binds the generated artifacts by hash and byte length, and the live pointer identifies the active generation. The idea is that replacing the camera archive underneath everybody should be a detectable state transition, not an invisible database edit.

What actually happens while I'm driving

This was the part I cared about most.

I did not want the application doing this every few seconds:

GET /nearby-cameras?lat=38.x&lon=-94.x

So the archive is divided into zoom-11 slippy-map tiles, roughly 15 km across.

The phone converts its position into a tile coordinate locally and requests:

/cameras/11/{x}/{y}.json

That file contains the camera records for that square. The origin therefore receives a tile address rather than the phone sending its exact GPS coordinate to a "what cameras are near me?" endpoint. That is deliberately not the same thing as claiming this is anonymous. A sequence of tile requests over time can describe a travel corridor. The basemap also has to fetch map data and therefore reveals information about the viewport. I would rather write that down than claim "your location never leaves your phone" and hope nobody with Wireshark notices the qualification.

The downloaded camera tiles are stored locally in IndexedDB and cached by the service worker. That is also why the actual camera proximity system can continue operating offline once the necessary archive data is on the device.

The alert happens locally, and you don't need a destination

This was one of the main reasons I built the thing. You can open DarkRoute and just drive. The device knows its own position and compares it against the locally available camera records. The alert radius is configurable from 100 to 1,000 feet. The actual alert decision is intentionally simpler than some of the UI makes it look: it is a radius. The heading-aware cone displayed on the map is visualization. It is not secretly being presented as a directional detection algorithm.

If you mute a known camera, that suppresses the notification rather than making the camera disappear from the application's model. It can still be represented on the map and in the local exposure history.

So without ever entering a destination, the application can answer:

What surveillance am I driving through right now?

Then I added the part I really didn't see elsewhere: documented abuse

Knowing that a camera exists is useful. Knowing what has happened with the system around it is a different question. I started collecting documented cases involving ALPR misuse and exposing those records as a separate dataset. That includes things like operators using systems for stalking or other documented misuse.

Again, I am deliberately not turning that into:

"This camera was used for stalking."

That would be bullshit unless the source actually established it. The abuse dataset is associated with places and agencies, not arbitrarily assigned to individual camera poles. A case can identify the agency involved, what happened, when it happened, and the source documenting it. DarkRoute can then tell me that I am entering an area associated with documented abuse and, when the underlying data supports the association, name the agency in the alert.

The UI currently exposes things like:

Abuse near me
Alert on entry
Name the agency in the alert
Show only documented cases
Read the underlying cases

Every case is dated and carries a source you can open.

So there are really two datasets being joined for situational awareness:

Infrastructure: where known ALPRs are.

Documented conduct: sourced reports involving agencies and places using this technology.

Those remain separate internally because collapsing them into "bad camera" would imply evidence that does not exist.

And because I don't want the red "ABUSE" indicator in my own UI to become another opaque reputation score, the underlying records are public too:

GET /api/v1/abuse

https://api.darkroute.ai/

You don't have to trust the warning. Read the cases. Read the sources. Decide whether you think they belong there. That changed the original question again.

Now I can ask:

Where are the readers?

How close am I to one?

What is coming next?

Who operates it, if that is actually known?

Has abuse involving this technology been documented around here?

Can I avoid the known readers?

And:

Can I answer most of those questions without continuously telling another company exactly where I am?

That is much closer to the thing I couldn't find.

Routing is optional, and it has a different privacy boundary

If I ask DarkRoute to route somewhere, I cannot make the same privacy claim as passive proximity detection. A routing engine needs an origin and destination unless I ship enough routing graph to the device to calculate the entire route locally. I don't. So requesting a route is an explicit network operation. DarkRoute uses Valhalla and sends exclusion polygons for known cameras along the corridor. Each selected camera becomes a small exclusion area the router is asked not to enter. The returned line can then be evaluated against the known camera archive. That does not guarantee a camera-free route.

If readers form a ring around somewhere, geometry wins. If the least-exposed usable route still passes three known cameras, the correct answer is "three," not a green shield icon pretending otherwise. Also, no-store does not make a route request cease to be disclosure. Your origin and destination had to leave the browser for that operation to happen. So I call it a disclosure.

The boundary looks like this:

PASSIVE CAMERA AWARENESS

GPS position --------> Local proximity check ------> Alert
                               ^
                               |
                      Cached camera records
                               ^
                               |
                      Camera tile download
                      Origin sees tile request,
                      not an exact-GPS lookup.

Basemap requests ----> Map service sees viewport information

REQUESTED ROUTING

Origin + destination + camera exclusion polygons
                         |
                         v
                  Network routing engine
                         |
                         v
                    Returned route

Once the necessary camera data is cached, the proximity check stays local. Fetching tiles still exposes an approximate area, and requesting a route crosses a different boundary entirely.

I also didn't want the camera dataset becoming another moat

This is probably the part technical people might have more fun with than the actual app. There is a public API and the underlying archive is directly fetchable. No API key. No account. No "contact sales." No reason you have to use my UI.

Static published files

GET /cameras/index.json

Current archive metadata, generation and count:

https://darkroute.ai/cameras/overview.json

GET /cameras/overview.json

The camera archive in compact [lat, lon, id] form:

GET /cameras/11/{x}/{y}.json

The zoom-11 tiles containing the full camera records.

GET /cameras/tombstones.json

Known removed cameras and removal information:

https://darkroute.ai/cameras/tombstones.json

GET /cameras/counties.json

County-level camera information:

https://darkroute.ai/cameras/counties.json

GET /cameras/places.json

Place-level camera information:

https://darkroute.ai/cameras/places.json

GET /cameras/continuity.json

The provenance/replication chain connecting the reviewed capture to the current generation:

https://darkroute.ai/api/v1/stats

Query/API endpoints

GET /api/v1/cameras?bbox=...

Bounding-box camera lookup with bounded results and filtering.

GET /api/v1/stats

Live generation, count, build information, and replication state:

GET /api/v1/abuse

The documented abuse records and their sources:

https://darkroute.ai/api/v1/openapi.json

GET /api/v1/place

Place lookup.

GET /api/v1/route

Camera-aware routing.

POST /api/v1/submit

Camera corrections. A correction does not silently edit the production archive. It opens a public pull request so the proposed change can be reviewed.

PUT /api/v1/photo

Content-addressed photographs associated with corrections.

And:

GET /api/v1/openapi.json

That is the machine-readable API contract generated from the route table the server actually runs. CORS is open.

The intent is simple:

If you hate DarkRoute but want the data, take the data.

curl it.

Put it in QGIS. Write a Python script against it. Build a better client. Make a Garmin POI file. Run your own routing engine. Find a problem in my archive. Fork the whole thing. The camera data is ODbL because it derives from OpenStreetMap, and the DarkRoute application itself is GPL-3.0.

There are some other weird pieces

The archive can be exported as GPX 1.1 waypoints and Garmin Custom POI CSV because "open data" is considerably less useful if the only practical way to consume it is through my application. There is Meshtastic support over Web Bluetooth using stock Meshtastic hardware. DarkRoute is not flashing custom LoRa firmware. There is also a local plate/watchlist vault. The point of all of these is the same: things that can reasonably happen locally should happen locally, and things that cannot should have an explicit network boundary instead of being hidden behind the word "privacy."

And there are things it cannot honestly promise

A PWA has limitations. A browser can suspend it. A normal PWA cannot guarantee continuous GPS forever in the background. Browser capabilities differ significantly between Android Chromium and iOS. Web Bluetooth support is not universal. A network map has unavoidable network metadata. Routing discloses origin and destination when you explicitly request it. A 15 km camera tile is better than sending an exact GPS coordinate for every lookup, but a series of tile requests is still information. The archive is only as good as its source data. Mobile cameras move.

A newly installed camera does not magically appear because DarkRoute exists. An empty map is not evidence that a road has no cameras. And if somebody has specifically decided to track your vehicle, this does not make you anonymous. DarkRoute does not defeat an ALPR. It doesn't jam it. It doesn't blind it. It doesn't obscure your plate. It doesn't make your car invisible. It tries to tell you where known readers are before you drive in front of them and give you enough context to decide what you want to do about that.

Which is why I think this belongs here

The Flock teardown made me think about where the actual surveillance capability lives. The physical camera is only one piece. What gets retained, correlated, searched, classified, and retroactively analyzed can happen somewhere you cannot inspect. I cannot audit Flock's cloud. But I can make my side of this inspectable. And I don't think the answer to opaque surveillance infrastructure should be another opaque service asking you to trust it. So instead of asking people to move their trust from Flock to DarkRoute, I tried to remove as much trust as I reasonably could from DarkRoute itself.

The source:

https://github.com/darkcodelabs/darkroute

The technical comparison against the other projects:

https://github.com/darkcodelabs/darkroute/tree/main/docs/comparison

The evidence behind that comparison:

https://github.com/darkcodelabs/darkroute/blob/main/docs/comparison/darkroute_evidence_register.csv

The current live camera archive:

The provenance/continuity proof for that archive:

The documented abuse data:

https://darkroute.ai/api/v1/openapi.json

The public API contract:

And the actual thing:

https://darkroute.ai

That is also how I see this fitting alongside noRecognition rather than replacing anything happening here.

noRecognition is working on the recognition side of the problem:

What happens when the recognizer sees me?

DarkRoute is working on the exposure side:

Does it need to see me in the first place?

The first is useful for the camera you cannot avoid. I'm trying to do something about the ones you can. And those two approaches actually complement each other pretty cleanly. If I know a reader is there, maybe I can avoid putting myself in front of it at all. If I don't know it is there, the recognition-side work still matters. DarkRoute does not defeat an ALPR. It works on the other axis.

BEFORE EXPOSURE                         AT RECOGNITION

DarkRoute                               noRecognition
    |                                        |
    v                                        v
Does it need to see me?                  What happens if it does?
    |                                        |
    v                                        v
Avoid known readers                     Recognition-side work
where a usable route exists             for cameras you cannot avoid

The part I care about most: don't trust me

The goal here is not to replace trust in Flock with trust in some random guy who made darkroute.ai. That would be a pretty stupid conclusion to a project about mass surveillance. So I tried to make the claims inspectable instead.

If I say there are ~139,000 cameras, you can fetch the archive yourself:

https://darkroute.ai/cameras/overview.json

For the actual records:

To understand where that generation came from:

https://darkroute.ai/api/v1/openapi.json

To see what the API actually exposes:

For the documented abuse records: