Consumer Camera: Pre-Pairing Recording and Public Neighbourhood Watch
A consumer electronics company sells an indoor smart camera that streams video to a cloud service and uses on-cloud AI to detect people and pets. The camera has a default administrator password of 'admin', no forced change at setup, and uses a peer-to-peer relay that can be reached from the internet. The mobile app's privacy notice is a link to a 12-page legal document, and the camera begins recording as soon as it is powered on, before pairing. Clips are retained for 60 days by default and can be shared to a 'neighbourhood watch' feature that makes them publicly viewable by geographic area. A journalist found that a search for a street name returns clips from cameras in that area. The company wants to add fall detection for older users and is preparing a firmware release.
1. Analyze the default password, pre-pairing recording, and public neighbourhood watch against IoT security and privacy principles. Which issues are principle-level, not just configuration?
Read the worked answer
Reasoning. The default admin password is a secure-default and authentication failure. Pre-pairing recording means processing before transparency or consent. The public neighbourhood-watch geosearch turns private video into publicly viewable, location-linked data and exposes bystanders. These are principle-level: privacy by design and default, lawfulness, fairness and transparency, purpose limitation, data minimisation, security and accountability. Changing a password setting does not fix an architecture that records before pairing and publishes by street.
Conclusion. Treat the default password, pre-pairing recording and public sharing as design defects requiring redesign, not user-education fixes.
2. Propose a redesigned onboarding and default configuration that would satisfy ISO 27400 guidance without breaking the user experience.
Read the worked answer
Reasoning. Onboarding should establish consent and secure defaults before any capture. Use a QR-code or app-guided setup that creates a unique device credential or passkey; no shared default. Keep the camera and microphone off until pairing and an explicit privacy choice; present layered just-in-time notice, not a 12-page link; let the user choose retention and sharing. Disable geosearch by default; sharing should require authenticated recipients and preferably clip-level invites. Add MFA for account access.
Conclusion. Security and privacy defaults should be the path of least resistance; the user experience can be simple without being permissive.
3. The fall-detection feature would process health-related video. What additional privacy and security controls should be added before release?
Read the worked answer
Reasoning. Fall detection processes health-related video, a sensitive category. Add a DPIA, explicit consent, purpose limitation, on-device processing where feasible, short retention, access control and encryption. Exclude fall clips from neighbourhood watch and from model training without separate consent. Validate accuracy and provide human review, because a false negative is a safety issue. Signed firmware and secure update protect the new capability.
Conclusion. The feature needs a separate privacy and safety assessment before release; it cannot inherit the camera's existing defaults.