What happens to your audio after you press record

Aurora saves the recording on your device before transcription begins. The models process it there. You decide whether to export it or include it in a diagnostic report.

Most transcription products answer "what happens to my audio" with a privacy policy. A policy describes intent; the data path describes what is possible. This article traces the path Aurora actually takes — the directory the samples are written to, the format they are written in, the protection attribute set on them before the first byte lands, and the complete list of network calls the app is allowed to make.

Where does Aurora write the audio while you are still speaking?

Aurora writes captured audio into a directory it owns inside the app's own container, one directory per session, while the recording is still running. The file is Apple Lossless in an .m4a container — 16 kHz, mono, with a 16-bit depth hint — because live transcription and the later refinement pass both read the same canonical 16 kHz mono stream that the microphone path produces.

The session directory is created with the iOS data-protection class Apple calls complete-until-first-user-authentication, and the same attribute is applied to the audio file immediately after the writer opens and before any samples are written into it. That ordering is the point: a protection attribute applied after the first write would leave unprotected bytes on disk for as long as the write took.

There is no third location. Nothing is staged for upload, because there is no upload path for conversation audio to stage it for: the classes of network egress the product contract permits are listed below, and not one of them carries a recording.

Why does Aurora write the same audio twice?

Aurora keeps a second, dumber copy of the audio because the first one is not reliably readable if the process dies mid-recording. A fragmented MP4 that has not been finalised is only decodable up to its last completed fragment, and the encoder decides when that is. Aurora emits a fragment every 0.5 seconds and asks the writer to behave as a realtime sink, which caps the theoretical loss — and that still was not enough.

Two device-confirmed results drove the design. With the writer batching normally, a recording over a minute long came back as roughly 14 seconds after a hard kill. With realtime writes and half-second fragments, a killed session still recovered only a few seconds of audio. So every chunk is mirrored into a plain PCM sidecar — sample count is file size divided by four, with no container to repair — synced to disk about once a second by a worker that sits off the audio path, so disk durability can never stall sample ingestion. A clean stop deletes the sidecar, which makes its presence the crash signal: recovery prefers it only for sessions that actually died.

Does Aurora's transcription make any network calls?

No. Recording, speech recognition, speaker separation, offline refinement, summaries, action items and Ask Aurora all run on the device that captured the audio, and none of them opens a connection to do it. Aurora is local-first rather than network-free, though, and the honest form of that claim is the list of paths which do exist, together with their defaults. None of them carries a recording or a transcript.

Reading your calendar is not on that list because it is not a network path: Aurora reads your next event on the device and sends nothing anywhere for it.

Setup metrics are the row a privacy page is tempted to leave out. Aurora asks once, at the end of onboarding, with two buttons of equal weight — "Don't share" and "Share and continue" — and stores a three-state answer rather than a boolean, because a boolean cannot tell "declined" apart from "never asked". The upload also requires eight separate build-time approvals and a kill switch, every one of which defaults to off, so a build that forgets to record an approval uploads nothing. The record itself carries no identifier, no text and no audio.

The free-minutes counter is the row we used to leave out, and it is the one exception to "optional". It is a single number in your own iCloud key-value storage, written so that deleting and reinstalling the app does not hand out a fresh trial, and it is not covered by the iCloud sync setting: it is on whether or not you turned sync on. It carries nothing about what you recorded.

What stops the on-device AI from leaking a transcript?

Aurora's chat surface refuses to resolve any image URL the model produces. This is a real exposure in any product that renders model output as markdown: a markdown image renderer resolves a markdown image by fetching its URL, and a transcript containing injected instructions can steer a language model into emitting an image URL with conversation text in its query string. The request itself is the leak — whether an image ever appears is irrelevant.

So the chat renderer installs image providers that draw nothing for a block-level image and throw for an inline one, and that reference neither the networking layer nor any network-image type. A test feeds a reply containing an exfiltration URL through the renderer and asserts that no request is issued. That closes one channel, not the whole class of prompt-injection problems, and Aurora does not claim otherwise — but it is the channel that most reliably turns a local model into an exfiltration path, and it is held shut by a test rather than by a convention.

What leaves the device when you report a problem?

Only a report you asked Aurora to send. Diagnostics are collected locally so that a fault can be investigated at all, and nothing is transmitted until you act. What the report carries is governed by one switch — and when you report a problem from inside a session, that switch starts on, attaching that session's transcript, chat, recording and a screenshot. Turned off, the report is technical only: no audio, no transcript, no summary, no note. What is actually inside an Aurora diagnostic report covers the switch, every tier, the package members and how long a report is kept.

What does Aurora's on-device claim not cover?

It covers the speech pipeline: capture, transcription, speaker separation, refinement, storage and local AI. It does not mean that nothing ever crosses the network, and a product telling you that would be misrepresenting at least its own model download. Aurora's claim is bounded deliberately:

• Bytes in are not bytes out. Models are fetched once. That is traffic toward your device, not away from it — but it is still a request, and the host serving it sees your IP address, the time and the size.
• Your own copies are yours to manage. An export, a share sheet, a device backup or a file you move elsewhere leaves Aurora's boundary on your instruction.
• Two optional features add paths. iCloud settings sync and web research in Ask Aurora are both off until you turn them on, and neither carries audio or transcript text.
• Consent-gated setup metrics exist. Content-free, refusable, and silent unless you said yes.
• One path is not optional. The free-minutes counter writes a single number to your own iCloud key-value storage regardless of the sync setting.
• A report can carry content, and starts that way. On a session report the content switch opens on. That is the one place where the honest answer is "check before you send", not "nothing happens unless you act".

What should you ask any transcription app?

Three questions separate architecture from policy, and the third one answers the first two. Ask where the audio goes. Ask where the transcript goes — a different question with a different answer at many vendors, because a product can transcribe locally and still send the finished text to a cloud model to be summarized. Then put the device in airplane mode and record.

A product that keeps working with the network off cannot have been depending on a server for that work, and no later policy revision can take that property away. A product that stops working has just told you where your conversation was going. Be precise about what the test proves, though: it proves that capture, transcription, separation and summaries are local. It does not prove that an app makes no network calls at all — the table above is Aurora's own list, and a model download is on it. Airplane mode tests the pipeline, not the whole application.

References

1. Apple. FileProtectionType. developer.apple.com — the data-protection classes, including the one Aurora applies to session audio.
2. Apple. AVAssetWriter.movieFragmentInterval. developer.apple.com — fragment emission, and why an unfinalised file decodes only to its last fragment.
3. OWASP GenAI Security Project. LLM01: Prompt Injection. genai.owasp.org — the injection-to-exfiltration pattern the chat renderer blocks.
4. European Union. Regulation (EU) 2016/679 (GDPR), Article 9. eur-lex.europa.eu — special-category data, the reason voice identification belongs on the device.

Related

1. What is actually inside an Aurora diagnostic report — the one path that can carry content, field by field.
2. What on-device transcription costs on an iPhone — the compute budget this architecture spends.
3. Aurora's privacy policy — the named network paths, the report tiers and the retention periods.