Visitors and temporary occupants need a default policy
Aliases: unknown-user fallback · guest default policy
What it is
Every identification system inevitably meets people it cannot recognise: visitors, cleaners, couriers, a new flatmate, a family member not yet enrolled. The system must predefine what "unknown person present" means by default — treat them as nobody, as the owner, or as an intruder. All three defaults exist in real products, each with a distinct failure surface; and having no default at all (behaviour undefined, improvised on the spot) is the worst option, because it leaves the errors to luck.
The essence of a default policy: when recognition hits an undecidable input, the mapping from "don't know who" to behavioural consequences. Get that mapping wrong and the whole system's credibility collapses with it — an alarm blaring as a friend walks in, or a guest silently recorded, are both worse than having no smart features.
Why it happens
The failure surface of each default:
- Treat as nobody: visitor activity triggers nothing. Safety functions (security, fall monitoring) miss; energy functions misfire (guest in the living room, system reads "empty", kills the lights and heating).
- Treat as owner: the unknown person inherits full privileges and personalisation. Recognition error is amplified into open access and data disclosure — the most dangerous default, nearly guaranteed to fail in visitor scenarios.
- Treat as intruder: raise an alarm. Family and friends trigger sirens; repeated false alarms breed alarm fatigue and burn away the system's security value.
Temporariness compounds the problem: visitors stay briefly and there is no enrolment window (nobody enrols a face for an aunt staying two days), so the system lives in the "unknown person present" state for the whole visit — the default policy is not edge-case handling but the main path of the visitor scenario. Time of day couples further: an unknown person by day and at midnight, with someone home versus everyone away, want different defaults — a single global default is necessarily wrong in some combinations.
Studying it
- Multi-user access control research: smart home user studies (Zeng et al. 2017) find users want explicit control over "who can trigger what" and worry about unanticipated use by others — visitor handling is a stated user need, not a designer's invention.
- Scripted visitor scenarios: deployment studies use standard scripts (guest arrives, cleaner comes, courier enters) to test each default's behaviour per function, logging what "nobody / owner / intruder" each produces — the direct method for evaluating the default matrix.
- False-alarm research: studies of security products' alarm behaviour find users' embarrassment at "friend triggers alarm" coexists with fear of misses, so the policy must suppress both ends (state generally).
Methodological caution: evaluation of default policies must cover the time × home-occupancy combination matrix — testing one scenario (daytime guest, family home) misses the most dangerous combination (night, empty house, stranger enters).
Where it stops holding
- Defaults vary by function class; no system-wide default exists. Security leans toward alerting (low-intensity: a phone notification, not a siren), convenience leans toward ignoring, privileges are never inherited — per-class defaults beat one global default.
- "Owner approves on the spot" is not a universal solution. It presupposes the owner is present, notified, and willing to respond — it fails for people living alone, asleep, or away; approval is a layer over the matrix, not a replacement for it.
- Unrecognisability can be a design goal. Some contexts should renounce identification deliberately (a guest-room camera doing motion detection only, never identity) — "not recognising who" is a privacy-protective default, not a capability defect.
Applying it
- Write down the unknown-person default matrix: time of day (day/night) × home occupancy (someone/no one) × function class (security / convenience / privilege), one explicit behaviour per cell, reviewed by the whole team — every cell gets an owner.
- Security: unknown presence triggers a low-intensity alert (phone notification "activity detected", not a local siren) that the owner can escalate; convenience: ignore, hold state; privileges: never inherited — independent authentication required.
- Give the owner a lightweight guest-announcement entry: one tap to enable "guests tonight" mode (personalisation paused, alert sensitivity eased) — the cost of accommodating a guest compressed to a single tap.
- How to check: have someone never enrolled enter the space and verify each function's actual behaviour cell by cell against the declared matrix — especially the night-and-empty combination. Any undefined behaviour or mismatch is a defect.