Is your phone listening to you?

What a wake word detector actually is

The microphone feeds a small always-on coprocessor that sits beside the main processor and draws a tiny fraction of its power. Running on it is a keyword spotting model: a neural network usually measured in tens or hundreds of kilobytes, which is orders of magnitude smaller than anything that could transcribe speech. It has no vocabulary. It produces one number, several times a second, for how closely the last moment of sound matches the one pattern it was trained on.

The sound it works on lives in a rolling buffer a couple of seconds long, overwritten continuously. Some wake-word designs use a short rolling audio buffer; details such as retention and storage behavior depend on the device and operating system. When the score crosses a threshold, a second and larger checker wakes on the main processor and re-examines the buffered audio to throw out false alarms. Only if that agrees does the phone light its microphone indicator and begin listening in the ordinary sense of the word.

A low-power detector may reduce energy use compared with waking larger processors continuously, but hardware designs and power costs vary by device. The design is shaped end to end by the goal of doing as little as possible until the pattern appears.

The wake word and the sentence after it are different systems

A wake-word detector and full speech recognition are distinct tasks. Speech recognition requires broader processing, which may run locally or remotely depending on the device and feature. In some designs, audio may be sent after a trigger for remote recognition; other implementations process it locally.

Some modern phones support local speech recognition for selected languages and configurations; other setups use remote services. The detector and the recognizer stay different systems, sized for different jobs, but both can now live on the device. Whether a particular assistant sends the transcript onward afterward is a separate design decision, and it is the one worth asking about. Whether the microphone briefly woke to hear a full sentence is not.

What continuous upload would mean for network traffic

As an illustrative calculation, at an assumed voice-call bitrate of 8–16 kilobits per second, an uninterrupted compressed stream would total about 2.5–5 gigabytes over 30 days, before protocol overhead. This arithmetic describes data volume only; it does not show that any feature transmits audio.

A network monitor can show that a device sent data and may show timing, volume, or destination, but encryption normally prevents it from revealing audio contents. Traffic patterns can be useful evidence, not proof of what was transmitted.

• Bandwidth: a continuous speech stream runs to gigabytes per phone per month, on networks that meter it.
• Battery: keeping a radio and an encoder awake around the clock costs hours of runtime, which people notice.
• Compute: speech recognition requires processing, but its cost varies by device, service, workload and implementation.
• Exposure: recordings of everyone are discoverable, subpoenable and leakable, which makes them a liability rather than an asset.
• Detection: the traffic is visible from outside the device to anyone with a router and some patience.

So where do the uncanny ads come from?

Ads can be targeted using signals such as browsing activity, location, purchases, or information shared by apps, depending on the service and its settings. An ad appearing after a conversation alone does not establish that a microphone was used.

Prediction does the rest. A system holding thousands of signals about hundreds of millions of people does not need to hear that you are planning a trip. It can infer it from people whose patterns resemble yours, and it will often be early rather than late. Frequently the conversation and the ad share a cause instead of one following the other: the same season, the same friend, the same thing you both saw last week.

And you only count the hits. Most people see hundreds of ads a day and remember almost none of them. The one that lands an hour after a conversation is the one that stays. Once the microphone is suspected, matches get noticed and misses stop being counted, so the pattern feels stronger every month on evidence that has not actually changed.

What is worth checking instead

Microphone permissions and system indicators can help show when an app uses the microphone. Current operating systems provide indicators and, on some devices, privacy reports or recent-use history. Exact controls and available detail depend on the operating system, device, and version. Reviewing those settings can help you investigate access.

False triggers are an implementation-dependent possibility. Some services may review audio samples for quality or safety under their policies; that does not establish how any particular wake-word feature handles false triggers. Check the device and service documentation for those details.

Underneath all of this is a question you cannot settle from the outside. A promise that audio is discarded is a promise about someone else's computer, and no amount of reading the policy makes it checkable. Local recognition removes the audio request to a remote recognition service for that feature. The app may still transmit a transcript or other data, so its broader network behavior remains worth checking.