Guests never enter the setup flow

What it is

Account, privacy defaults, voice match, whether history is kept: these are decided in a setup flow the purchaser walks on unboxing day. Overnight relatives, dinner guests, a temporary babysitter never enter that flow. They have no account, never tapped agree, do not know which lamp means an upload, and have no social license to mute someone else’s furniture. Their speech still lands on a microphone that is already always-on, already running someone else’s policy. The problem is not the bystander on a street. It is the unset person inside the home.

Why it happens

Setup is a one-time, one-person ritual; always-on is a standing property of the room. Policy is bound to the host’s account; acoustic coverage is bound to the room; the two boundaries do not coincide. Guests bring a different felt rule — “I am talking in someone else’s house” — which guards against the host’s ears, not against cloud and history. They will not open the companion app. Asking “will this be kept” is rude while one is a guest. Muting is touching someone else’s furniture, socially costlier than speaking. So the guest’s data flow inherits the host’s defaults wholesale: a guest hits the wake word, a guest talks into an still-open session window, a guest’s address is used to call a car, all under the host’s current retention and personalization. When the host finished setup, the flow asked whether “you” agreed. It never asked about the people who will walk into this kitchen on Saturday.

Studying it

Split interviews into hosts and guests; do not recruit only primary account holders. Ask guests whether they know the device keeps speech, whether they can stop it, whether they mind their address being read from that mouth. Ask hosts whether they changed retention or muted when guests were over. Answers that fail to match are the coverage hole in setup.

In the field, watch an evening with guests: does anyone introduce the device, does anyone mute, do guest requests land in the host’s history. A lab that only lets “the user” complete setup designs the guest side away.

Where it stops holding

Long-term cohabitants who have enrolled their own voice are not guests. A hotel room that resets daily binds setup to the room rather than the purchaser; the hole has a different shape. Children in their own home are often treated as “household” rather than guests, yet they also never walked consent — another class of unset person, not to be covered by guest copy. When the guest brings their own already-awake phone, the liability boundary sits on the guest’s device, not on the host’s speaker.

Applying it

• Give the host a short path for “we have guests”: no history tonight, discard the buffer when the session ends. Do not send the host three settings screens deep to turn things off on a guest’s behalf.
• Before executing on an unenrolled voice, make it hearable in the room that this is running on the host’s account. Do not quietly add a guest’s address or number to the host’s recents.
• Put the people who will enter this room into the unboxing flow, not only the purchaser. Not asking is accepting the host’s policy for the guest.
• How to check: invite someone who has never seen the device to spend an evening. Can they stop capture without opening the host’s phone, and does one of their sentences appear in the host’s history. If they cannot stop it and it is kept, setup still covers only the buyer.

Related

• Same group: M4.07.1 Felt privacy and actual data flow come apart · M4.07.2 False wakes are the main destroyer of trust
• Nearby: C7.07 Privacy Visibility of Voice Input · M4.08 Multi-User Voiceprint and Account Switching · M4.02 Always-On Microphones
• Search terms: guests outside setup · incidental user · household bystander