C7.08.1False wake as privacy and function eventdesignresearch

A false wake is both a privacy event and a functional event

Aliases: false accept · unintended listening · spurious wake

What it is

A false wake (false accept) is keyword spotting opening engagement when nobody meant to call the device. It is two things at once. Functionally, the device starts listening and may even speak over what people were doing. As privacy, audio that should never have entered recognition is captured. Treating it as only an annoying misfire misses non-consensual recording; treating it as only a privacy incident misses that it is executing or interrupting ongoing activity.

Why it happens

Once the keyword-spotting threshold is crossed, the state machine takes the same path as a true wake: a lamp, audio into a buffer, possibly several seconds into ASR, and on some products a chime or spoken reply. Television dialogue, advertising slogans, and everyday near-neighbours are sources. Functional outcomes include interrupting music, placing a wrong order, or speaking into a quiet room; privacy outcomes include sending whatever was being said in the room into a cloud session. Both share one state jump, so logs, indicators, and stop controls must cover both. This is not a phonotactics discussion: that asks why the word is easy to collide with; this asks what happens after the collision.

Studying it

Log for long periods in rooms with media and multi-party talk: false-wake count, whether audio left the device, whether a transcript or an action was produced, whether the owner was present. Classify source (TV, guest, owner without intent). Interviews should ask both “were you startled or interrupted” and “did you know you were being heard then.” Having people deliberately say neighbours in the lab measures functional false alarms and not how long real privacy exposure lasts.

Where it stops holding

The user saying the wake word and then changing their mind is not a false wake. High trigger rates on demo units belong in a separate bucket. If on-device keyword spotting truly never sends audio off-chip, the privacy face shrinks; the functional face (speech, interruption) remains. A dictation keyboard with no speaker is a milder functional nuisance; capture can still occur.

Applying it

  • On a false wake, show a capture indicator as strong as a true wake, and offer one-tap stop that discards the buffer.
  • Incident taxonomies need two columns—“interrupted what people were doing” and “may have uploaded audio that should not have left”—and both need a response.
  • Accept with an overnight living room and a television on: count triggers with no user present, and whether audio left the device afterward.

Related

  • Same group: C7.08.2 False-wake records should be inspectable and deletable · C7.08.3 Reducing false wakes and reducing missed wakes are opposing goals
  • Adjacent: C7.01 Wake Words · C7.07 Privacy Visibility of Voice Input
  • Search: false wake · false accept · unintended listening

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/C7.08.1