Your voice typing app will type your password into a login box. Here is how to stop it

Ahmed Ibrahim — Wed, 21 Oct 2026 12:42:18 +0000

A dictation app has a simple job: you hold a key, say a sentence, and the text is typed into whatever window has focus. That is also its worst failure mode. Click into a login page, hold the key out of habit, say a few words, and they land in the password box. You cannot see them, a wrong word is invisible, and a copy of what you said has just been saved to the app's history.

VoxScribe, a free and open source dictation app for Windows and Android, has to make sure that never happens. Here is how the Windows side works, including the one bug that made the check look broken for browsers.

The rules were strict:

It must never raise an exception.
It must never make the hotkey wait.
It must not add a dependency to the installer.

Check 1: the classic Win32 password style

Old desktop apps and many Windows dialogs use a plain edit control with the ES_PASSWORD style. That check is cheap and instant, using only user32:

_ES_PASSWORD = 0x0020
_GWL_STYLE = -16

def _win32_focus_is_password() -> bool:
    user32 = ctypes.windll.user32
    info = _GUITHREADINFO(cbSize=ctypes.sizeof(_GUITHREADINFO))
    if not user32.GetGUIThreadInfo(0, ctypes.byref(info)) or not info.hwndFocus:
        return False
    class_name = ctypes.create_unicode_buffer(64)
    user32.GetClassNameW(info.hwndFocus, class_name, 64)
    if "edit" not in class_name.value.lower():
        return False
    style = user32.GetWindowLongW(info.hwndFocus, _GWL_STYLE)
    return bool(style & _ES_PASSWORD)

This is where most tutorials stop, and it is why most implementations are wrong. A browser does not use Windows edit controls. Chrome, Edge and Electron draw their own text boxes, so GetClassNameW returns something like Chrome_RenderWidgetHostHWND and the style check sees nothing.

Check 2: UI Automation knows

UI Automation exposes an IsPassword property on the focused element, and browsers set it for <input type="password">. The question is how to ask it from Python without bundling a COM library. The answer is raw vtable calls with ctypes. Two methods are all you need:

# IUIAutomation: IUnknown (0-2), CompareElements, CompareRuntimeIds,
# GetRootElement, ElementFromHandle, ElementFromPoint, GetFocusedElement (8).
_IUIAUTOMATION_GET_FOCUSED_ELEMENT = 8
# IUIAutomationElement: ..., GetCurrentPropertyValue (10).
_ELEMENT_GET_CURRENT_PROPERTY_VALUE = 10
_UIA_IS_PASSWORD_PROPERTY_ID = 30019

def _com_method(obj, index, *argtypes):
    vtable = ctypes.cast(obj, ctypes.POINTER(ctypes.POINTER(ctypes.c_void_p))).contents
    prototype = ctypes.WINFUNCTYPE(ctypes.HRESULT, ctypes.c_void_p, *argtypes)
    return prototype(vtable[index])

One trap in the result: IsPassword comes back in a VARIANT, and a VARIANT_BOOL uses -1 (0xFFFF) for true, not 1. Compare against zero after masking, or every password field reads as false:

is_password = value.vt == _VT_BOOL and (value.value & 0xFFFF) != 0

The bug that looked like a failed check

In Edge, the check said "not a password field" on a login page, even though the password box was right there.

The cause: Chromium builds its accessibility tree lazily. The very first time a UI Automation client asks, the focused element is just the bare window Pane, not the text box. The second question, a moment later, returns the real element. That first answer looked exactly like "this is not a password field".

The fix is small: if the first answer is not a password but the element is a bare pane, wait 150 ms and ask once more.

is_password, is_pane = cls._ask_focused(automation)
if not is_password and is_pane:
    time.sleep(_CHROMIUM_WAKE_SEC)   # 0.15
    is_password, _ = cls._ask_focused(automation)

Later questions are answered immediately, so the retry only costs time once.

Making sure it never blocks

UI Automation calls can stall for seconds when the target app is hung. A dictation hotkey cannot wait on that. Three decisions keep it safe:

Its own thread with its own COM apartment. Every question goes to a worker thread and waits at most 0.5 seconds.
A busy flag. If the worker is still stuck on an earlier question, a new one returns immediately instead of queueing behind it.
Skip our own window. Asking UI Automation about the app's own window from inside the app waits on the app's own busy UI thread. So if the foreground window belongs to this process, the check is skipped.

What happens when it says "password"

The first check runs as soon as the text comes back from the speech model, before anything is shown or saved. If it reports a password field, the text is not typed, and it is not written to the transcript or the history either. A spoken password never reaches the disk. A second check runs just before typing, after the target window is refocused, and it stops the typing if focus moved into a password box in the meantime. At that point the text is already in the history, so that second check protects the box but not the log.

The trade-off I would like your opinion on

A timeout counts as "not a password field". That is fail-open: a slow or hung app loses this protection for that moment, and dictation still works. The alternative is fail-closed: if the check cannot answer in time, refuse to type. That is safer for passwords and much worse for everyone dictating into a slow app.

I chose fail-open because a dictation tool that randomly refuses to type gets uninstalled, and the check answers in time in nearly every normal case. But I am not sure it is right. Would you fail closed?

What it does not cover

It trusts what apps report. A custom-drawn control that never sets IsPassword, and anything inside a remote desktop or virtual machine window, looks like an ordinary field from the outside. On Android the equivalent is the accessibility service reporting that a node is a password field, and the floating button simply hides there.

The code is in core/password_field.py if you want to read it in full or send a pull request, especially from an app where it gets the answer wrong. This article and the code were written with Claude Code as an assistant, and the Edge behavior was found and fixed by testing in the browser itself.

What broke when I shipped a local Whisper dictation app to real Windows hardware

Ahmed Ibrahim — Sat, 03 Oct 2026 19:32:49 +0000

I built VoxScribe, a free, open source voice dictation app for Windows. You hold a hotkey anywhere, talk, release, and the text is typed into whatever app has focus. Speech recognition runs locally with faster-whisper, so the audio never leaves the machine.

The Whisper part was the easy part. Almost every real bug came from audio hardware and drivers. Here are the ones that cost me the most time.

The first was a Bluetooth headset that recorded near silence. On my machine the sounddevice library picked a default input device that landed on an MME driver, and for my headset that produced audio so quiet that Whisper transcribed almost nothing. The same physical microphone shows up several times, once for each Windows audio host API (MME, WASAPI and DirectSound), and they are not interchangeable. The fix was to ask for the WASAPI default input device explicitly instead of trusting the generic default. Same headset, usable level right away.

The second was a crash when forcing 16 kHz. Whisper wants 16 kHz audio, so my first version opened the microphone at 16 kHz. That worked on my headset, then failed with an invalid sample rate error on a laptop's internal mic running at 48 kHz. Some drivers just refuse a rate they do not support natively. The fix was to record at the device's own native rate and resample to 16 kHz in software afterward. Plain linear interpolation is not audiophile quality, but for speech going into Whisper it was good enough, and it has worked on every device I have tried so far.

The third was dropping voice activity detection. My original design was fully automatic: run a voice activity detector (Silero VAD) on the live stream, start a segment when it hears speech and stop when it hears silence. On quiet or variable input, like a compressed Bluetooth headset, the detector's confidence was inconsistent. Worse, false triggers did not just miss words, they sent background noise to Whisper, and Whisper does not fail quietly on noise. It makes up plausible sentences. I switched to hold-to-talk, so the user decides when speech starts and stops and there is nothing to guess. I kept the VAD code in the repo but it is no longer used in the live path. Letting faster-whisper's built-in VAD trim silence inside a finished clip turned out to be enough.

There is also a known weakness in any design that opens the mic when you press a key: the stream takes a moment to start, especially on Bluetooth, so the first word can get clipped. I added an opt-in mode that keeps the stream open and holds the last half second in a small in-memory buffer, so a recording starts with audio that is already there. It is off by default, because an always-open mic means Windows shows the mic as in use all the time. Nothing is saved or transcribed unless you press the hotkey.

If I had to give advice to anyone building something like this: test on at least three different microphones before you trust anything, never assume a sample rate, record at the native rate and resample after, and expect the AI part to be the smallest source of bugs.

The project is MIT licensed if you want to read the capture code or try it: https://github.com/ahmedhmam1994/voxscribe-ai-voice-dictation. It is Windows only for now, since that is the machine I can test on. I used AI coding assistance while building it, and I tested every fix on real hardware myself. Issues and feedback are welcome, especially from people with unusual microphones.

DEV Community: Ahmed Ibrahim