Keeping raw data on the device, not the cloud, shrinks what could leak

What it is

The same capture yields different privacy exposure depending on where processing happens: raw data processed locally (on the device or a home gateway), with only conclusions emitted, exposes less than raw streams uploaded whole to the cloud. Processing location is a control variable of privacy exposure; the full architecture trade-off of local versus cloud (compute limits, hybrid designs, visibility to the user) belongs to another group of knowledge.

Why it happens

Exposure surface = the data's transmission path + storage locations + parties with access. Cloud processing lengthens all three segments: transmission gains a network leg (intermediaries, link metadata); storage gains a cloud-side copy (the vendor, lawful-access surface, breach surface); access gains the possibility of cross-service aggregation (linkage to accounts and other devices' data). Local processing shortens all three at once — data never leaves the house, and the set "who could obtain it" physically shrinks.

One necessary clarification: local processing reduces exposure, not capture — the sensors still sense; only the raw data never leaves the capture site. And the inference output itself may still go to the cloud (locally recognised "asleep", the cloud receives just "asleep") — event-level reporting is still exposure, only at a coarser granularity from raw stream to conclusion; the difference in breach surface is an order of magnitude, not a categorical one.

Studying it

• Preference measurement: smart home privacy research consistently finds users prefer local processing (state the phenomenon generally); sensitivity to "does the data leave the house" runs higher than awareness of "where the computation happens" — users care about the outcome and cannot verify the implementation.
• Traffic audits: packet-capture comparisons of what "locally processing" devices actually transmit are the direct method for verifying claims against implementation (a staple of independent security research, and the main way excess telemetry gets discovered).

Where it stops holding

• Local is not secure. Lateral movement inside a compromised home network reaches local data just as well; local processing shrinks the external exposure surface and provides no internal defence.
• "Local processing" is an unverifiable claim. Event reports often travel alongside telemetry; without third-party audits, users cannot distinguish genuine from nominal locality — the credibility problem is independent of the architecture itself.
• Compute and functional costs exist but belong elsewhere. Smaller local models, slower updates, fewer features — the full development of that trade belongs to the architecture group; what is fixed here is the single causal claim that processing location affects exposure.

Applying it

• Decide processing location per data type: raw streams (audio, video, fine-grained sensing) processed locally, uploading event-level conclusions only; whatever must reach the cloud is listed item by item with type, purpose, and retention.
• Treat "local processing" in procurement as a verifiable specification: the presence of independent audits, and whether the function survives disconnection, carry more information than marketing copy.
• How to check: run one traffic-capture session per device and reconcile what actually leaves against the privacy statement — any data type outside the statement is a mismatch; re-test after firmware updates.

Related

• Same group: Z2.05.1 Capture state needs a physically visible indication · Z2.05.2 People entering a space passively have not consented
• Nearby: Z6.07 Local versus cloud processing · Z2.01.2 Fusion raises confidence but amplifies privacy exposure
• Search terms: on-device processing · edge computing · data minimization · network traffic audit