A Practical Privacy Threat Model for Consumer Companion Robots

A companion robot is not one device from a privacy perspective. It is a small distributed system inside a home. The physical shell may contain cameras, microphones and touch sensors. A mobile app manages accounts and settings. Cloud services may handle speech recognition, language generation, media storage, analytics and updates. Support teams and third-party SDKs can introduce additional access paths. This article offers a lightweight threat-modeling method that developers, reviewers and technically curious buyers can use without needing access to proprietary source code. 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 Area Evidence to seek Warning sign Sensor activation hardware indicator and per-sensor control app-only or unclear status Data path architecture or privacy documentation generic “AI processing” language Retention duration and deletion mechanism indefinite or purpose-free storage Accounts MFA, session review and reset flow shared permanent credentials Offline behavior documented local capability essential controls require cloud access End of ownership factory reset and token revocation no resale or disposal procedure 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.