Wake words and privacy: what always listening really means
A wake word is a short phrase a voice device listens for locally so it knows when to start real listening. Always listening usually means a small on-device detector is running in standby, not that everything you say is recorded, but the difference matters and honest products state it plainly. The privacy questions that decide everything are where detection runs, what is streamed after activation, and what is retained.
How wake-word detection actually works
A device with a wake word runs a small acoustic model, often called a keyword spotter, on the device itself. In standby, the microphone feeds a rolling buffer of a few seconds of audio into that detector. The detector can do exactly one thing: score how closely the incoming sound matches one trained phrase. Audio that does not match is overwritten as the buffer rolls. When the score crosses a threshold, the device activates: it opens a session with a much larger speech recognizer, usually in the cloud, and starts streaming audio to it. Apple documents this two-stage design for Siri, and Google documents it for Assistant devices: standby processing happens on the device, and snippets that contain no activation are discarded rather than sent.
The wake word is therefore a switch, not a transcript. The privacy boundary is the moment the switch flips. Before it, the device is matching a sound shape locally. After it, your actual words travel to a server that can transcribe anything.
What always listening really means
The phrase always listening collapses four different stages into one scary claim. Separating them is how you evaluate a product honestly.
| Stage | What the microphone does | Where the audio goes |
|---|---|---|
| Standby | Feeds a rolling buffer into a local wake-word detector | Nowhere; non-matching audio is discarded on the device |
| Activation | The detector matches the wake phrase | Often a short pre-trigger buffer plus the request begins streaming |
| Active listening | Captures your request | A speech recognition service, usually the vendor's cloud |
| Retention | Nothing; this stage is about storage | Audio or transcripts may be stored under the vendor's policy |
A device can be always listening in stage one and still never send standby audio anywhere. It can also quietly retain everything from stage three onward. The words always listening do not tell you which product you are holding; the architecture does.
The plugged-ears pattern
A useful mental model for on-device wake-word detection: a doorman with plugged ears. He cannot follow your conversation. He can feel exactly one knock pattern through the wall, and when he feels it, he unplugs his ears and starts paying real attention. Everything before the knock is vibration he cannot interpret and does not keep.
The pattern is sound, but three things can break it in practice:
- False accepts: a phrase on television or a similar-sounding name flips the switch, and audio you never meant to send gets streamed.
- Pre-trigger buffers: many devices include the second or two of audio before the wake word in the upload, so activation reaches slightly backward in time.
- Cloud verification: some systems double-check the wake word server-side, which means borderline activations send a snippet even when the final answer is no.
None of these break the pattern silently in an honest product. They break it silently in products that never mention them. Whether a vendor documents its false-accept behavior is itself a strong privacy signal.
Where the web is different: browser speech recognition
Web apps that offer voice input mostly use the Web Speech API's SpeechRecognition interface. Here is the plain truth about it: on many browsers, recognition is not local. MDN's documentation states that in Chrome, using speech recognition on a web page involves a server-based recognition engine, so audio is sent to a web service for processing and recognition does not work offline. Some platforms can process speech on the device, but a web page cannot force that, and mostly cannot even verify which path was used.
This means a web app's honest voice-privacy claim is limited to what it controls: when the microphone is live, what it does with the transcript, and whether it tells you the rest plainly. Any web product that implies its voice input is fully private end to end is claiming something the platform does not let it guarantee.
How Violet handles the microphone
Violet is a private AI companion, currently pre-launch. Her web companion uses no wake word and no always-listening mode in this phase. The microphone is push-to-talk: it is live only while you hold the talk button, and releasing the button ends the capture and sends the final transcript through the same path as typed text. Pressing the mic also interrupts any reply Violet is speaking.
- No standby listening exists to audit: when the button is not held, no recognizer is running.
- The transcript shown is exactly what the browser's recognizer returned, trimmed and nothing more.
- Where the browser has no speech recognition, the button says so plainly instead of showing a fake listening state.
- Spoken replies are off by default and only turn on when you choose them.
- Because the companion runs in a browser and uses the browser's own SpeechRecognition, the recognition itself may be processed by the browser vendor's speech service. Holding the button controls when the microphone is live; it does not change where the browser processes the audio. Violet states this rather than hiding it.
A checklist for evaluating any voice product
Ask these questions of any product with a microphone, including Violet. A trustworthy vendor answers all of them in plain language.
- Where does wake-word detection run: on the device or in the cloud?
- What is buffered during standby, and is pre-trigger audio included when the device activates?
- What exactly streams after activation, and to whose servers?
- Is speech-to-text on-device or server-side? If server-side, run by whom?
- What is retained afterward: audio, transcripts, or both, and for how long?
- Are recordings ever reviewed by humans, and is that off unless you opt in?
- Is there a hardware mute or a mode where the microphone is verifiably off?
- Can you see and delete accidental activations?
- Does the vendor state its limits plainly, including the unflattering ones?
When a wake word is the right choice, and when it is not
Wake words earn their place when your hands and eyes are genuinely busy: driving, cooking, carrying things. In those moments a button is a real barrier and a well-built local detector is a reasonable trade. Push-to-talk is the better fit when the device is already in your hands, because it removes the hardest privacy questions instead of answering them: there is no standby stage, no false accepts, and no ambiguity about when the microphone was live.
Wake words also fail people who never consented: guests in your home, children, anyone within range of a shared room. A device that anyone can activate by saying a phrase is making a privacy decision for everyone present, not just its owner. If a product lives in shared space, look hard at its mute story and its activation history controls.
Questions
Does always listening mean everything I say is recorded?
Usually not. On most wake-word devices, standby audio feeds a small on-device detector and is discarded unless the wake phrase matches; recording and retention typically begin at activation. But the phrase itself guarantees nothing: check where detection runs, whether pre-trigger audio is uploaded, and what is retained afterward.
Does Violet use a wake word?
No. In the current phase, Violet's companion is push-to-talk only: the microphone is live while you hold the talk button and off when you release it. There is no standby listening. Violet is pre-launch, with a waitlist rather than live apps.
Is speech recognition in the browser private?
Not fully, on many browsers. MDN documents that Chrome's implementation of the Web Speech API sends audio to a server-based recognition engine. A web app can control when the microphone is live and what happens to the transcript, but it cannot make the browser's recognition local, and an honest product says so.