M4.01.6headphones privatize output not inputdesignresearch

Headphones privatize the reply, not the request

Aliases: private listening public speaking · headset covers the speaker only

What it is

In an elevator, through headphones: “navigate to 14 Maple, apartment 3B.” The reply stays in the ear canal; neighbors miss flight numbers and message bodies. The request with the unit number still leaves the mouth. Headphones privatize output not input. Writing “headset support” as if it had solved public voice privacy repairs half the chain. The broadcast of output is cut. Input remains a sound source aimed at the room.

Why it happens

Consumer hardware already knows how to take the loudspeaker out of the room: wired, wireless, bone conduction — synthetic speech becomes a near-ear event. There is no peer product on the input side. The vocal folds and the mouth are radiators attached to the speaker; headset mics, ANC, and beamforming change the SNR the device hears, not the oral sound the neighbor hears. Breath voice and lip movement also leave the visual mark of “talking to a machine” on the face. Headphones are an engineering fix for output, not a privacy fix for public dialogue. If, with a headset on, the prompt still says “please say the destination” with a full slot, the remaining exposure is concentrated on the end the user must still speak.

Studying it

Within-subject headset on/off: the same address-bearing dialogue, a neighbor (or confederate transcriber) reports which slots they caught from the reply and from the request. Output-side slots should drop with headphones; input-side slots should barely move. Add a “headset only, no rephrasing” condition and watch whether people spontaneously switch to typing — behavioral evidence that the input-side cost is still there. Measure oral sound pressure at the neighbor’s distance; do not only measure headset leakage. Leakage is unfinished output work. Oral sound is input the headset never changed.

Where it stops holding

A sealed mask, a throat mic, or true whisper recognition that pushes oral sound below neighbor intelligibility does change the input side — those are other devices, not ordinary headphones. Two people sharing one headset break output privacy again. Open-ear leakage can give the output-side gain back, looking like “they had headphones and I still heard it,” with the cause still on output. Fully silent visual or key input makes the headset irrelevant. In an elevator the social mark of opening the mouth remains even with headphones; that is a separate bill.

Applying it

  • On detecting a headset, route replies to the ear only, and switch to a shorter spoken grammar or on-screen slots so the user is not forced to broadcast an address again.
  • Settings and marketing must not write “put on headphones and voice is private in public” as a complete privacy claim. State that people nearby can still hear what you say.
  • For slots that still require speech, prefer a keyboard or a map pick once a headset is on, instead of chasing “please say the full address.”
  • How to check: finish a navigation dialogue with headphones in an elevator. The bystander should write down no slots from the reply and should still be able to write the destination unit — if the second holds, the “headset solution” has not covered input, and a silent slot path is required.

Related

  • Same group: M4.01.1 Speaking to a dialogue system hands the content to everyone in earshot · M4.01.2 Addressing a device in public is still socially marked · M4.01.3 Social cost drives people to abandon voice in public · M4.01.4 Bystanders pay a cost for being forced to overhear · M4.01.5 Spoken replies leak more than spoken commands
  • Nearby: M3.05 Voice and screen complementarity · C7.17 Switching between voice and keyboard · C7.07 Privacy visibility of voice input
  • Search terms: headphones privatize output not input · private listening · spoken request still public

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/M4.01.6