Local processing lowers exposure risk but caps capability
Aliases: edge computing · local-first · on-device inference
What it is
On-device (edge) processing keeps data inside the home network — inference, recognition, and storage all happen on the device or a local hub. Its privacy gain is structural: with no remote copy, the cloud-side attack surface ceases to exist. Its cost is equally structural: home hardware offers limited compute, memory, and power budgets — enough for lightweight recognition, not for large models; without cross-user data, model quality and personalisation ceilings are lower.
This entry is the first axis of the trade-off: capability grows as data moves out, and so does risk — local processing sits at the "low risk, low capability" end.
Why it happens
Why does localisation genuinely reduce risk? Because exposure scales roughly with the number of reachability paths, and localisation removes paths wholesale:
- Data never leaving the LAN means every path tied to a remote copy — stolen cloud credentials, platform breaches, insider abuse, data transfer in acquisitions, legal demands — does not exist. What remains is narrow: intruding into the home network, or physical access to the device.
- No remote copy also changes the response window: a local leak is a single-household event, discoverable and containable at household scale; a cloud leak is a bulk event in which the user is powerless at the moment it happens.
The capability limits are equally physical:
- Compute and power: a local NPU runs quantised small models — person detection, wake words — fine; heavier tasks (long-audio transcription, multi-camera re-identification, large-model dialogue) either do not fit or blow latency budgets.
- No cross-user learning: clouds keep improving models on all users' data; a local model ships frozen, so accuracy and scene adaptation top out lower.
- No off-site redundancy: destroy the device, destroy the data — a privacy virtue (true deletion is trivial) and a reliability vice (the only copy of the footage left with the stolen camera).
Studying it
- Architecture trade-off benchmarks: run the same recognition task on-device and in the cloud, comparing accuracy, latency, and power; then threat-model both architectures and compare attack surfaces. Systems and HCI communities both produce such studies, typically to quantify "how much capability the privacy loss buys".
- In-home usability studies: configure the same product in pure-local and cloud modes for households over months, tracking functional failures, satisfaction, and trust — measuring whether "capability caps" are even perceptible in real use.
- Covert-exfiltration audits: for devices claiming to be local, capture all outbound traffic (telemetry, DNS, heartbeats, crash reports) and compute the share that is "local in name, exfiltrating in fact" — the key method for testing whether local claims hold.
One methodological caution: the local-versus-cloud accuracy gap is not a constant — quantisation techniques and consumer NPU specs keep moving, so comparisons must pin hardware and model versions; stale benchmarks mislead procurement.
Where it stops holding
- "Local means safe" is too coarse. Home networks get breached (cameras as pivots are a mature attack pattern) and firmware flaws exist locally too; the gain is deleting cloud paths, not immunity.
- The privacy gain presumes data truly stays home. Telemetry, crash uploads, DNS queries, and time sync are covert channels — a "local" product with these channels earns discounted credit, itemised only after an audit.
- The capability cap is a moving line. Dedicated NPUs move last year's cloud-only task on-device this year; "is local enough" must be answered on current hardware, not on remembered impressions.
Applying it
- Allocate processing by data sensitivity: high-sensitivity streams (raw audio/video, continuous physiological signals) processed locally by default; low-sensitivity streams (aggregate statistics, device state) may go to cloud for capability.
- Local mode must be a complete loop: with the internet cut, core functions (recording, detection, local playback) survive fully — local is not a crippled tier; "detection local but footage stored in cloud" must be presented as hybrid, not local.
- Audit the exfiltration surface: place the device in an isolated segment, list every outbound connection and account for each; block the unexplained ones and observe what functionality is lost.
- How to check: a disconnected-internet run (core-function survival checklist, item by item) plus traffic capture in the isolated segment (no unexplained outbound flows). Both pass, and the local claim stands.
Related
- Same group: Z6.07.2 Cloud processing is more capable but enlarges the transport and storage attack surface · Z6.07.3 Hybrid architectures must pin down which data types never leave · Z6.07.4 The choice of processing location must be visible, not hidden
- Nearby: Z6.05.4 Storage location determines the actual risk of exposure · Z4.03 Losing connectivity and degraded operation
- Search terms:
on-device processing·edge computing·local-first·privacy