Free tool

How honest is your voice assistant?

Nine plain questions about the microphone, taken from our wake-word explainer and made answerable for any product you own. Everything on this page runs in your browser: the script behind it contains no network code at all, so your answers never leave the page, which you can verify by reading it. With JavaScript off, the whole audit still reads as a printable paper checklist.

One rule before you start: every question offers "the vendor does not say", and it always scores as the worst answer. Undocumented behavior counts against a product, because whether a vendor documents its behavior, including the unflattering parts like false accepts, is itself the privacy signal.

Axis 1

The microphone model

Answer from the vendor's own published documentation, not from what the product feels like. The sources section below lists where the major vendors keep theirs.

1. How does the microphone turn on? Only when you act: push-to-talk or an explicit tap, with no standby listening at all. A wake word you can fully disable, falling back to a button. A wake word you cannot turn off. The vendor does not say.

2. Is there a hardware mute, and does the vendor say how it works? A physical switch or button the vendor documents as cutting the microphone at the hardware level. A mute the vendor documents as software-only. No mute of any kind. The vendor does not say how its mute works.

Axis 2

Where wake-word detection runs

3. Where does the device decide it heard the wake word? On the device, and the vendor states that standby audio which contains no activation is discarded and never leaves. On the device, with cloud verification of borderline activations, and the vendor documents that those snippets are sent for that check. In the cloud: standby audio is processed on the vendor's servers. The vendor does not say.

Axis 3

What streams after activation

4. Once the device activates, what streams and to whom? Only your request audio, to servers the vendor names, and the session ends when you stop talking. Your request plus documented account or context data, with the recipients named. More than your request streams, and you cannot limit it. The vendor does not say what streams.

5. Is the vendor honest about its pre-trigger buffer? Most devices hold a rolling second or two of audio from before the wake word, and some include it in the upload. Yes: the vendor states how much audio is buffered in standby and whether pre-trigger audio is included when it uploads. The vendor acknowledges a standby buffer exists, but not whether pre-trigger audio uploads. The vendor says nothing about buffering.

Axis 4

Retention and human review

6. What is kept after a request: audio, transcripts, or both, and for how long? Nothing by default, or you can turn saving off entirely and set auto-delete. Audio or transcripts are kept by default, with documented retention periods and a working delete. Recordings are kept indefinitely and you cannot limit it. The vendor does not say what it keeps.

7. Are recordings ever reviewed by humans? Never, or only if you explicitly opt in, and the vendor says so plainly. Human review happens by default, but the vendor documents it and you can opt out. Human review happens and you cannot opt out. The vendor does not say whether humans review recordings.

Axis 5

Deletion and indicator honesty

8. Can you see and delete accidental activations? Yes: a reviewable activation history where you can inspect each recording and delete it, singly or in bulk. You can delete everything in bulk, but you cannot review individual activations. There is no deletion path. The vendor does not say.

9. Does the listening light reflect the real microphone state? The vendor documents the indicator as tied to the microphone at the hardware level: if the microphone is live, the light is on. The indicator is software-driven, and the vendor documents when it can lag or fail. The vendor does not say how the indicator relates to the microphone.

Your verdict

What your answers add up to

Answer the nine questions above to build a verdict.

The bands are rules, not measurements. Strong story: every answer is documented, none is the worst documented option, and at least five of nine are the good answer. Mixed: everything is documented but mostly weaker, or the microphone model is solid while retention, review, or deletion is weak or unstated on one or two questions. Poor or undocumented: anything else. This scores the vendor's documentation as you read it, never the device.

Printing keeps the checklist and your ticked answers and drops the site chrome. Nothing is saved: reloading the page clears every answer.

Read this part

What a checklist cannot verify

You are scoring the vendor's public documentation, not the firmware. That is worth doing, because documentation is the only privacy commitment a vendor makes in writing, but be clear about the limit: a questionnaire cannot detect false accepts as they happen, cannot see whether a pre-trigger buffer really uploads, and cannot catch cloud verification happening silently. Only the vendor's docs, independent audits, and its behavior over time can settle those.

One more caveat that applies to the web itself: web apps that offer voice input mostly use the Web Speech API, and on many browsers recognition is not local. MDN documents that Chrome uses a server-based recognition engine, so audio is sent to a web service for processing. A web page cannot force local processing and mostly cannot verify which path was used, so even an honest web product cannot promise local speech-to-text.

Sources

Where to look up real answers

These are the major vendors' own privacy documentation, linked so you can answer the nine questions from the source. They are pointers for your audit, not claims about any product's score.

Where Violet stands

How Violet answers question 1

Violet uses no wake word. Voice is push-to-talk only: the microphone is live while you hold the button and off when you let go, so there is no standby stage, no false accepts, and no ambiguity about when it was listening. That removes the hardest questions on this page instead of answering them.

The honest caveat cuts against us too: in a browser, Violet's speech recognition may run server-side, because the Web Speech API works that way on many browsers and a web page cannot force local processing. We say that plainly rather than implying otherwise. And the plainest limit of all: Violet is pre-launch, so today this is design intent you can read, not shipped hardware you can test.

The reasoning in full: wake words and privacy and voice UX and barge-in.