If a dictation vendor says speech stays on device, ask which release, which feature, and which kind of data. A source review can identify likely paths; a signed app test checks what the buyer would actually install. For SuprFlow, this matters because local speech recognition sits alongside license traffic, release telemetry, and optional hosted text formatting. A claim should describe each path precisely, then be tested against a named signed build.
This is a reproducible test plan, not a claim that the current public installer passed it. Use a fresh or managed test Mac, a fictional sentence, and a written record of the version and configuration. Do not use actual client speech to test a privacy promise.
Confirm what binary you are testing
Record the download URL, date, app version, macOS version, package hash, and developer identity. On the installed .app, an administrator can run Apple's documented tools:
codesign --verify --deep --strict --verbose=2 /path/to/SuprFlow.app
spctl --assess --type execute --verbose /path/to/SuprFlow.app
Apple explains that codesign checks signature integrity and spctl assesses the app against local system policy. A passing result does not demonstrate “no network,” “no telemetry,” “no training,” or that the app matches a public source revision. It tells you which signed artifact your following tests concern. Use the appropriate installer verification method if the vendor ships a package instead of a standalone app, and have IT interpret unexpected policy output.
Test each route separately
Start with a unique fictional marker such as “Harbor Test 274 did not approve the transfer.” This catches both the route of the text and material rewrite errors.
| Test configuration | What to observe | What it can establish |
|---|---|---|
| First install and model download | Download hosts, file size, prompts, and any sign-in or license checks | Setup traffic is distinct from speech processing. |
| Local recognition and local cleanup | Network requests while recording, local history after completion, and final inserted text | Whether the tested path sends the marker externally; one quiet run is not proof for every mode. |
| Cloud API formatting | Recipient host and whether transcript text is sent | This path may be intentionally external; compare it with the public description and provider agreement. |
| Custom Ollama endpoint | Resolved host and network destination | “Ollama” does not guarantee the endpoint is this Mac. |
| Paste and history controls | System clipboard, third-party clipboard tool, Application Support history file, and destination record | Local copies can persist even when network traffic is limited. |
| Analytics and errors | Event names and parameters during ordinary and failure cases | SuprFlow uses release telemetry; test for user-authored strings, not just transcript payloads. |
| Console and support diagnostics | Standard output, available Mac logs, and any support bundle during short, streaming, chunked, and failed recognition | SuprFlow 1.0.0 prints transcript excerpts on some paths; test whether the signed release and diagnostic collection expose the marker. |
Use an approved network monitor or managed-device instrumentation. HTTPS may hide request bodies, so a host-only trace cannot prove that no text was sent. Correlate it with app instrumentation, a test provider account, source review, and vendor documentation. Conversely, seeing traffic to an account or update service does not mean audio was uploaded. Describe the observed host, data category, and trigger rather than making either leap.
Check local state after app restart, not only while the UI is open. SuprFlow 1.0.0 stores up to 100 entries with raw, cleaned, and possibly formatted text. It briefly uses the clipboard for normal paste. In that release, deleting one history row may not persist after a restart; use Clear All and check again after relaunching. Those findings belong in the release test.
Keep an evidence sheet
For each test, record build identifier, configuration, synthetic marker, expected behavior, observed behavior, evidence location, reviewer, and date. Mark a result “not observed” if the test could not reveal encrypted contents; do not mark it “never happens.” Repeat when the app updates, a formatter changes, or a new destination app is approved. The buyer should be able to reproduce a result without access to real customer text.
Questions people ask
Does notarization prove a dictation app does not send text to the cloud?
No. Apple's notarization and signature checks concern distribution integrity and system policy. They do not attest to the vendor's data-flow or provider retention claims.
Is a source-code review enough to publish a privacy guarantee?
It is useful evidence, but the downloaded signed build, configuration, dependencies, and actual endpoints must also be checked. A claim should identify the release it covers.
Can a network trace prove that no transcript ever leaves the Mac?
A single trace can show traffic observed in that test. Encryption, untested modes, error cases, later updates, and other apps limit broader conclusions. Combine tests with source, contracts, and release records.
Related guides
- Where does my SuprFlow dictation go?
- Does SuprFlow use dictation for AI training?
- Choose local or cloud formatting
- What should a bank ask a dictation vendor?
- What does SuprFlow history contain?
- Can dictation appear in Mac diagnostic logs?