The short answer

Treat marketing claims as unreliable. Assume a pair listens continuously unless it has a visible hardware LED, a physical mute or hard switch, and clear documentation that the wake‑word runs on the glasses themselves. If you cannot verify those three signals, choose a push‑to‑talk model or return the device.

Time needed about 90 minutes, done in one session

Key takeaways
  • Visible hardware indicators, a physical mute, and explicit on‑device wake‑word documentation are the only reliable trust signals.
  • A short home checklist of visual checks, app/OS permissions and a hotspot test reveals most always‑listening behaviour.
  • Cloud wake‑word processing raises the risk that audio leaves the device before you consent; require vendor confirmation if unclear.
  • If you cannot verify behaviour, demand written proof, return the glasses, or pick a push‑to‑talk design.
  • Network tethering catches unexpected outbound audio even when apps hide activity indicators.
Before you start
  • The smart glasses and their companion app installed on your phone
  • The phone you use to pair the glasses and create a hotspot
  • Charger or charged batteries for both phone and glasses
  • A quiet room for wake‑word and silent‑speech tests
  • A browser or link to the vendor's support and privacy pages

The steps

  1. Inspect the frame for an LED or muteUnbox the glasses, place them in bright light and look along the temples and bridge for an LED, a labelled mute switch or a removable cover.You should see: You can point to a visible LED, a labelled mute switch, a removable cover or confirm none exist.
  2. Locate microphone holesExamine the frame for tiny hole clusters and compare their positions to the manufacturer diagram on the device page.You should see: You identify one or more small hole groups that match the vendor diagram and can mark them on the frame.
  3. Pair the glasses and open the companion appPower on the glasses, pair them with your phone, then open the companion app and go to its device or settings screen.You should see: The app shows the glasses as connected and displays device settings or status.
  4. Check phone microphone permissionsOn iPhone open Settings > Privacy > Microphone; on Android open Settings > Apps > [app] > Permissions > Microphone and observe the app's microphone status.You should see: The phone shows whether the companion app has microphone permission and whether background access is allowed.
  5. Toggle wake‑word or push‑to‑talk in the appFind voice or assistant settings in the companion app and turn off any 'wake word' option or enable 'push to talk' if available.You should see: The setting in the app UI changes state and the app confirms the change or prompts for a reboot.
  6. Trigger the assistant and watch for indicatorsSpeak the documented wake word with the glasses powered and watch for an LED, a spoken response or a visual cue in the app.You should see: You see the LED light, hear the assistant, or see a specific capture indicator in the app when the wake word is spoken.
  7. Revoke microphone permission and test silenceRevoke the companion app's microphone permission in the phone settings, then speak a short sentence without the wake word.You should see: After revoking permission, the assistant does not respond and no LED lights during your silent sentence.
  8. Tether the glasses to a phone hotspot and watch dataTurn off other devices, enable your phone hotspot, connect only the glasses, record five minutes of baseline data, then speak without the wake word and watch for data spikes.You should see: You see a low baseline; any data spike when you did not trigger the assistant indicates outbound traffic linked to the glasses.
  9. Test offline in airplane modePut the glasses into airplane mode or otherwise remove their network access, then speak the wake word and listen for a response.You should see: If the assistant does not respond, the device requires cloud services; if it responds, some processing runs locally.
  10. Request written confirmation or decideDocument any unexpected behaviour and contact vendor support asking whether wake‑word processing runs locally and whether audio is sent before user confirmation; if you do not get a clear written answer, return the device or choose a push‑to‑talk model.You should see: You receive a written vendor response or you have a documented record to use when requesting a return.

How to tell if glasses listen all the time

When you have the glasses in hand, prove whether the microphone is idle or active by checking hardware indicators, app and OS permissions, and quick network behaviour tests. We treat a visible LED, a physical mute and explicit on‑device wake‑word documentation as the minimum signals of transparency; otherwise run the verification steps below.

If you want to compare companion apps for a specific model, check our apps directory and the device pages we link to for vendor diagrams and support material.

Quick visual and physical checks you can do now

Find hardware you can see and touch. A visible LED that lights when audio is captured, a labelled mute switch, or a removable cover are the clearest sign the vendor gives you control without relying on software. Verify any small LED lights during an actual assistant trigger.

Put the glasses in bright light and inspect the temples and bridge for tiny hole clusters, buttons and engraved icons. Match what you see to the manufacturer diagrams on the device page before you power the glasses on.

  • Find any physical mute, switch or removable cover — expect it to move without force.
  • Locate mic holes — small groups of holes are more likely microphones than vents.
  • Note any LED position before powering on so you can watch it during tests.

Where to check in the companion app and phone OS

Open the companion app and the phone's permission screens to find explicit microphone controls, wake‑word options and background microphone status. Those screens show whether the vendor gives you real control or hides listening behind broad permissions.

On iPhone go to Settings > Privacy > Microphone and check the app list. On Android go to Settings > Apps > [companion app] > Permissions > Microphone. Inside the companion app look for settings labelled 'wake word', 'push to talk' or 'background listening' and toggle them to confirm the UI takes effect.

  • Verify the companion app appears in the microphone permission list.
  • Find any 'wake word' or 'push to talk' setting and toggle it for a test.
  • Inspect Bluetooth and call permissions as they can enable audio streaming to the phone.

A simple live test you can run at home

Run a short set of checks: trigger the assistant and watch for an LED or sound, revoke microphone permission and try again, unpair or mute and test, and speak a normal sentence without the wake word. These actions catch most always‑listening behaviour without developer tools and take under 15 minutes.

If the assistant responds after you revoke microphone access or after you mute or unpair the device, treat that as evidence the glasses are listening in a way you cannot control.

  • Speak the wake word and note any LED or spoken response.
  • Revoke microphone permission and test the wake word again.
  • Unpair or use a physical mute and test; absence of response is expected.

How to tell whether wake‑word runs on the device or in the cloud

On‑device wake‑word processing keeps raw audio inside the glasses until you trigger the assistant. Cloud wake‑word detection sends short audio snippets to a server, which increases the chance your speech leaves the device before you consent. You must know which method the vendor uses to assess privacy risk.

Search privacy FAQs and support pages for phrases like 'on‑device wake word' or 'processed locally'. If the wording says audio is 'sent for processing' or 'streamed to the cloud', assume cloud processing and require stronger controls and network checks.

  • Look for explicit 'on‑device' wording in the privacy policy or FAQs.
  • If the vendor says 'audio sent only after keyword', prefer that device.
  • Ask support: 'Does wake‑word processing occur locally on the glasses?'

Network checks anyone can run to detect outbound audio

Tether the glasses to your phone hotspot or a travel router and watch for unexpected traffic. If audio is sent to the cloud you will usually see brief outbound connections after speech or steady background traffic when the device claims to be idle.

Turn off other devices, record a five‑minute baseline, then speak without the wake word and watch for spikes. Trigger the assistant and compare the spike sizes. Any data used when you did not trigger the assistant indicates background outbound audio.

  • Use a phone hotspot and record baseline data for five minutes.
  • Speak without the wake word and watch for data spikes.
  • Compare data used on a triggered assistant response versus silence.

When you can’t verify: what to demand and short mitigations

If the hardware lacks an LED or mute and the vendor will not confirm on‑device wake‑word, insist on written documentation stating when audio is transmitted. If the vendor refuses, return the device or choose a push‑to‑talk model.

Short‑term mitigations include revoking microphone permission when not using the glasses, covering mic holes with tape, or storing the glasses in a privacy case to block radios. Treat these as temporary workarounds, not fixes.

  • Demand written confirmation of where wake‑word runs and when audio is sent.
  • Disable microphone permission when not using the device.
  • Use a privacy case or cover mic holes only as a temporary measure.

How manufacturers hide listening in practice

Manufacturers can combine vague permissions, small or hidden LEDs, and firmware updates that add cloud features without clear notice. A user grants broad permissions at setup, then a later update enables background audio uploads while the indicator remains unseen.

Verify LED behaviour during visual tests, recheck permissions after updates, and ask vendors for changelogs if behaviour changes after a firmware push.

  • Opaque permissions granted at setup allow persistent background audio services.
  • Firmware updates can change behaviour without clear user notice.
  • Poorly placed LEDs give false reassurance unless verified during tests.

Where this usually goes wrong

  • Assistant responds when you speak without the wake wordThe device listens without a visible indicator or the indicator is poorly placed or too dim to notice.Repeat the visual test under bright light, ask the vendor for a video showing the indicator during capture, and return or replace the device if they cannot provide clear proof.
  • App still uses the microphone after you revoke permissionA background service or companion firmware communicates directly and bypasses OS permission dialogs.Unpair the device immediately, document the behaviour, and demand written vendor confirmation before using it again.
  • Hotspot shows persistent outbound traffic while glasses are idleBackground streaming, telemetry or periodic audio upload running even when idle.Disable network access (airplane mode), revoke permissions, store the glasses in a privacy case and ask the vendor for an explanation.
  • Firmware update reactivates cloud assistant after you disabled itVendor pushed an update that reset settings or added cloud features without clear disclosure.Lock down automatic updates if possible, retest after updates, and insist on a changelog before accepting future updates.

The checklist

  • Inspect the frame for an LED or mute
  • Locate microphone holes
  • Pair the glasses and open the companion app
  • Check phone microphone permissions
  • Toggle wake‑word or push‑to‑talk in the app
  • Trigger the assistant and watch for indicators
  • Revoke microphone permission and test silence
  • Tether the glasses to a phone hotspot and watch data
  • Test offline in airplane mode
  • Request written confirmation or decide

Frequently asked questions

Can I trust vendor marketing that says 'only listens after wake word'?

No. Treat marketing as a claim, not proof. Verify with a visible LED, a physical mute and documentation that wake‑word processing runs on the glasses. If those signals are absent, run the visual tests, app/OS permission checks and network tethering described here and ask support for written confirmation.

Will airplane mode prove whether the assistant uses the cloud?

Partly. If the assistant stops working in airplane mode it likely requires network access. If it continues to work, at least some processing runs locally. Combine airplane mode with a hotspot traffic check, because devices can work offline in some states while uploading audio at other times.

Are there safe models I can trust out of the box?

Models that advertise a hardware mute and explicitly state on‑device wake‑word are the most trustworthy out of the box. Prefer devices with vendor documentation or security whitepapers that match your tests. Check our device pages for notes on vendor transparency before you buy.

Does covering microphone holes reliably stop listening?

Not reliably. Covering mic holes can reduce or block capture, but many devices use multiple microphones or sensors and audio quality will degrade rather than stop entirely. Use covering only as a short‑term measure and seek a device with a physical mute for a long‑term solution.

What if my phone shows microphone use even when the app is closed?

That indicates a background process or service is using the microphone. Revoke microphone permission and test again. If usage continues after revocation, unpair the glasses, document the behaviour and contact vendor support for a written explanation before you keep using them.

Find apps that work on your glasses

Every app in the directory lists the glasses it runs on, how it works on each, and the official source that proves it.

Browse the app directory