Dictation privacy

Technical reference synchronized with Yard’s source. File names and development commands refer to the native app repository.

Yard's native and browser dictation now share one promise: recognition starts only when local processing can be enforced. A missing capability, language pack, permission or Studio connection leaves the existing prompt intact and explains the next action. There is no remote-audio fallback.

Apple documents that requiresOnDeviceRecognition is honored only when supportsOnDeviceRecognition is true. Yard checks both availability and that capability before requesting permissions and again immediately before creating a recording session; each request unconditionally requires on-device recognition. The implementation uses the capabilities of the running system rather than assuming every language or OS supports them. Apple speech request, Apple recognizer capability.

The browser contract follows the Web Speech API's explicit local-processing controls, not the presence of SpeechRecognition or a browser brand. Yard sets and checks processLocally before starting; it does not install language packs automatically. Web Speech on-device specification explainer.

Native permission requests and transcription callbacks carry a generation. Closing a view, canceling while permissions are pending, navigating away or disabling Studio invalidates delayed callbacks. The microphone stops synchronously when Studio closes admission. Native text fields append to the existing prompt rather than replacing it. If the user edits the prompt while recording, dictation stops and keeps those edits.

External-browser recognition waits for Studio admission before calling start(). A generation-bound lifecycle SSE stream detects disable even if Studio is immediately re-enabled; interruption of that connection aborts recording too. Closing/hiding the page, sending the prompt, denied permission, manual edits and recognition errors also stop capture while retaining text. This is asynchronous notification over loopback (the server checks the generation every 200 ms), not an assertion of zero network-notification latency. Audio is never attached to the conversation; text is sent through the existing prompt flow only when the user sends it.

Verification

DictationTests injects recognition capabilities, delayed/denied permissions and a recording handle. It proves unsupported and disabled paths cannot reach capture, a locale is checked again after permissions, canceled approvals cannot start capture, interruption retains partial text, stale results are ignored, immediate end cannot resurrect recording and shutdown stops synchronously. Origin/frame checks are exercised separately. No test invokes the microphone or permission dialogs.

DictationWebTests executes the bundled UI in a real WKWebView with fake recognition and lifecycle sources. It covers unsupported browser/local language, local enforcement and selected locale, waiting for Studio, shutdown, denied browser permission, manual draft edits, native bridge dispatch and dismissal. Existing lifecycle subprocess fixtures cover process shutdown independently.

Initial filter: 7 native + 3 browser + 6 lifecycle tests passed, with no skips, audio capture or model calls, /tmp/yard-hd016-tests.log. The expanded filter passed all 8 native and 5 browser dictation cases, including disabled-Studio, manual editing and native-bridge dismissal: /tmp/yard-hd005-018-final-tests.log. The same run passed 31 of 32 selected tests overall; the remaining lifecycle fixture used a single Task.yield as a scheduling assertion. That fixture now waits for the observed drain entry, and its targeted rerun passed in /tmp/yard-hd005-018-race-test.log. No dictation test was skipped.

A hardware microphone smoke was deliberately not run: these acceptance boundaries are exercised without capturing or transmitting audio. Recognition quality and installed language availability remain dependent on the user's Apple/browser language support.