A Practical Privacy Threat Model for Consumer Companion Robots

Step 1: Draw the data-flow boundary

Start with five boxes:

• Physical robot - sensors, actuators, local storage and firmware.
• Home network - router, local discovery and other smart devices.
• Companion app - phone permissions, account tokens and local caches.
• Vendor cloud - APIs, inference, storage, analytics and update services.
• External parties - subprocessors, support tools and integrations.

For each sensor event, draw where the data moves. A microphone event might be buffered locally, transmitted for speech-to-text, retained as a transcript, passed into a language model and logged for diagnostics. The privacy impact depends on the complete path, not merely on whether the robot “has a microphone.”

Step 2: Classify the data

Use categories that reflect harm rather than implementation convenience:

• Ambient media: audio, images and video that may include bystanders.
• Identity data: face templates, voice profiles, names and account identifiers.
• Behavioral data: routines, preferences, interaction history and inferred mood.
• Home data: floor maps, object detections, Wi-Fi metadata and device inventory.
• Operational telemetry: errors, battery state, motor performance and usage logs.
• Sensitive context: health reminders, child interactions or private conversations.

The same field can change sensitivity through combination. A timestamp is ordinary telemetry until it is paired with a face identifier and a room location.

Step 3: Test the trust assumptions

For every flow, ask four questions:

Is transmission necessary? Could the task be completed locally? Cloud processing can be justified, but necessity should be explicit. Wake-word detection, obstacle avoidance and simple touch responses are common candidates for local execution.

Is collection visible? People near the robot should be able to tell when a camera or microphone is active. Hardware indicators are stronger than an app-only status because guests may not have the app.

Is retention bounded? “Stored as needed” is not a useful boundary. Look for a retention duration, deletion trigger or user-configurable history setting. Diagnostic logs and model-improvement datasets should be treated as separate purposes.

Is the user in control? A privacy control should be reachable, understandable and testable. Useful controls include hardware mute, per-sensor toggles, history review, export, deletion and account removal. Document what functionality is lost when a control is used.

Step 4: Model realistic failure cases

The most useful threats are concrete:

• A guest is recorded without noticing the active sensor.
• A compromised account exposes interaction history or live controls.
• A support workflow grants broader data access than expected.
• A third-party SDK receives identifiers unrelated to its function.
• A discarded robot retains tokens, maps or user media.
• A cloud shutdown makes local privacy controls inaccessible.
• A child profile inherits adult defaults.

For each case, identify prevention, detection and recovery. For example, secure device reset prevents residual data; an account dashboard detects active sessions; token revocation supports recovery after resale.

Step 5: Evaluate graceful degradation

Security and product resilience overlap. Ask what happens when the robot cannot reach the vendor cloud:

• Does it fail closed or repeatedly transmit queued data?
• Which essential functions remain local?
• Can the owner still reset or delete the device?
• Are safety functions independent of remote inference?
• Does the app explain the degraded state clearly?

A cloud outage should not create an ambiguous sensor state. The user needs a visible, predictable answer.

A compact review table

The buyer-facing translation

Technical reviewers can help consumers by turning the model into a short set of questions: what is sensed, where it is processed, how long it is kept, who can access it, and what still works offline. I edit Robot Companion AI, where we translate these architecture questions into practical evaluation criteria for nontechnical readers.

Disclosure: I edit the linked publication. The threat-modeling method and table above are provided in full here.