Pet Camera Privacy Scorecard and Research Methodology

The scorecard measures public disclosure, not product security

A connected camera is more than a lens. The buyer may depend on hardware, firmware, an app, an account, cloud video, a subscription, household sharing, support, deletion, and resale or disposal workflows. NIST’s consumer-IoT profile supports evaluating the product ecosystem rather than hardware alone. FTC guidance for connected home cameras similarly tells buyers to examine encryption, updates, account security, remote access, and sharing controls before purchase.

This page asks whether current public records address sixteen buyer-relevant domains. It does not examine source code, network traffic, vulnerability exposure, incident history, access logs, deletion execution, or actual app behavior.

Read each status literally

Swipe horizontally to see all columns.

“Partial,” “not found,” and “conflict” identify different evidence problems and should not be merged into a single failing score.

The sample covers three camera ecosystems

The bounded sample follows the official product paths for Petcube Cam 360, Furbo 360° Dog Camera, and Wyze Cam Pan v3; it is not a census of the US camera market.

Swipe horizontally to see all columns.

Use each row only for the exact named product ecosystem and the dated documentation captured for it.

Disclosure summary

The counts below are inventory totals, not points. A product with more documented rows is not automatically more secure or private.

Swipe horizontally to see all columns.

The practical result is not “15 beats 9.” The result is that a buyer can see which exact questions are answered, incomplete, missing, or contradictory.

Full 16-domain documentation matrix

The matrix reconciles the current Petcube privacy record, Furbo privacy and security record, and Wyze privacy policy with the model-specific support records listed in Sources.

Swipe horizontally to see all columns.

Read across one domain at a time and investigate every partial, not-found, or conflicting cell before relying on that workflow.

Petcube exposes a useful support record, but policy freshness and MFA remain open

Petcube’s current documentation names Cam 360, explains Care history, describes separate family and friend accounts, exposes a privacy mode, publishes security statements, provides a vulnerability route, and lists Cam 360 security updates through December 31, 2028. Those are meaningful public disclosures.

The retained privacy policy is effective September 17, 2021, so data-use, third-party, rights, and permission findings stay partial rather than being treated as a fresh audit. The bounded official search did not locate a current Petcube MFA record. Its public delete-device workflow also does not fully establish account or backend-data deletion.

Furbo documents account security, but retention records need reconciliation

Furbo publishes two-step-verification guidance, vendor security statements, a product-security reporting route, firmware/support information, account deletion, camera on/off controls, and remove-device/reset steps. Its household-sharing guide is unusually explicit: family and friends use the same username and password. That makes the access model visible, even though it does not provide separate caregiver roles.

The critical problem is documentation conflict. Current official localized support records describe cloud-history retention differently, including a 24-hour framing and another record with one-, three-, or seven-day availability by plan or device. Until a current exact US product/plan record reconciles them, the scorecard stops on retention rather than selecting one statement.

Wyze has broad current documentation, but the exact model support date is missing

Wyze’s May 2026 privacy policy covers data categories, sharing, targeted advertising and user rights. Current support pages document two-factor authentication, separate-account sharing, a physical Privacy Mode, automatic Pan v3 firmware updates, VerifiedView, account deletion, fourteen-day Cam Plus cloud history, a vulnerability route, reset guidance, and service-status access.

The remaining critical gap is specific: the current security-support table did not list exact Wyze Cam Pan v3 on the checked date. A sibling camera’s date is not substituted. That leaves the product conditional even though the other fifteen domains have current public records.

Critical gaps and conflicts

The actions below follow the retained Petcube security documentation, the two conflicting Furbo retention records for deleting cloud recordings and viewing video history, and Wyze’s current security-support-period table.

Swipe horizontally to see all columns.

A critical conflict requires a current exact official answer; a missing record must not be replaced with a sibling model or a favorable assumption.

Use the result as a verification queue

Swipe horizontally to see all columns.

The scorecard is useful only when it produces a concrete verification queue and clear stop conditions.

This scorecard compares documentation depth, not the wider device category. For that architecture decision, read the pet camera versus indoor security camera comparison.

After the documentation screen, use the pet-camera household account security workflow to organize owner access, recovery, sharing, retention, incident response, and offboarding.

Policy capture must preserve version, locale, plan, and model

A policy URL alone is not a reproducible snapshot. The research record retains the owner, title, effective or source date where available, check date, locale or plan limitation, exact model scope, status, and direct URL. When an official localized page supplies a material fact, that locale remains attached to the finding.

A later policy or support-page change does not automatically invalidate the historical record, but it does require a fresh decision. Material changes regenerate the claim ledger, matrix, model inputs, results, public article, hashes, and QA.

Why the scorecard has no winner

Documentation completeness and implementation quality are different questions. A vendor can publish a detailed control that is inconvenient or weak. Another vendor may have an internal control that the bounded public search did not locate. A percentage would hide those distinctions and encourage false precision.

What we could not verify

• whether any documented control is correctly implemented, enabled by default, resistant to attack, or consistently enforced;
• camera, app, cloud, router, credential, encryption, access-log, deletion, update, reset, transfer, support, or incident behavior;
• complete Petcube account/backend deletion or current public MFA availability;
• one authoritative current Furbo retention rule for the exact US plan and device;
• a current comprehensive Furbo privacy/data-rights and app-permission record;
• the exact minimum security-support date for Wyze Cam Pan v3;
• breach frequency, vulnerability count, exploitability, response quality, compliance, or legal sufficiency;
• a complete United States market census or a universal best product.

Refresh the scorecard when the documentation changes

Recheck after a policy effective-date change, app/account migration, new plan, retention change, sharing redesign, support-period update, end-of-life notice, vulnerability-policy change, incident/status change, model replacement, or deletion/reset workflow update. A material change should update the versioned source register and model input rather than being patched into prose from memory.