/nearby route silently replaces empty WiGLE/Shodan scan results with hardcoded dummy surveillance devices

[tg12]

Summary

The /nearby route fabricates WiFi and Bluetooth device intelligence from hardcoded dummy fixtures when WiGLE and Shodan return empty results, producing invented surveillance devices and consumer electronics as if they were real scan output.

Evidence

app.py:2859-2874 — triggered whenever both WiGLE and Shodan return zero results:

# Fallback to dummy data if no results
if not devices:
    print(f"Using dummy data fallback for {mode}")
    if mode == 'bluetooth':
        devices = [
            {"lat": lat + random.uniform(-0.002, 0.002), "lon": lon + random.uniform(-0.002, 0.002),
             "ssid": "Tesla Model 3", "type": "car", "vendor": "Tesla Motors"},
            {"lat": lat + random.uniform(-0.002, 0.002), ..., "ssid": "Hidden_BT_Tracker",
             "type": "bluetooth", "vendor": "Unknown"},
        ]
    else:
        devices = [
            {"lat": ..., "ssid": "CYBER_SURVEILLANCE_ROUTER", "type": "router", "vendor": "Cisco Systems"},
            {"lat": ..., "ssid": "DASHCAM_V3", "type": "camera", "vendor": "Nextbase"},
            {"lat": ..., "ssid": "5G_TOWER_B4", "type": "cell_tower", "vendor": "Ericsson"},
        ]

The fabrication notice is printed to server stdout only (print(f"Using dummy data fallback for {mode}")). The JSON response is structurally identical to a real scan result — no simulated, mock, or fallback field is included.

• app.py:2876 returns jsonify({"devices": devices}) — no provenance distinction.
• app.py:2753 and app.py:2840 show the WiGLE and Shodan calls that precede the fallback.

Why this matters

• Recon tools that fabricate physical-world evidence are dangerous: they can confirm surveillance infrastructure that does not exist.
• A user running a scan in an area with no provider coverage receives a structurally normal list of routers, cameras, and cell towers invented from a fixture — indistinguishable from real output.
• "CYBER_SURVEILLANCE_ROUTER" attributed to Cisco Systems and "5G_TOWER_B4" attributed to Ericsson at believable lat/lon offsets look like live intelligence.

Attack or failure scenario

An investigator uses GeoSentinel to scan a location. WiGLE and Shodan have no coverage for the area. The route silently returns CYBER_SURVEILLANCE_ROUTER (Cisco), DASHCAM_V3 (Nextbase), and 5G_TOWER_B4 (Ericsson) at the queried coordinates. The investigator records these as real nearby devices, maps the "surveillance infrastructure," and draws false conclusions about monitoring at that location.

Root cause

Demo/test fixtures were committed directly into the production route handler. There is no production mode guard, no simulation header, and no disclosure mechanism — only a stdout print that operators will never see.

Recommended fix

1. Remove all hardcoded dummy device records from production route handlers.
2. Return an explicit empty or degraded response when providers return no results.
3. If demo/simulation mode is required, gate it behind a development-only flag and include a simulated: true field in every response.
4. Add a test asserting that empty upstream results never produce a non-empty devices list.

Acceptance criteria

• /nearby never returns synthetic device records in production mode.
• Empty provider responses are represented as {"devices": [], "provider_status": "no_coverage"} or equivalent.
• No hardcoded device fixtures exist in any production route handler.

Suggested labels

bug, reliability, production-readiness

Priority

P1

Severity

High — fabricated physical-world intelligence is returned with no disclosure, indistinguishable from real scan output.

Confidence

Confirmed — app.py:2859-2874 is explicit and unconditional when provider results are empty.