{
  "id": 13327686,
  "title": "Threat-modeling the LAN sync in my wildlife app (as a beginner)",
  "url": "https://urgent.news/2026/10/10/threat-modeling-the-lan-sync-in-my-wildlife-app-as-a-beginner",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-10T04:34:28.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/amgedi/threat-modeling-the-lan-sync-in-my-wildlife-app-as-a-beginner-43j0"
  },
  "original_language": "en",
  "account": "A beginner programmer has penned a threat model for a feature in their open-source wildlife incident-handoff app. The feature allows two devices on the same local network to exchange incident records directly, without relying on a cloud service. This is an experimental, opt-in feature that has not undergone independent review.\n\nThe main concern is protecting sensitive information such as animal locations and private contact details, which should not be leaked. The potential threat is eavesdropping, where someone on the same WiFi network could intercept the data. However, the data is encrypted using AES-256-GCM with a key that both devices agree on through the P-256 ECDH + HKDF protocol.\n\nThe keys used for encryption are long-lived, which means there is no forward secrecy unless the keys are rotated or re-paired. Impersonation is another risk - someone could pretend to be the other device. Each install has its own keypair and fingerprint to compare, which helps prevent impersonation on a hostile network. However, if people fail to compare fingerprints, impersonation could still occur.\n\nThe threat model also addresses the risk of stolen pairing codes. If someone learns the pairing code, they could try to pair the devices. The first device must manually approve every request, which requires careful attention from the human user.\n\nAnother potential threat is replay attacks, where someone records a message and sends it again later. Each message includes a counter, and old counters are rejected even after a restart.\n\nThe model also covers the possibility of an unpaired device asking for records, which the sync endpoint rejects. Even when sync is disabled, the network listener stays open, listening for pairing and sync requests. This listener remains open while the app is running. The app does not currently support attachments, and testing is limited to a few routers, VPNs, and corporate networks. A security review by an outside expert is also recommended.\n\nThe writer notes that their understanding of the app's \"disabled\" state has changed. In the app, \"disabled\" means it refuses requests, not that it stops listening. They plan to fix this so the listener only runs when sync is turned on. If anyone discovers a flaw, they are asked to report it through the repo's SECURITY.md, rather than opening a public issue.",
  "summary": "I'm new to programming & have been teaching myself security by building things and then poking at my own assumptions. This is a simple threat model for one feature of Wildlife Incident Handoff , it's an opensource Windows app for recording wildlife incidents and handing them off between people. Now the feature is LAN sync : I wanted to make it so two paired devices on the same local network can…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}