Residents, guests, and children need different permissions

What it is

Permissions in a shared space are not "one account, one permission" but a layering of co-present roles — role-based access: residents, children, guests, and visiting service workers occupy different tiers of control. The layering is not gatekeeping for its own sake; it reflects three real dimensions — standing to be present, duration of stay, and capacity for responsibility. A guest may turn on a light but should not rewrite the security rules; a child may request a song but should not unlock the door.

This entry answers the structural question — which tiers a home needs and each tier's default scope. Which specific tier a given device sits at, and how guest credentials are issued and retired, are implementation decisions laid on top of this structure.

Why it happens

The home is physically open: anyone inside can reach the wall panel and talk to the speaker. Digital permissions govern only apps and remote entry — physical presence is itself a permission. Layering is therefore negotiated between two mechanisms, the physical (locks, keys, where devices are mounted) and the digital (accounts, PINs, voice recognition); designing only the digital layer leaves the tiering full of holes.

Each tier's characteristic failure mode sets its default. Guests: trusted (they were invited) but carry no ongoing accountability (no trace, no consequences) — so their permissions should be sufficient but never persistent. Children: capability grows with age and static permissions go stale — a limit set at 8 is wrong at 12; treating a child as a permanently low-privilege account freezes a judgement that no longer holds. Service workers (cleaners, repair): functional entry — permission should bind to the task's scope, not to the person. Residents: digital permissions should be near-equal, or the system becomes part of the household's power structure.

Studying it

• Large-scale access-control preference surveys (CHI 2018): users' smart-home permission preferences form stable tiers — household members and guests are clearly distinguished, persistent guest access causes widespread discomfort, and children's permissions are seen as an extension of parental duty rather than an independent account question.
• Field studies of parental-control products (described generically): repeatedly document "set once, never revisited" — limits configured on installation day, later neither relaxed with age nor reviewed with need.
• Variables: acceptable tier structures, default-permission expectations for various unfamiliar co-present persons, expected review cadence for children's permissions.

Where it stops holding

• The four-tier model assumes real households map onto it; blended families, tenants and landlords, live-in workers, and housemates all break the neat tiers. The design must allow custom roles rather than forcing people into four boxes.
• Jurisdiction matters: tenants' rights over premises and fittings are legally protected in many places, and an "owner is admin" default can conflict with the law in rental situations.
• The children's tier strains against development: teenagers need a graduated expansion path (unlocking with age); a single child role becomes an instrument of control by puberty, provoking resistance rather than cooperation.

Applying it

• Define roles by the triple standing × duration × responsibility, not by account type alone; bind guest permissions to presence — they exist while the guest is there and lapse at the panel when they leave — without issuing persistent digital credentials.
• Give the children's tier a review rhythm: a default each-term reminder ("are this role's limits still right?") turns "set and forget" into process.
• Offer service workers task-scoped permissions (which devices this visit may operate) instead of the all-or-nothing choice between full-home access and none.
• How to check: three months in, inventory the roles actually in effect — if the whole household shares one account or everyone is an admin, the tiering failed to carry reality; that is a design failure, not user laziness.

Related

• Same group: Z6.02.2 Permissions must be easy to grant temporarily and revoke · Z6.02.3 Concentrated admin control creates dependence
• Nearby: Z4.07 Multi-user and permission assignment · Z4.08 Guests and temporary authorisation
• Search terms: role-based access control · smart home multi-user · parental control · access tiers